vault-k8s VS sealed-secrets

Hashicorp Vault k8s is an operator that modifies pods via a mutating webhook to connect between vault and pod via sidecars (additional containers) to provide secrets. This has the major advantage that no secret objects are created in Kubernetes here. The disadvantage is that this way only works with Vault.

They’ve made it so you can define the order that the vault sidecar starts in, so that the proxy will be running first. https://github.com/hashicorp/vault-k8s/issues/53

The addition of Consul and Vault gives me a few things. For one, right now I'm handling secrets with a mixture of SOPS and Sealed Secrets. I use Vault in my professional life, and have used both Vault and Consul at my last job. Vault is a beast, so I may as well get better at it; plus its options for secret injection are better.

Use Sealed Secrets Operator.

Considering the major limitations of using Kubernetes Secrets, there are many new approaches being developed by the Kubernetes community. Kubernetes SIGs like the Secrets Store CSI Driver and solutions like the external secrets operator that works with third-party secret managers, and options to seal secrets through tools like bitnami’s sealed-secrets. To skip the tools and move directly to best practices, click here.

sealed-secrets (sealed)

We use sealed secrets controller - https://github.com/bitnami-labs/sealed-secrets

An option that easily works with GitOps is the Operator Sealed Secrets from Bitnami. Secrets encrypted with it can only be decrypted by operators running inside the cluster, not even by the original author. For encryption, there is a CLI (and a third-party web UI) that requires a connection to the cluster. The disadvantage of this is that the key material is stored in the cluster, the secrets are bound to the cluster and one has to take care of backups and operation.

Have you considered SealedSecrets? It is perfect for GitOps, assuming you don't want to deal with a Vault or something like that.