External Secrets Operator connects a central secret store to applications that expect Kubernetes Secrets. You specify the external values to retrieve, and the operator creates or updates the corresponding Kubernetes objects. It is useful when credentials should be managed at their source instead of copied into deployment files by hand. The copied values still exist inside Kubernetes, so access to those objects and to the consuming workloads remains part of the security design.
Define the trust boundary
Choose the external provider, workload identity, namespace scope and permissions before creating a store. Give each tenant access only to its required paths or keys. A cluster-wide store can simplify administration while increasing the importance of authorization boundaries.
Rotation and outages
Record the expected refresh interval and what an application does when its value changes. Environment variables and mounted files can have different consumption behavior; a synchronized Secret does not guarantee the application has reloaded it. Test provider unavailability and invalid credentials without logging the secret value.
Compare synchronization with mounted-secret and encrypted-Git approaches in the secret-management guide. Keep the provider recovery process separate from application rollout and Kubernetes object restoration.
Sources & further reading
Spotted something that needs another look?
Help improve this page →