The biggest hurdle we face with GitOps is managing sensitive data like database passwords and API keys. Since the core principle of GitOps is that everything is in Git, how do we handle secrets without violating security best practices? I've heard of Sealed Secrets and External Secrets Operator, but which one is more reliable for a production-grade environment? We need a solution that works seamlessly with an automated CI/CD flow where secrets might rotate frequently.
3 answers
For production environments, I highly recommend the 'External Secrets Operator' (ESO). Unlike Sealed Secrets, which encrypts data into Git, ESO fetches secrets directly from a secure external provider like AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault. This means your Git repo only contains a reference (a SecretStore) rather than the sensitive data itself. This is much better for secret rotation because when you update the password in AWS, ESO automatically detects the change and updates the Kubernetes Secret. It perfectly aligns with the GitOps "pull" model while keeping your sensitive credentials entirely outside of your version control system.
If you go with the External Secrets approach, how do you plan to handle the initial authentication between your Kubernetes cluster and your cloud provider's Key Vault?
Sealed Secrets is great for smaller teams or local dev because it doesn't require a cloud vault, but it becomes a maintenance headache when you need to rotate keys.
Agree, Kimberly. We started with Sealed Secrets but moved to ESO once our infrastructure grew across multiple regions. The centralization offered by a real Vault is unbeatable.
Jeffrey, we use Workload Identity (on GKE) or IRSA (on EKS). This allows the External Secrets Operator pod to assume an IAM role without needing any static credentials stored in the cluster. It’s a "zero-trust" approach where the pod is authorized to fetch secrets based on its identity. This setup ensures that even if someone gets unauthorized access to our Git repo, they only see the names of the secret keys, but they have no way of retrieving the actual values without the specific cloud-level permissions.