Cloud secrets management for compliance
Secrets in code and in pipeline variables are how most cloud breaches start. Auditors ask how credentials are stored and rotated. The answer that passes: a secret manager, federation for pipelines, and scanning that catches leaks.
Store application secrets in the provider's secret manager (AWS Secrets Manager or Parameter Store, Azure Key Vault, Google Secret Manager), fetch them at runtime with the workload's identity, rotate them on a schedule, replace CI/CD access keys with OIDC federation, and scan repositories for secrets on every push. That covers what SOC 2 CC6.1 and ISO 27001 controls 5.17 and 8.24 expect for credentials.
| Provider | Secret store | Rotation | Access by |
|---|---|---|---|
| AWS | Secrets Manager, SSM Parameter Store | Built-in rotation for RDS and custom Lambda rotation | IAM roles on the workload |
| Azure | Key Vault secrets | Rotation policies and Event Grid notifications | Managed identities |
| Google Cloud | Secret Manager | Rotation schedules with Pub/Sub notifications | Attached service accounts |
CI/CD without stored keys
GitHub Actions, GitLab CI and most pipelines can exchange an OIDC token for short-lived cloud credentials: IAM roles on AWS, workload identity federation on Azure and Google Cloud. That removes the most valuable long-lived keys in most companies. Restrict the trust to specific repositories and branches.
Catching leaks
- Secret scanning with push protection on the repository host.
- A pre-commit hook for developers.
- A procedure for leaked secrets: revoke first, then investigate, then record the incident.
Inventory the secrets you already have
Before moving anything, list what exists. Auditors ask for this inventory, and it usually turns up keys nobody remembers creating.
- Export access keys and their last-used dates: the IAM credential report on AWS, service principal credentials in Entra ID, service account keys in Google Cloud.
- Scan repositories, including history, for committed secrets.
- List pipeline variables and secrets in each CI/CD system.
- Record owner, purpose, rotation date and where each secret is used.
- Revoke anything unused for 90 days after confirming with its owner.
Evidence an auditor asks for
| Control | Evidence |
|---|---|
| Secrets stored in a managed service | Secret manager inventory, IAM policies limiting access |
| No static keys for pipelines | OIDC trust configuration, empty key inventory for pipeline identities |
| Rotation | Rotation configuration and last-rotated dates |
| Leak detection | Secret scanning enabled, a sample alert and its resolution |
Workload identities remove most secrets entirely, which is covered in IAM and least privilege. Serverless estates have more of them per workload; see serverless compliance.
Are environment variables acceptable for secrets?
Environment variables populated at runtime from a secret manager are common and acceptable. Secrets hard-coded into task definitions, templates or repository files are not.
How often should secrets be rotated for SOC 2?
SOC 2 does not set a period. Your policy does. Annual rotation for static secrets, immediate rotation on suspected exposure or staff departure, and short-lived credentials wherever possible is a defensible position.
Keys scattered across pipelines?
Firms in the network move secrets to managers and set up federation.
Get matched