domains / security / ci-cd-secrets-management / secrets-management

secrets-management

Skill card

combined

The two skills cover the same domain but with different emphases and non-overlapping material. The first copy (rmyndharis) is a broad, example-heavy guide that includes specific tool integrations (Vault, AWS, Azure, GCP), Terraform, and a Python rotation script. The second copy (sickn33) is a stricter, security-focused procedure that emphasizes workload identity, least privilege, specific verification steps (testing denied access, synthetic markers), and explicitly warns against the development-mode patterns shown in the first copy. Crowning one would hide the other's unique constraints (e.g., the second's strict verification and identity focus vs. the first's concrete tooling examples).

Repositories

Other copies

Combined skill

---
name: secrets-management
description: Implement secure secrets management for CI/CD pipelines using Vault, AWS Secrets Manager, or native platform solutions.
---

# Secrets Management

## Purpose
Implement secure secrets management in CI/CD pipelines without hardcoding sensitive information.

## Procedure
1. **Identify Requirements**: Determine secret types, owners, consumers, environments, and rotation requirements.
2. **Choose Backend**: Select a supported backend (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) or the host's protected secret store.
3. **Configure Access**:
   - **Vault**: Use production-hardened configurations. Do not use dev mode or root tokens in production. Integrate via `hashicorp/vault-action` (GitHub) or CLI (GitLab).
   - **AWS**: Use `aws-actions/configure-aws-credentials` or workload identity. Retrieve via `aws secretsmanager get-secret-value`.
   - **Cloud Native**: Leverage IAM/RBAC integration for Azure/GCP.
4. **Implement Least Privilege**: Prefer short-lived workload identity where supported. Check issuer, audience, and environment restrictions. Ensure different workloads/environments are denied access.
5. **Integrate with CI/CD**:
   - Supply secrets to the consuming process (e.g., via environment variables or files).
   - Never interpolate secrets into generated shell source or print them for debugging.
   - Use `::add-mask::` (GitHub) or equivalent masking in logs.
6. **Rotation**:
   - Use the backend's supported rotation protocol (e.g., AWS Lambda for RDS).
   - Follow a prepare -> switch -> verify -> revoke sequence.
   - Ensure retries do not leave the database and secret store on different credentials.
7. **Verification**:
   - Test that authorized retrieval succeeds and unauthorized access is denied.
   - Verify missing credentials fail closed without exposing values.
   - Use synthetic secret markers to inspect logs, artifacts, and crash reports.
   - Confirm no secret markers appear in output, including on failure.

## Safety & Best Practices
- Never commit secrets to source control.
- Use different secrets per environment.
- Enable audit logging (record operation, principal, outcome; not values).
- Use secret scanning (GitGuardian, TruffleHog).
- Encrypt secrets at rest.
- Document secret requirements.

## Limitations
- Masking does not make logging secrets safe; data can persist in infrastructure state, subprocess environments, or backups.
- Do not alter real credentials or deploy secret infrastructure without authorization.