Securely Manage Secrets in CI/CD

Secrets Management designs or repairs secret retrieval, CI credentials, workload identity, access policies and rotation for an authorized system using Vault, AWS Secrets Manager or other tools. Its inputs are the secret names and owners, consumers, environments, authentication mechanism and rotation/recovery policy, inspected without ever displaying the values themselves.

Its six-step procedure: choose the existing supported backend - Vault, a cloud secret manager, or the host's protected secret store - keeping environment boundaries and minimum privileges explicit; for Vault, follow references/vault-setup.md, since development mode and root tokens are never production configuration; for GitHub Actions, follow references/github-secrets.md, keeping pull-request validation jobs separate from privileged ones, and supplying secret values to the consuming process directly rather than interpolating them into generated shell source or printing them for debugging; prefer short-lived workload identity where the backend supports it, checking issuer, audience, workload/environment restrictions and denied access before enabling retrieval; rotate through a prepare, consumer-switch, verification and old-credential-revocation sequence using the backend's supported rotation protocol, ensuring retries never leave the database and secret store on different credentials; and inspect logs, error paths, artifacts and crash reports using synthetic secret markers, recording only metadata like operation, principal and outcome, never values.

Its worked example: a deployment needing a database credential has the trusted job retrieve it through the configured identity and pass it only to the migration process; missing access and an expired identity are tested in staging; and verification confirms no credential appears in output and a failed rotation leaves a recoverable working state.

The Vault-specific checklist separates disposable development mode from production, verifies authenticated TLS, storage, recovery procedures, audit access and least-privilege policies against the installed version's own documentation, prefers short-lived workload identity, and tests allowed and denied paths with synthetic values before rotating in staging and revoking the old credential only after consumers have successfully switched and been validated. The GitHub Actions checklist supplies secrets through the process environment or an approved credential action rather than shell-expression interpolation, avoids printing, tracing, encoding or uploading secret values, isolates untrusted pull-request jobs, verifies missing-secret failure, and notes that an environment name alone does not establish reviewer protection - its actual configured rules must be inspected.

Use it to design or repair secret retrieval, CI credentials, workload identity, access policies or rotation for an authorized system. Limitations: masking cannot make logging secrets safe; secret data can persist in infrastructure state, subprocess environments or backups, and those boundaries need explicit review; and real credentials must never be altered or secret infrastructure deployed without authorization.

Inputs are the secret names, owners, consumers, environments, authentication mechanism and rotation policy for the target system. Output is a verified configuration: authorized retrieval succeeds while a different workload or environment is denied, missing credentials fail closed without exposing values, rotation and rollback are exercised with synthetic data, logs and artifacts carry no secret markers even on failure, and any credential that was exposed is actually revoked or rotated - not just deleted from a log entry.

It suits engineers hardening CI/CD credential handling who need a concrete procedure for workload identity, safe secret injection and coordinated rotation rather than a vague "use Vault" recommendation.