Secrets in CI/CD

Secrets in CI/CD addresses the challenge of providing sensitive credentials (API keys, database passwords, signing keys, cloud provider credentials, Docker registry tokens) to automated pipelines without exposing them in source code, build logs, or artifacts. Every CI/CD platform provides encrypted secret storage that injects values as environment variables at runtime, masked from log output.

Best practices include using the CI platform's built-in secret storage (GitHub Actions secrets, GitLab CI variables) for pipeline-specific values, with references to external secret managers (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) for production credentials. OIDC-based authentication (e.g., GitHub Actions OIDC with AWS IAM roles) eliminates the need for long-lived access keys entirely by exchanging short-lived, scoped tokens. Secrets should be scoped to the minimum necessary environment (production secrets only accessible to production deployment jobs).

Secret rotation must be planned from the start: credentials should be rotated on a schedule (90 days is common) and immediately upon suspected compromise. The rotation process should be automated and tested to avoid outages. Audit logging should track which pipelines accessed which secrets and when. Never echo, print, or log secret values -- CI platforms mask known secrets in logs, but derived values (e.g., base64-encoded secrets) may not be automatically masked. Store Docker image pull secrets and Helm values containing credentials in the CI platform's secret store, never in version control.