Using projected volume mount to read SA token#41
Conversation
| ) | ||
|
|
||
| // GetTokenFromSA gets the token associated to the first secret located in a k8s' service account | ||
| func GetTokenFromSA(cli client.Client, ns, saName string) (string, error) { |
There was a problem hiding this comment.
I might be completely misunderstanding this ... but with this change it seems to me that now we are just reading the secret for the SA the vault-secrets-manager pod is running with instead of the one defined in the CR
There was a problem hiding this comment.
Yes, you are right! I missed this part :(
We deploy the vault-secrets-manager to every namespace (with a single value for WATCH_NAMESPACE env) and then using the SA of the operator makes more sense... However, indeed, this kills the possibility of using single-operator installation and keeping more granular access to Vault. I guess, the PR will be declined
There was a problem hiding this comment.
Yes security wise, it's bad. The operator should connect on behalf of the client SA.
I currently have very little access to internet and only have my phone, so I can't really work on that before Sept. I am afraid... I can merge PR though ;)
There was a problem hiding this comment.
Merging this PR will break installations, which watch multiple namespaces. I'm converting the PR into a draft
3 participants
This PR fixes #40 without the need to create
kubernetes.io/service-account-tokensecrets and link them to SA's.The projected volume mounts also work with earlier versions of Kubernetes.
A new image was built with
docker build . -t xxxxxxx/vault-secret:0.0.1-fix02and tested with k8s 1.24 and 1.23