https://platformengineering.org logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
a
We've been experimenting with runtime secret injections where you put a secret management tool key in place of the value of your secrets and they are fetched right before your service starts, there's multiple solutions for that : https://github.com/busser/murmur https://banzaicloud.com/blog/inject-secrets-into-pods-vault-revisited/
That does the job well, but you have a bigger dependency on your secret management tool that way
g
What scenario are you trying to protect against? I believe it starts by properly configuring your k8s RBAC with least privilege to make sure that Kube secrets can only be read by those who actually need to read them
If secrets are in the env of your process, they can anyways be read by someone that has kubectl exec access to the pod, or node access
a
They're only base64-encoded if you're using the 
Secret
Resource, but if you're injecting/pulling secrets directly into your application Pods then you're subject to the risks others have mentioned (access to 
env
variables, or the ephemeral filesystem if written there)
Another option is to have the applications themselves pull the secrets (https://github.com/hashicorp/vault-client-go) and have their access to the secret store granted via identity management (something like EKS IRSA)
3 Views
Open in Slack
PreviousNext
Powered by