I have integrated the external vault into kubernetes cluster. Vault is injecting the secrets into shared volume “/vault/secrets” inside the pod which can be consumed by application container. Till now everything looks good.
But I can see security risk by inserting the secrets into shared volume in plain text as anyone can access the application secrets who has access to the kubernetes cluster.
Example: Secrets are injected into shared volume at /vault/secrets/config
Now, If kubernetes cluster admin logged in and he can access the pod along with secrets available at the shared volume in plain text format.
Kubectl exec -it command will be used to enter into pod.
In this case, my concern is cluster admin can access the application secrets (Ex: database passwords) which is security risk. In my scenario vault admin is different and kubernetes cluster admin is different.
Please provide your inputs on this. Thanks in advance
Yes you need to be careful about who has access to your application as well as all the surrounding infrastructure, as people with such access would be able to obtain credentials. As you mentioned someone with admin privileges to Kubernetes would be able to look at secrets, but also would be able to exec into a pod or possibly dump memory (to find credentials).
To reduce the risk you need to have robust access control and audit processes to reduce the liklihood of inappropriate activities (as well as detecting them if they do occur).
The use of alternative auth options (such as the Kubernetes auth) wouldn’t really help as admins would still be able to intercept things and grant themselves access to credentials. You might be able to mitigate risks slightly by using single use wrapped tokens in some situations, although that would bring its own problems when pods recycle.
I agree with @stuart-c. It’s one of the tradeoffs of having auto-auth and not having to integrated Vault into your application.
I’m no Kubernetes expert but I believe “cluster” wise, you’re safe from other containers/users as they wouldn’t be able to mount your PV, a PVC will lock your storage. As long as the admin can get into your pod though you’re still at some risk there. But that’s also true for almost any auth. If someone has access they can get to the secrets. The trick is to reduce that risk as low as possible.
@aram@stuart-c Thank you for your swift response.
Is it possible export the vault secrets as environment variable without writing to shared volume path? Just a thought.
My intention is to avoid a copy of the secret in a file.
Environment variables are no better. Someone with permissions (e.g. a cluster admin) could easily exec into a pod and view all environment variables and their contents. If anything files are better than env vars.
Yes. I agree with you. Only option we have is, restrict the access of the users to cluster.
I am thinking of solution similar to this one, provided at below link https://codeengineered.com/blog/2020/k8s-exec-access/