5 ms·

> There’s not much difference between a configmap and a k8s secret. The secret doesn’t have a separate decrypt operation so you have to lock down even list acce

> There’s not much difference between a configmap and a k8s secret. The secret doesn’t have a separate decrypt operation so you have to lock down even list access and can’t separately view it’s metadata so you don’t get much benefit from k8s anyways. Even though Secrets and ConfigMaps are used exactly the same way, there's a big difference between them. The most obvious one being that Secrets contain values that are sensitive. Of course, by the time these sensitive values have made their way into a Kubernetes Secret stored in a Namespace, they appear in cleartext. But the point of a Kubernetes Secret is to offer cluster administrators an Object that is explicitly meant to store Secret values, which can then, _for example_, be stored in ETCD differently (encrypted at rest for example). > My take is that it is noticeably more secure to use the cloud provider secret manager (or hachicorp vault). Yes, you should use Vault (or whichever is your favorite secret management tool), but this has no bearing on the Kubernetes side: ultimately, your sensitive values will end up inside a k8s Secret object, that is then being used by your Workloads (i.e. Pods). > If you use a k8s secret adapter to the external secret manager tool rather than loading directly in the container out of band, the security picture gets more complicated. Loading sensitive values out of band should be avoided since it is non-standard and forces your users to implement a method of retrieving secrets (which will be 1- painful, 2- buggy, 3- a security incident soon). 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. What matters is the transport and persistent storage of your value. For a non-sensitive value, the storage can be done in VCS and transport over non-secure channels. For a sensitive value, the storage must be done encrypted (in hashicorp Vault for example) and transport be done over a secure channel (with authentication/authorization). By using an adapter ([0]External Secrets for example), you actually abstract away the transport and storage of secret values from your users; allowing them to treat all configuration values the same (by reading an ENV variable, or a file), regardless of whether they are sensitive or not, and regardless of where they are stored at rest. [0]: https://github.com/external-secrets/external-secrets https://github.com/external-secrets/external-secrets

gregwebs 4y ago
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.

gregwebs 4y ago

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.