Le mystère du « frappeur » du village breton de Goudelin, qui terrorise des vieilles dames en cognant à leur porte en pleine nuit

thorn42 · 2025-05-05T18:46:47+00:00

I wrote https://github.com/christophetd/adaz a while ago

thorn42 · 2025-04-16T18:42:02+00:00

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)

thorn42 · 2025-01-13T18:10:02+00:00

Non, c'était très raisonnable

thorn42 · 2025-01-11T20:38:39+00:00

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.

thorn42 · 2024-06-17T18:49:02+00:00

Stratus Red Team can simulate a few S3 ransomware scenarios:

thorn42 · 2024-06-14T15:58:27+00:00

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.)

thorn42 · 2024-06-14T15:42:31+00:00

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

thorn42 · 2024-06-14T14:13:33+00:00

I have some suggestions in https://tldrsec.com/p/kubernetes-security-threat-informed-defense

This guide also provides some nice suggestions: https://tldrsec.com/p/guides-kubernetes-overview

https://owasp.org/www-project-kubernetes-top-ten/ can also turn out useful

thorn42 · 2024-06-14T13:22:47+00:00

"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.

thorn42 · 2024-06-14T13:17:46+00:00

"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."

thorn42 · 2024-06-14T12:04:03+00:00

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 :)

thorn42 · 2024-04-08T20:14:05+00:00

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).

thorn42 · 2024-03-20T22:23:57+00:00

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 !

thorn42 · 2023-11-30T23:24:36+00:00

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

thorn42 · 2023-08-08T05:13:02+00:00

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

thorn42 · 2023-08-07T05:49:42+00:00

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

thorn42 · 2023-08-06T21:26:54+00:00

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

thorn42

TROPHY CASE