Managing Secrets
Plugin: TSH Platform Engineering
Invoke: /tsh-platform-engineering:managing-secrets, or loaded automatically when a request matches its description
Used by: devops-engineer, infrastructure-auditor, which audits secret handling against this skill's checklist
Picks the secret store that matches the deployment shape, then federates credentials instead of copying them. The failure it exists to prevent is a long-lived cloud access key pasted into CI settings, which no rotation policy ever reaches.
Key Areas
| Area | Coverage |
|---|---|
| Precedence | Reads the shared context file; sections 3 and 4 detect the cloud provider and any secrets tooling already in place. An existing pattern in the repository outranks the decision matrix, and is extended instead of adding a second mechanism. |
| Solution matrix | Single cloud with simple apps: the cloud-native store (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Multi-cloud or hybrid: HashiCorp Vault. GitOps with Kubernetes: Sealed Secrets, or External Secrets Operator when the source of truth is a cloud store. Local development and small teams: SOPS with age or GPG. CI/CD to cloud: OIDC federation, with no stored key at all. |
| CI/CD federation | GitHub Actions to AWS, Azure and GCP through OIDC (aws-actions/configure-aws-credentials, azure/login, google-github-actions/auth). GitLab CI to AWS or GCP through OIDC with the job JWT. Bitbucket Pipelines to AWS through OIDC (oidc: true) with a web-identity role. Vault with JWT or OIDC auth from any platform. Current syntax is looked up with context7 against the pinned version. |
| Rotation | A rotation policy for every credential the change introduces, with an explicit interval of 30 to 90 days stated as a number, and what performs the rotation. |
| Placement | No secrets in ConfigMaps, plain environment blocks in IaC, pipeline logs or anything committed. A .env.example with placeholders is committed, never a .env with real values. |
| Access and audit | Audit logging enabled on the secret store and least-privilege access to it. Break-glass access for an incident is documented. |
| Separation | Separate secret values per environment. |
| Verification | A secret is verified by reference or by the consuming service starting, never by printing, echoing or logging its value. Secret scanning in CI with gitleaks or trufflehog. |
How it works
- Discover the cloud, the CI platform and any secrets tooling already present.
- Choose by the decision matrix, or extend the existing mechanism.
- Look up syntax with
context7for the pinned provider or action version. - Implement: store the secret, grant least-privilege read access to exactly the consuming principal, and reference it from the workload.
- Set rotation with an interval, and say what rotates it.
- Enable auditing on the store.
- Document break-glass: who can reach the secret in an incident, and how.
- Verify that the consumer starts and the secret is absent from every log, manifest and state file the change touches.
The skill has no references/ files; everything is in SKILL.md.
Related skills
- Implementing CI/CD Pipelines - where the OIDC wiring actually lands.
- Implementing Terraform Modules - IaC secret resource patterns and state hygiene.
- Deploying to Kubernetes - in-cluster secret delivery.