I'm uncomfortable storing Base64 encoded secrets in our Git repository, even if the repo is private. It feels like a massive security risk. What are the current industry standards for integrating external vaults like HashiCorp Vault or AWS Secrets Manager into a K8s workflow? Should I be looking at "External Secrets Operator" or "Secrets Store CSI Driver"?
3 answers
You are right to be concerned; Base64 is not encryption. The industry is moving heavily toward the External Secrets Operator (ESO). It allows you to define a 'SecretStore' that points to your external provider and then automatically syncs those values into native K8s secrets. This means your application code doesn't need to change—it still reads from environment variables or volumes. In my current project, we use ESO with Azure Key Vault, and it has completely removed the need for developers to ever touch a sensitive YAML file. It’s a "set and forget" solution that keeps your GitOps pipeline clean.
Does your security team require that the secrets never even touch the ETCD database as a native K8s secret object, or is syncing them acceptable?
Sealed Secrets is another great option if you want to keep everything in Git but keep it encrypted. Only the controller in the cluster can decrypt them.
Sealed Secrets is excellent for smaller teams. It fits perfectly into a standard GitOps flow without needing a heavy external vault infrastructure.
Jeffrey, that's the million-dollar question. If you need a "zero-touch" approach where secrets only live in memory, the Secrets Store CSI Driver is better because it mounts the secrets directly as a volume. However, it's a bit more complex to set up. For most companies, syncing to ETCD with 'Encryption at Rest' enabled in the cluster is a perfectly acceptable middle ground that balances security with operational simplicity.