4 ms·

This is interesting, but in my opinion, it's not quite as universally useful as some of the secret management in other security tools because you have to explic

This is interesting, but in my opinion, it's not quite as universally useful as some of the secret management in other security tools because you have to explicitly manage the secret within your application by reading that in-memory filesystem. I'd much prefer passing a secret as an environment variable if that can be done securely. It's possible with some tools, but not out of the box with Docker itself. eg, with one tool, you can do: # docker run --rm -e PASSWORD={supersecret_password} someimage:latest program Then '{supersecret_password}' gets replaced in the container at runtime with the value stored in the tool or from an integration with a separate dedicated secret management tool like HashiCorp Vault, and value gets masked external to the container such as when running 'docker inspect' command. The benefit is that you don't need to modify or maintain a lot of pre-packaged applications that read environment variables instead of looking to the contents of a file on the disk, so it just works out the box. However, under ordinary circumstances, you may not want to pass secrets as environment variables in docker (or at least be careful about it). A 'docker inspect' command can show any docker user the environment variable and its value, if you don't have a tool to encrypt the contents.

eicnix 10y ago
Kubernetes supports this already. You have the choice to either mount the secret into the container file system or set it as a environment variable. https://kubernetes.io/docs/user-guide/secrets/#using-secrets-as-environment-variables https://kubernetes.io/docs/user-guide/secrets/#using-secrets...
- tonyhb 10y ago
  But Kubernetes secrets are stored - and by default transmitted amongst managers - in plain text. And Kube will share secrets with all kubelets, no questions asked. They're not "secrets".
  - eicnix 10y ago
    Yes, the kubernetes secrets resource is not a replacement for a secret store. Your specific point is being worked on: https://github.com/kubernetes/kubernetes/issues/12742 https://github.com/kubernetes/kubernetes/issues/12742 You can use Vault(https://github.com/Boostport/kubernetes-vault https://github.com/Boostport/kubernetes-vault) or extend Kubernetes easily for your specific secret as a replacement if you need extra security.
    - tonyhb 10y ago
      "priority/backlog" for 18 months. Kube doesn't care about security.
      - eicnix 10y ago
        Encrypted storage isn't as important when you can restrict the access to the secrets. Just because the secrets are in plaintext in etcd doesn't mean everyone can read them. Then you need a mutual authenticated connection from the api server to etcd + encrypted etcd hard drives + networking policies that only the api-servers are able to communicate with etcd and your secrets are pretty safely stored.
        benth 10y ago
        I agree. I also care more about access control than encryption. But if you obtain a kubelet's credentials, you can read all secrets. It would be nice if a kubelet's access was restricted to only what the kubelet needs to know. That would limit the impact of a node in a cluster being rooted.
        eicnix 10y ago
        There is a issue open for this too... https://github.com/kubernetes/kubernetes/issues/40476 https://github.com/kubernetes/kubernetes/issues/40476
        Pyxl101 10y ago
        > It would be nice if a kubelet's access was restricted to only what the kubelet needs to know. This seems like a fairly difficult problem to solve with meaningful security confidence. The only easy way I can see this working is if you pre-define groupings of kubelets and specify which pods may run on which kubelets, and enforce secret access the same way. Without this kind of hard separation, any kubelet is a candidate for running any pod and needing any pod's secrets at a moment's notice. Furthermore, this sort of separation would require some kind of PKI; you could not just trust any given kubelet to accurately claim which groups a member of. You'd need to provision the kubelet groups with a secret that proves their membership in the group, and we're back to the secret distribution problem again. And while it's true that a given kubelet may not be running a certain pod at the moment (and thus doesn't need the secret), that does not seem to be a hard security boundary. An attacker who controls the kubelet can manipulate which pods run on it, such as by terminating pods until the desired one is scheduled on it, or falsely advertising a huge amount of available resources to entice the scheduler to run pods on it, and so on. Ultimately if a kubelet is a candidate for running a pod, then it is simply a matter of coincidence whether it possesses the pod's secrets at a given moment or not. That said, limiting kublets to have access only to secrets required by active pods will make things harder for an attacker, and so will provide value. But we should also evaluate the priority of that work in context of how hard it will be for an attacker to defeat that same restriction (e.g., advertise 1 petabyte of free RAM and disk, and 1000 idle CPU cores).
koolba 10y ago
How about replacing your entry point with: envdir /run/secrets <stuff>
justincormack 10y ago
Linux does not hide process environments, you can cat /proc/[pid]/environ to read them. It is not a good way to pass secrets.
- heroprotagonist 10y ago
  True, but people do it anyway and a large number of applications are preconfigured to use them. But to the point, the same tool that hides the secret and encrypts the variable in 'docker inspect' will also show it as encrypted in /proc/[pid]/environ as well.
  - justincormack 10y ago
    That would be a kernel patch then. Good luck getting that upstream.
- jlgaddis 10y ago
  On mobile so no URLs, etc, but cf. "hidepid" mount option for /proc.

eicnix 10y ago

Kubernetes supports this already. You have the choice to either mount the secret into the container file system or set it as a environment variable. https://kubernetes.io/docs/user-guide/secrets/#using-secrets-as-environment-variables https://kubernetes.io/docs/user-guide/secrets/#using-secrets...

tonyhb 10y ago
But Kubernetes secrets are stored - and by default transmitted amongst managers - in plain text. And Kube will share secrets with all kubelets, no questions asked. They're not "secrets".
- eicnix 10y ago
  Yes, the kubernetes secrets resource is not a replacement for a secret store. Your specific point is being worked on: https://github.com/kubernetes/kubernetes/issues/12742 https://github.com/kubernetes/kubernetes/issues/12742 You can use Vault(https://github.com/Boostport/kubernetes-vault https://github.com/Boostport/kubernetes-vault) or extend Kubernetes easily for your specific secret as a replacement if you need extra security.
  - tonyhb 10y ago
    "priority/backlog" for 18 months. Kube doesn't care about security.
    - eicnix 10y ago
      Encrypted storage isn't as important when you can restrict the access to the secrets. Just because the secrets are in plaintext in etcd doesn't mean everyone can read them. Then you need a mutual authenticated connection from the api server to etcd + encrypted etcd hard drives + networking policies that only the api-servers are able to communicate with etcd and your secrets are pretty safely stored.
      - benth 10y ago
        I agree. I also care more about access control than encryption. But if you obtain a kubelet's credentials, you can read all secrets. It would be nice if a kubelet's access was restricted to only what the kubelet needs to know. That would limit the impact of a node in a cluster being rooted.
        eicnix 10y ago
        There is a issue open for this too... https://github.com/kubernetes/kubernetes/issues/40476 https://github.com/kubernetes/kubernetes/issues/40476
        Pyxl101 10y ago
        > It would be nice if a kubelet's access was restricted to only what the kubelet needs to know. This seems like a fairly difficult problem to solve with meaningful security confidence. The only easy way I can see this working is if you pre-define groupings of kubelets and specify which pods may run on which kubelets, and enforce secret access the same way. Without this kind of hard separation, any kubelet is a candidate for running any pod and needing any pod's secrets at a moment's notice. Furthermore, this sort of separation would require some kind of PKI; you could not just trust any given kubelet to accurately claim which groups a member of. You'd need to provision the kubelet groups with a secret that proves their membership in the group, and we're back to the secret distribution problem again. And while it's true that a given kubelet may not be running a certain pod at the moment (and thus doesn't need the secret), that does not seem to be a hard security boundary. An attacker who controls the kubelet can manipulate which pods run on it, such as by terminating pods until the desired one is scheduled on it, or falsely advertising a huge amount of available resources to entice the scheduler to run pods on it, and so on. Ultimately if a kubelet is a candidate for running a pod, then it is simply a matter of coincidence whether it possesses the pod's secrets at a given moment or not. That said, limiting kublets to have access only to secrets required by active pods will make things harder for an attacker, and so will provide value. But we should also evaluate the priority of that work in context of how hard it will be for an attacker to defeat that same restriction (e.g., advertise 1 petabyte of free RAM and disk, and 1000 idle CPU cores).

koolba 10y ago

How about replacing your entry point with: envdir /run/secrets <stuff>

justincormack 10y ago

Linux does not hide process environments, you can cat /proc/[pid]/environ to read them. It is not a good way to pass secrets.

heroprotagonist 10y ago
True, but people do it anyway and a large number of applications are preconfigured to use them. But to the point, the same tool that hides the secret and encrypts the variable in 'docker inspect' will also show it as encrypted in /proc/[pid]/environ as well.
- justincormack 10y ago
  That would be a kernel patch then. Good luck getting that upstream.
jlgaddis 10y ago
On mobile so no URLs, etc, but cf. "hidepid" mount option for /proc.