Setting up declarative secrets in Kubernetes
Published: 2026-09-03
When working on Kubernetes deployments, connecting all your pods and services will require you to define secrets and credentials to share between workloads. However, defining any of these secrets declaratively in GitOps contexts can be a bit tricky to set up and get right!
As my homelab has grown and evolved in the past few months, so has my secret needs. I’m sharing what I’ve learned from using some different secret management solutions!
SOPS and Sealed Secrets
I started my Kubernetes journey using SOPS to manage my secrets. I was already familiar with it, and FluxCD has built-in integrations for decrypting SOPS secrets. In a similar vein, Sealed secrets is a Kubernetes native alternative.
At a higher-level, both these solutions have similar strategies for defining Kubernetes secrets: they take a private and public key pair, use the public key to encrypt secret data, and then the private key on the cluster decrypts the secret. Flux+SOPS decrypts Secret resources during its reconciliation loop. Sealed Secrets decrypts a custom SealedSecret resource to generate a Secret resource using its own reconciliation loop. Both let you create secrets that can be defined declaratively and committed to the repository!
SOPS and Sealed Secrets were great starting points, and they helped me get up and running quickly. I think the limitations of these solutions only started to show up when I started adopting branch based workflows and set up multiple development and staging clusters to test any changes that I made to my cluster before applying them. Suddenly, the amount of secrets I needed to juggle increased almost exponentially and this issue was exacerbated when I started decoupling my cluster workloads and set up a dedicated storage cluster. This created so many possible contexts to manage each one needing their own set of secrets for development and production! I needed something that could handle all this stratification.
OpenBao and External Secrets Operator
OpenBao is an open source fork of HashiCorp’s Vault. It, like many of the secret management platforms out there, aims to create a centralized location for secrets to be used anywhere. Be it in CI/CD workflows, development shells, or your clusters, OpenBao can act as a secret provider.
It comes with a lot more bits and bobs that let you do more with your secrets. Not only can you use OpenBao to define your secrets, you can use it to define how they are accessed and distributed to your workloads. This is done via RBAC policies. Those policies can then be tied to OpenBao’s myriad collection of authentication methods to give your clusters access to only the specific set of secrets that it needs.
When using OpenBao in a Kubernetes context, I’ve found these specific features very useful:
- Kubernetes authentication: Uses Kubernetes cluster’s internal service accounts to authenticate your workloads’ requests for OpenBao. Very handy if your OpenBao instance is running in the same cluster as the workload that depends on it.
- AppRole authentication: Uses user generated AppRole id and key pair to authenticate a requests to the secret vault.
- Secret injection agent: Instead of storing secrets as resources, OpenBao can be configured to inject the secret into the workload environment when it starts up. Runs as a sidecar and only works if the pod containers have a shell!
Additionally, tools like External Secrets Operator exist to provide a more platform agnostic means of distributing secrets to your workloads. Like Flux+SOPS and Sealed Secrets, it performs a reconciliation loop with you secret management platform to ensure your secrets stay up to date. The connection to the secrets platform is established by the custom SecretStore resource, it then generates native Kubernetes Secret resources from custom ExternalSecret resources.
Reflections
While OpenBao and External Secrets Operator solved a lot of the secrets management issues I was having, it still took time to set up, test, deploy, and migrate all my secrets! They are inherently more complex tools than SOPS or Sealed Secrets, and the niceties and features they provide come at a hefty operational cost.
It all comes down to the scale of your operation, I think, to determine if it’s worth the time and effort to invest in a secret management platform. I think I held on to using Sealed Secrets for so long because I appreciated the simplicity but, at certain point, that was what was holding me back. I had outgrown the target use case for those tools and needed to move on to something more robust.