菜单
Secrets management patterns for cloud and Kubernetes environments. Use when implementing secure credential storage, rotation, or CI/CD authentication.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Perform code review. Quality analysis. Acceptance criteria verification. Best practices review.
Transform extracted epics and user stories into Jira-ready format following a benchmark template. Handles field mapping, formatting for Jira markdown compatibility, two-gate user review, and guidance for Jira issue creation via Atlassian tools.
Identify and structure epics and user stories from workshop materials (cleaned transcripts, Figma designs, codebase analysis, and other documents). Produces a business-oriented task breakdown with dependencies, assumptions, and open questions.
Analyze extracted epics and user stories for quality gaps, missing edge cases, and improvement opportunities. Runs domain-agnostic analysis passes, optionally enriches findings with Jira board context, and produces accept/reject suggestions that refine the task list before Jira formatting.
Design the architecture to solve a given task. Propose the solutions to be used to deliver the task following the best practices and standards.
Discover and establish technical context before implementing any feature. Prioritize project instructions, existing codebase patterns, and external documentation in that order. Use for any task requiring understanding of project conventions, coding standards, architecture patterns, and established practices before writing code.
| name | tsh-managing-secrets |
| description | Secrets management patterns for cloud and Kubernetes environments. Use when implementing secure credential storage, rotation, or CI/CD authentication. |
| user-invocable | false |
| Scenario | Recommended Solution |
|---|---|
| Single cloud, simple apps | Cloud-native (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) |
| Multi-cloud / hybrid | HashiCorp Vault |
| GitOps with Kubernetes | Sealed Secrets or External Secrets Operator |
| Local dev / small teams | SOPS with age/GPG |
| CI/CD → Cloud | OIDC federation (no long-lived keys) |
Check which cloud provider the project uses:
*.tf with provider "aws" → AWS Secrets Manager*.tf with provider "azurerm" → Azure Key Vault*.tf with provider "google" → GCP Secret ManagerUse context7 or cloud documentation MCP to look up provider-specific syntax.
Check for existing patterns:
SealedSecret resources → Bitnami Sealed SecretsExternalSecret resources → External Secrets Operator*.enc.yaml files → SOPS encryptionvault-agent sidecars → HashiCorp Vault| CI Platform | Cloud | Approach |
|---|---|---|
| GitHub Actions | AWS | OIDC with aws-actions/configure-aws-credentials |
| GitHub Actions | Azure | OIDC with azure/login |
| GitHub Actions | GCP | OIDC with google-github-actions/auth |
| GitLab CI | AWS/GCP | OIDC with CI_JOB_JWT |
| Bitbucket | AWS | Repository variables + assume role |
| Any | Any | HashiCorp Vault with JWT/OIDC auth |
Rule: Always prefer OIDC federation over long-lived access keys.
context7 or cloud MCP for current syntax| ❌ Don't | ✅ Do |
|---|---|
| Hardcode secrets in code | Use secret references |
Commit .env files | Use .env.example with placeholders |
| Share secrets via Slack/email | Use secret manager with access control |
| Same secret across environments | Separate secrets per environment |
| Long-lived CI/CD credentials | OIDC federation with short-lived tokens |
| Secrets in ConfigMaps | Use Kubernetes Secrets (encrypted at rest) |
tsh-implementing-ci-cd - For pipeline credential setuptsh-implementing-terraform-modules - For IaC secret resource patternstsh-optimizing-cloud-cost - Secret manager pricing considerations