The journey of secrets in Kubernetes at Zapier

We adopted Kubernetes in 2017 and initially used Helm and custom scripts to deploy applications from Helm configs in a git repository. We used the Helm secrets plugin to manage our secrets, which uses SOPS under the hood to encrypt or decrypt secrets using various key providers. However, this approach had limitations, such as CI/CD tooling needing permissions to decrypt secrets and unencrypted secrets getting committed to the repo by mistake. We later moved to sops-secrets-operator, which manages Kubernetes Secret Resources created from user-defined SopsSecret custom resource objects using sops. This approach provided better security, but also introduced new challenges, such as duplicate secrets for each Kubernetes cluster and granular access control limitations. Finally, we adopted Vault, a centralized secret management solution that provides granular access control, out-of-the-box Kubernetes authentication mapping, and a user-friendly UI and CLI. We are currently using external-secrets to manage secrets in Kubernetes, which allows us to reference actual secret values in Vault without having to decrypt them. Overall, our journey of secrets management in Kubernetes has been shaped by the evolution of these tools and our need for better security practices.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.