3 ms·

I agree that K8s secrets are more convenient for applications and separate out deployment concerns. But I don't agree with any of the statements made about secu

I agree that K8s secrets are more convenient for applications and separate out deployment concerns. But I don't agree with any of the statements made about security properties. It is possible to not use K8s and make things just as convenient. For example by encrypting the secrets and putting them into the docker image and having a tool run at startup that decrypts them into the same file format as K8s (or as env variables). More equivalent and with less exposure of encrypted values would probably be to run a sidecar container that pulls in the secrets from the secret manager. If you want to represent the secrets in K8s you still can as a CRD that doesn't actually expose the secrets when listed or read.

gouggoug 4y ago
I’m not sure I understand. What is the issue with Kubernetes Secrets that makes you want to go through all this complexity and avoid using a facility explicitly meant to manage secrets efficiently?
- gregwebs 4y ago
  Security. K8s secrets present their data in the clear to anyone who can view it or list or watch secrets. Cloud secret managers provide a separate decrypt operation, along with builtin features like auditing and versioning. > _for example_, be stored in ETCD differently (encrypted at rest for example). Cloud provider k8s clusters are deployed with encryption at rest for ETCD now. If secrets were doubly encrypted at rest that wouldn't fix how their secret values are exposed in what should be just a metadata listing. > From the point of view of the process running inside the container, there is absolutely no difference between a sensitive configuration value and a non-sensitive configuration value. When this value reaches your process it is in cleartext. This model is desirable for convenience, but not for security. In order to securley handle a secret properly, the process needs to know that it is handling a secret. This can help to ensure secrets are not accidentally logged. For higher levels of security, it also helps to periodically refresh secrets so that they can be given as expiring tokens.

gouggoug 4y ago

I’m not sure I understand. What is the issue with Kubernetes Secrets that makes you want to go through all this complexity and avoid using a facility explicitly meant to manage secrets efficiently?

gregwebs 4y ago
Security. K8s secrets present their data in the clear to anyone who can view it or list or watch secrets. Cloud secret managers provide a separate decrypt operation, along with builtin features like auditing and versioning. > _for example_, be stored in ETCD differently (encrypted at rest for example). Cloud provider k8s clusters are deployed with encryption at rest for ETCD now. If secrets were doubly encrypted at rest that wouldn't fix how their secret values are exposed in what should be just a metadata listing. > From the point of view of the process running inside the container, there is absolutely no difference between a sensitive configuration value and a non-sensitive configuration value. When this value reaches your process it is in cleartext. This model is desirable for convenience, but not for security. In order to securley handle a secret properly, the process needs to know that it is handling a secret. This can help to ensure secrets are not accidentally logged. For higher levels of security, it also helps to periodically refresh secrets so that they can be given as expiring tokens.