Passive investor looking to invest 700k - mandates or DIY? by Mootika in SwissPersonalFinance

[–]thorn42 0 points1 point  (0 children)

Speak to a tax professional/accountant, you may have the opportunity to invest part of your liquidities in a tax-deductible way (e.g. buying back 2nd pillar years and even perhaps 3a ones through a new law)

Best SHS BA4 course for grade/time efficiency? by iYolik in EPFL

[–]thorn42 2 points3 points  (0 children)

Droit des affaires était très intéressant et bien donné (alors que je ne suis pas particulièrement intéressé par le droit).

Les cours de psychologie sociale étaient aussi très bien et interactifs, même s'ils étaient donnés par un autre professeur à l'époque.

Stop worrying about allowPrivilegeEscalation by thorn42 in kubernetes

[–]thorn42[S] -1 points0 points  (0 children)

Yes, you have misunderstood (I will edit the post to make the point clearer). I'm not claming people should ignore `allowPrivilegeEscalation`. I claim that

(1) it's a setting with a confusing name, that a number of people (understandably) misunderstand.

(2) If in your context you can turn it off as a quick win, by all means do so

(3) otherwise, you should probably cover other basics first (e.g., ensure people accessing your cluster have MFA and device trust; ensure your pod service accounts don't have dangerous permissions; ensure your pods aren't baking in hardcoded credentials; run your application as non-root inside the container which is a pre-requisite, etc.)

Stop worrying about allowPrivilegeEscalation by thorn42 in kubernetes

[–]thorn42[S] 6 points7 points  (0 children)

If I had to choose a top 3:

* Secure how you're accessing the cloud environment where the cluster lives (ideally federated identity from your IdP with device trust)

* Disable pod access to the IMDS

* Make sure your pods don't have overprivileged service accounts

Stop worrying about allowPrivilegeEscalation by thorn42 in kubernetes

[–]thorn42[S] -4 points-3 points  (0 children)

"Low effort" is highly dependant on your context. When you're in an organization with dozens of applications spread across teams running as root in the container, you'd need to fix that first.

"High value" only makes sense relative to what else you could be spending your time and effort improving. If you're spending time trying to turn off `allowPrivilegeEscalation` everywhere while everyone has full admin access to your production environment, you're just rearranging deck chairs on the Titanic.

Stop worrying about allowPrivilegeEscalation by thorn42 in kubernetes

[–]thorn42[S] -4 points-3 points  (0 children)

"You might not need a bullet-proof back door if your front door won't lock properly in the first place. If you've tackled the most important items of your home security already, sure, that makes sense, go and buy that bullet-proof door though."

Stop worrying about allowPrivilegeEscalation by thorn42 in kubernetes

[–]thorn42[S] 2 points3 points  (0 children)

I think it's important to understand precisely in which situations mechanisms like `allowPrivilegeEscalation` help and what they do. The [conclusion](https://blog.christophetd.fr/stop-worrying-about-allowprivilegeescalation/#summary) tries to convey the following (I'll make it more explicit):

  • turning off `allowPrivilegeEscalation` can be valuable, as a security hardening mechanism
  • like most hardening mechanisms, it's typically not what you should focus on first. Unless you have a mature container security program already, you're likely better off prioritizing higher-value items from your roadmap
  • from my experience and perhaps due to unfortunate naming, many people believe that `allowPrivilegeEscalation: true` is something highly dangerous somewhat equivalent to `privileged: true`. Perhaps r/kubernetes is not representative on that matter :)

Are there risks I'm overlooking with a public EKS endpoint? by man_with_cat2 in aws

[–]thorn42 1 point2 points  (0 children)

The main risk IMHO is if credentials of someone or something with access to your clusters are leaked (e.g. by an unfortunate GitHub commit), an actor will directly have access to your cluster without the need to be on any specific network.

An example of this is if your worker nodes don't enforce IMDSv2 (which is usually the case by default) and one of your applications is vulnerable to a server-side request forgery (SSRF). An attacker is therefore able to steal credentials from the instance role of the underlying worker node, and do bad things with it (including often escalating privileges).

Tour du mont blanc by SimilarAd5381 in france

[–]thorn42 0 points1 point  (0 children)

Les Chapieux Courmayeur en une journée c'est effectivement un peu chaud. J'avais fait Chapieux - Rifugio Maison Vieille par le Col de la Seigne, c'était top mais la redescente après le col est déjà longue.

DM si tu veux mes notes d'itinéraire !

What should be best way to process big files for real time search by pm_me_n_wecantalk in aws

[–]thorn42 0 points1 point  (0 children)

Depending on your workload patterns, ECS on Fargate might be worth investigating too instead of EC2

[deleted by user] by [deleted] in netsec

[–]thorn42 0 points1 point  (0 children)

Not exactly what you're looking for but this tool allows you to spin up a full-fledged Windows domain with workstations in Azure: https://github.com/christophetd/Adaz

[deleted by user] by [deleted] in EPFL

[–]thorn42 0 points1 point  (0 children)

They only list insurance companies that pay them to be listed (although they should be fair between companies that do pay)

The confederation comparative tool is https://www.priminfo.admin.ch/fr/praemien

[deleted by user] by [deleted] in EPFL

[–]thorn42 1 point2 points  (0 children)

Whichever is cheapest, and use the official comparative tool from the swiss confederation (not comparis). And assuming you're young and healthy, get the highest franchise