You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 26, 2022. It is now read-only.
In all of the configuration examples, secrets (e.g. API keys) that are used directly by external-secrets in order to authenticate with a secrets backend (e.g. secrets manager, vault, etc) are attached to the pod via an environment variable.
Is there a reason that external-secrets doesn't seem to support this? If not, are folks open to enabling either mechanism in a plugin-agnostic fashion?
The text was updated successfully, but these errors were encountered:
Ideally, you wouldn't need any credentials at all and rely on the trust relationship of the underlying compute infrastructure.
I agree, i see the value to use files!
Is there a reason that external-secrets doesn't seem to support this?
AFAIK there was no demand for that, yet. It seems that this is a risk people are willing to accept.
If not, are folks open to enabling either mechanism in a plugin-agnostic fashion?
In all of the configuration examples, secrets (e.g. API keys) that are used directly by
external-secrets
in order to authenticate with a secrets backend (e.g. secrets manager, vault, etc) are attached to the pod via an environment variable.Generally, it's recommended to mount secrets as files rather than environment variables, because that's a slightly better security posture. (One example from SO: https://stackoverflow.com/questions/51365355/kubernetes-secrets-volumes-vs-environment-variables). Secret values can also be changed without restarting the pod when mounted as a volume.
Is there a reason that external-secrets doesn't seem to support this? If not, are folks open to enabling either mechanism in a plugin-agnostic fashion?
The text was updated successfully, but these errors were encountered: