k8s management/handling of secrets inside container

1
votes

I'm currently migrating my docker deployment to k8s manifests and I was wondering about the handling of secretes. Currently my docker container fetches /run/secrets/app_secret_key to get the sensitive information inside the container as env var. but does that have any benefit in comparison to k8s secrets handling as on the other side I can also do something like this in my manifest.yaml:

env:
- name: MYSQL_PASSWORD
  valueFrom:
    secretKeyRef:
      name: mysql-password
      key: password

which than directly brings the secret as a env-variable inside the container ... The only difference I was able to notice is that if I fetch /run/secrets/app_secret_key inside the container like so (docker-entrypoint.sh):

export APP_SECRET_KEY="$(cat /run/secrets/app_secret_key)"

the env var is not visible when I access the container after deployment, it seems that the env var is only available at the "session" where docker-entrypoint.sh gets initially triggered (at container/pod startup).

So my question now is what does make more sense here: simply go with the env: statement shown above or stay with manual fetching /run/secrets/app_secret_key inside the container ...

Thanks in advance

2
dockerkuberneteskubernetes-secrets
A tough to myself: In the end it shouldn't matter if I load secrets the one or the other way as even if the container gets exploited somehow by an attacker or so they will be able to access run/secrets/app_secret_key. There seems to be no difference except that the secret does not get directly exposed when printenv is called if loaded from /run/secrets/app_secret_key as shown above... – sunwave121

2 Answers

2
votes

To be frank both are different implementation of same thing you can choose either one but I will prefer kubernetes approch as mounting secret than container reading at run time simply because of visibility.

Won't matter if you look for one container but when we have 30-40+ microservice running accross 4-5+ environment and have like 100 or even 200 secret. In this case one deployment go wrong we can look at deployments manifest and can figure out entire application. We don't have to search for docker file to understand what happening.

1
votes

Exposing secret as env var or file is just a flavor to use the secret the k8s way.

Some secret like password is just a one line long string, so it’s convenient to use it as env var. Other secret like ssh private key or TLS certificate can be multiple line, that’s why you can mount the secret as volume instead.

Still, it’s recommended to declare your secret as k8s secret resources. That way you can fetch the value needed via kubectl without having to go inside the container. You can also make a template like helm chart that generate the secret manifests at deployment. With RBAC, you can also control who can read the secret manifests.

As per your comments, yes any user that can go inside the container will have access to the resource available to the shell user.