Azure / secrets-store-csi-driver-provider-azure

Azure Key Vault provider for Secret Store CSI driver allows you to get secret contents stored in Azure Key Vault instance and use the Secret Store CSI driver interface to mount them into Kubernetes pods.
https://azure.github.io/secrets-store-csi-driver-provider-azure/
MIT License
439 stars 193 forks source link

Possibility to inject key-vault values as environment variables with or without k8s secrets #412

Open ilya-git opened 3 years ago

ilya-git commented 3 years ago

Describe the solution you'd like Many applications have a native ability to read options/parameters from environment variables like e.g. dot net core. Right now to get that behavior we need to:

  1. Mount the files that won't be used later
  2. Add secrets as k8s secrets that won't be used later
  3. Map k8s secrets to env.variables

For many applications there is not much need for all of these and it would be a nice feature to just allow injection of variables without the need to configure either mounts or secrets.

Anything else you would like to add: It would be a cool additional feature if injecting as env. variable can update k8s secrets (like what is happening now during the mount if configured) with enabled auto-rotation that will restart pods to inject new environment variables with renewed secrets if the secret has changed.

Or perhaps it's possible to evaluate the injected variables instead of creating a k8s secret to determine if pod should be restarted.

That would allow for completely pain-free secret update, like e.g. database password update.

ltouro commented 3 years ago

Are we able to use Deployment env.valueFrom.secretKeyRef along with SecretProviderClass secretObjects already?

The documentation hints that this is possible. If so, I think it should be removed from backlog. https://docs.microsoft.com/en-us/azure/aks/csi-secrets-store-driver#enabling-and-disabling-autorotation image

Digging further, confirmed that we are able to do it with Secret or mounts. I don't see any benefit in not using these as they are first-class k8s citzens.

I think the gap here is to be able to restart the container as secrets are auto-rotated. It seems a feature better suited for k8s itself though.

ms1111 commented 2 years ago
  1. Mount the files that won't be used later

Even with the ability to use env.valueFrom.secretKeyRef, there is still a requirement to mount the files, otherwise the synced secrets aren't created. That's a bit unfortunate; it makes it more complicated to build a chart that can use regular secrets OR the CSI driver in different environments. Each deployment needs to be modified to mount the volume from the CSI driver.

kpkool commented 2 years ago

Is there anyway to expose vault secret directly as pod's env variables. My client does not allow you to use k8s secret due to base64 encode, which is still clear text. For e.g some db and sensitive data store credentials really need to be hidden from K8s admins/developers.

What my customer need is: https://akv2k8s.io/tutorials/env-injection/1-secret/ Ref: https://akv2k8s.io/