fcgravalos
commented
4 years ago Hey @smurfralf !
First of all, thanks for using secrets-manager and for opening the PR.
We do it internally by creating a kubernetes secret and populating VAULT_ROLE_ID and VAULT_SECRET_ID env variables. This is a good way of doing it assuming you have a minimum baseline of RBAC controls in your kubernetes cluster: secret read and pod execution.
My suggestion is that you deploy secrets-manager in its own namespace and you make sure you put RBAC controls to make sure access to resources in this namespace at least are restricted.
In our case, we do restrict pod execution and secret read privileges.
Other than that, If you have any other suggestion, just let me know
The scheme used for vault credentials (approle ID + secret passed thru cmd line or env vars) exposes the credentials to snooping. Even if you use a Secret to pass those values into secrets-manager (via yaml), the program writes them to disk where they can be read by an admin who has execute rights on the container.
Secrets-manager should support use of vault's Kubernetes Service Account Authentication to avoid these issues.(Edit: service account auth does not resolve any of this and is actually more leaky than approle because it puts its credentials into k8s secrets where they can be read thru kubectl)PS. In the documentation I don't see any notes on recommended yaml to deploy secrets-manager into kubernetes.