[ptcrash]

One of the most common misconfigurations I've seen is improper secrets handling. I'm glad to see it called out but I wish they would go into a little deeper detail on detection and remediation. Overall looks pretty good! I'm excited to have some baselines for K8s.

[m4l3x]

Can you elaborate what is improper secret handling in your opinion. I personally use sealed secrets, but I think generation of them is sometimes tricky (tied to the namespace etc

[ptcrash]

I don't have an easy answer for you because I'm still struggling to find the "proper" solution myself. That's why I'd kill to have the agencies weigh in.

I'm not a fan of SealedSecrets or managing secrets in-code at all because of this scenario: Secret rotation requires pushing updated code which may take too much time in a compromised situation. Ie, I don't want to hinder secret rotation with CI tests and merge approvals when there's an active incident triage - I want to kill the pwned secret with fire and get a fresh secret in there ASAP.

I've gotten better results by treating secrets as state instead of infrastructure... Like, by coupling your pod to a secret vending service like Vault or Secrets Manager, you can remove potential for programmers to introduce anti-patterns that weaken our posture.

The benefit is that we can keep things encrypted, auto-rotate things behind the scenes, remove the chance of developers to have even an encrypted copy of secrets, and we can get better turn-around on IRs when secrets inevitably get leaked. And, you can still write out the secret as IaC.

To mitigate the potential for single-points of failure when the secrets service goes down is to allow for secret caching client side. Vault and AWS Secrets Manager, which are the only services I can vouch for, both have client-side caching capabilities.

Take that with a grain of salt. I admit, I'm opinionated

[sqidyyy]

Thank you for this post. I agree and feel the struggle as well. Often the issue is even to communicate that this type of data is, literally, a _secret_ and should be treated accordingly.

I'm looking forward to things like mTLS and solutions with short token lifetimes and automated rotation. This should definitly reduce the amount of encrypted secrets in Git repos and basic auth logins for every 3rd exposed service.

In the end developers rarely care how the secrets gets to the application, or if it's fresh or been in the same namespace for over a year.

[f0e4c2f7]

Vault is what I would recommend. It's like a password manager for prod. When used correctly almost no one has to know the actual secrets and they can be easily reset and changed as long as you develop with that in mind.

Support with the Kubernetes secrets API is baked in and well documented.

Secrets manager and similar tools are fine too.