If your organization is small and lacks an external Secret management system like Vault, Sealed Secret is worth considering.

As seen in the recent xAI API Key leak case, passwords and authentication keys are a headache when setting up GitOps deployment pipelines.
Including Secret information in git repos or helm charts raises security risks, but injecting Secrets only during deployment breaks the automation flow. Therefore, to maintain GitOps workflow while securely managing Secret information, external Secret injection services like Vault or AWS Secret Manager are typically used. (There's an excellent open-source alternative called Infisical.)
However, there are ambiguous environments where Vault-like solutions cannot be used due to circumstances. Perhaps the service scale is moderate, or you're using a Private Cloud that hasn't adopted Vault... In such cases, Sealed Secrets created by Bitnami is worth considering.

Sealed Secrets doesn't have a separate external Secret management system, and manages Secret information with two tools:

• Cluster Side Secret Controller (=Operator)
• Client Side Utility (=kubeseal)

The overall flow is as follows: 1) Encrypt Secret 2) Version control and deploy the encrypted Secret 3) Decrypt in the cluster

Step	Action	Key Points
1. Install Controller	Deploy Sealed Secrets Controller + CRD to the cluster once using Helm/Kustomize etc.	The controller/operator monitors SealedSecret objects cluster-wide and decrypts them
2. Obtain Public Key	In development · CI environment kubeseal --fetch-cert > pub.pem (or automatically fetch from Operator)	This step can be skipped in environments with access to the Secret Controller Operator
3. Write Original Secret	Create temporary Secret locally kubectl create secret … --dry-run=client -o yaml > secret.yaml	This Secret is temporarily created in the operator/CI environment
4. Encryption (Seal)	cat secret.yaml | kubeseal \ --cert pub.pem \ --format yaml > secret-sealed.yaml	kubeseal outputs kind: SealedSecret encrypted with AES-256-GCM + RSA-4096 using the public key. This encrypted data is safe even if exposed
5. Git Commit & PR	Commit secret-sealed.yaml to Git repository (Argo CD/Flux source)	Safe to upload to public repositories as it's encrypted data
6. Apply (Deploy)	GitOps tool or kubectl apply -f secret-sealed.yaml	Controller decrypts with Private Key → Creates K8s Secret with identical name·namespace
7. Application Usage	Reference from Deployment/Pod as usual with envFrom, secretKeyRef, etc.	Created Secret works 100% like a regular Secret, and is automatically updated/cleaned when SealedSecret is changed/deleted

As shown, Secrets encrypted with asymmetric keys remain secure even when included in various configurations or deployment packages like helm charts, ensuring the GitOps flow remains uninterrupted.

However, if the keys stored on the Cluster Side are compromised or lost, there's no remedy, so preparing countermeasures for this would eventually lead to something like Vault... Nevertheless, I believe Sealed Secrets is a useful tool for small to medium-sized services that strikes a reasonable compromise between security and automation.

https://github.com/bitnami-labs/sealed-secrets