thesoftwarehouse/tsh-managing-secrets
.github/skills/tsh-managing-secrets/SKILL.md
Secrets management patterns for cloud and Kubernetes environments. Use when implementing secure credential storage, rotation, or CI/CD authentication.
$ install --global
skillsauthnpx skillsauth add thesoftwarehouse/copilot-collections tsh-managing-secretsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 15, 2026, 11:58 PM8.2s1 file scanned
SKILL.md
- name:
- tsh-managing-secrets
- description:
- Secrets management patterns for cloud and Kubernetes environments. Use when implementing secure credential storage, rotation, or CI/CD authentication.
Secrets Management
When to Use
- Storing application credentials securely
- Configuring CI/CD authentication
- Implementing secrets rotation
- Setting up GitOps-compatible secret management
Solution Decision Matrix
| 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) |
Cloud-Native Detection
Check which cloud provider the project uses:
*.tfwithprovider "aws"→ AWS Secrets Manager*.tfwithprovider "azurerm"→ Azure Key Vault*.tfwithprovider "google"→ GCP Secret Manager
Use context7 or cloud documentation MCP to look up provider-specific syntax.
Kubernetes Secrets Detection
Check for existing patterns:
SealedSecretresources → Bitnami Sealed SecretsExternalSecretresources → External Secrets Operator*.enc.yamlfiles → SOPS encryptionvault-agentsidecars → HashiCorp Vault
CI/CD Credentials Decision
| 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.
Process
- Discover context → Check existing secret patterns in codebase
- Choose solution → Use decision matrix based on scenario
- Look up implementation → Use
context7or cloud MCP for current syntax - Implement rotation → Set rotation policy (30-90 days for credentials)
- Enable auditing → Configure access logging on secret store
- Document break-glass → Define emergency access procedure
Security Checklist
- [ ] No secrets in code, environment variables visible in UI, or logs
- [ ] Rotation policy defined (30-90 days for credentials)
- [ ] Least privilege access to secret stores
- [ ] Audit logging enabled on all secret access
- [ ] OIDC used for CI/CD (no long-lived access keys)
- [ ] Secrets encrypted at rest and in transit
- [ ] Break-glass procedure documented
- [ ] Secret scanning enabled in CI (gitleaks, trufflehog)
Anti-Patterns
| ❌ 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) |
Related Skills
tsh-implementing-ci-cd- For pipeline credential setuptsh-implementing-terraform-modules- For IaC secret resource patternstsh-optimizing-cloud-cost- Secret manager pricing considerations
Related Skills
thesoftwarehouse/tsh-writing-hooks
development
VerifiedTrustedCommunity
Custom hook and composable patterns — naming, composition, stable return shapes, lifecycle cleanup, and testing strategies. Use when writing reusable logic units (React hooks, Vue composables), refactoring logic into hooks, debugging hook behavior, or reviewing hook implementations.
206SKILL.mdUpdated Apr 15, 2026
thesoftwarehouse/tsh-ui-verifying
testing
VerifiedTrustedCommunity
UI verification criteria, structure checklists, severity definitions, and tolerance rules for comparing implementations against Figma designs. Use for verifying UI matches design, understanding what to check, and determining acceptable differences.
206SKILL.mdUpdated Apr 15, 2026
thesoftwarehouse/tsh-transcript-processing
development
VerifiedTrustedCommunity
Clean raw workshop or meeting transcripts from small talk, filler words, and off-topic tangents. Extract and structure business-relevant content into a standardized format with discussion topics, key decisions, action items, and open questions.
206SKILL.mdUpdated Apr 15, 2026
thesoftwarehouse/tsh-technical-context-discovering
development
VerifiedTrustedCommunity
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.
206SKILL.mdUpdated Apr 15, 2026