NSA, CISA Release Kubernetes Hardening Guidance [pdf]
media.defense.gov
media.defense.gov
OpenStack feels like the last comparable extensible & open effort we could compare agaonst. OpenStack seemingly became a vendor fest, & vm's were never a truly great developmemt technology. The world of each platform service kind of being it's own separate thing contrasts so markedly versus a consistent configuration paradigm: desired state for everything is recorded on the api server (in k8s).
Things feel so much better this time around. There's really some good solid core policies we can write up like tbis for how to get safe, & we can really tell, semi-regardless of a lot of the infrastructure particulars. The paradigm holds very well across thr mamy quite varying deploemt possibilities.
And the containerization means we're dealing with much thinner workloads, with vastly reduced surface.
This is such strong evidence of winning, in a way a purely vendored world is so ill equipped to compete with.
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
Support with the Kubernetes secrets API is baked in and well documented.
Secrets manager and similar tools are fine too.
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.