When you manage applications with GitOps, you often need Secrets — tokens, passwords, and private keys — that GitOps deploys from Git repositories. Storing these Secrets as plaintext in a Git repository risks credential exposure. The GitOps system provides two approaches to keep Secrets secure.
Choose an approach
| Approach | How it works | Best for |
|---|---|---|
| Reference secrets from KMS | Store Secrets in Key Management Service (KMS). The Git repository holds only references; an operator fetches the actual values at deploy time. | Teams that want a single source of truth in a dedicated secrets store |
| Encrypt secrets in Git | Encrypt Secrets before committing them to Git. The cluster decrypts them after import. | Teams that prefer keeping all configuration — including secrets — in Git |
Reference secrets from KMS
This approach stores Secrets in KMS and keeps only a Kubernetes resource manifest in your Git repository. The manifest references the KMS secrets rather than embedding them. When GitOps deploys the manifest to an ACK cluster, an operator fetches the corresponding Secret from KMS and creates a Kubernetes Secret in the cluster.
ACK One supports two tools for this approach:
-
ExternalSecrets — syncs secrets from KMS into Kubernetes Secrets.
-
Secrets Store CSI Driver — mounts secrets directly from KMS into pods.
To implement this approach, store your Secrets in KMS, then add ExternalSecret and SecretProviderClass resources to your application manifest in Git. You also configure how each workload consumes the Secrets.
For step-by-step instructions, see Use ack-secret-manager or csi-secrets-store-provider-alibabacloud to import secrets from KMS.
Encrypt secrets in Git
This approach encrypts Secrets before storing them in a Kubernetes Secret manifest in your Git repository. The Secrets are decrypted after they are imported to the ACK clusters where your applications are deployed.
You can search for this solution in the open source community.