Practical examples demonstrating how to use ESI Pod Webhook annotations.
my-app-db-config
ExternalSecret as environment variables into the my-app-container
.
env-vars: "true"
.esi-cli --mode=init
.esi-cli
fetches data from the my-app-db-config
ExternalSecret.my-app-container
starts with these secrets as environment variables.my-app-tls-certs
ExternalSecret into the /secrets/secrets.json
file, accessible by my-secure-app-container
.
file-secrets: "true"
.esi-cli --mode=daemon
.emptyDir
volume (named secretless-secrets
by default) and mounts it to both the sidecar and your application container(s) at /secrets
.esi-cli
in the sidecar writes the fetched secrets to /secrets/secrets.json
.secrets.json
if the ExternalSecret
changes (application needs to support reloading).esi-cli
FederationAPI_TOKEN
) using esi-cli
’s federation capabilities from a federated ESI server and inject it as an environment variable.
secretless.externalsecrets.com/externalsecret
annotation is still technically required by the webhook to trigger its logic, even if the primary secret source is federated. You can point it to a minimal or placeholder ExternalSecret
in the pod’s namespace.env-vars: "true"
enables the init container with esi-cli
.federated-server-url
and federated-store
annotations configure esi-cli
to talk to the federation server.inject-on-env: "API_TOKEN=remote-secret-name.api-key"
tells esi-cli
to fetch api-key
from remote-secret-name
(via the federated store) and expose it as API_TOKEN
.env-vars
and inject-on-env
) AND a sidecar container (for file-secrets
).esi-cli
to set PRIMARY_DB_HOST
and PRIMARY_DB_PORT
./secrets/secrets.json
with all data from app-comprehensive-secrets
.esi-cli
documentation for details on its specific flags and behaviors when using passthrough annotations.