Secrets Management

Secrets management should reduce long-lived credentials, centralize audit, and make rotation routine. The strongest pattern is to replace static secrets with workload identity wherever possible.

Recommended posture

• Prefer cloud workload identity, OIDC federation, and short-lived tokens over stored credentials.
• Keep production secrets in a dedicated secrets manager, not in CI variables, source control, images, or Helm values.
• Scope secrets to service, environment, and least privilege.
• Rotate secrets automatically or on a published schedule.
• Detect leaks with pre-commit hooks, CI scanning, and repository scanning.
• Keep break-glass credentials rare, monitored, and time-bound.

Runtime delivery

Use one of these patterns:

• Native cloud secret injection for serverless and managed services.
• External Secrets Operator to sync cloud secrets into Kubernetes.
• Secrets Store CSI Driver for mounted Kubernetes secrets.
• Vault Agent, sidecars, or dynamic secrets for advanced rotation needs.
• SOPS with Age or KMS for encrypted Git-managed configuration.

Avoid placing raw secrets in Kubernetes manifests. If secrets must exist as Kubernetes Secret objects, ensure encryption at rest, tight RBAC, and rotation ownership.

CI/CD credentials

CI systems should use identity federation instead of static cloud keys. Common examples include GitHub Actions OIDC to AWS, Azure, or Google Cloud, GitLab workload identity federation, and short-lived deploy tokens for artifact registries.

Tooling examples

• HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Doppler, 1Password Secrets Automation, or Infisical.
• External Secrets Operator, Secrets Store CSI Driver, SOPS, Age, and Sealed Secrets for Kubernetes-adjacent workflows.
• Gitleaks, TruffleHog, GitHub secret scanning, and GitLab secret detection for leak prevention.