How do I install the Tsh Managing Secrets skill?

Run npx skillmds@latest add thesoftwarehouse/tsh-managing-secrets in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Tsh Managing Secrets safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Tsh Managing Secrets?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Tsh Managing Secrets free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Tsh Managing Secrets?

TheSoftwareHouse (@thesoftwarehouse) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Tsh Managing Secrets by thesoftwarehouse

Name: Tsh Managing Secrets
Rating: 4.5 (4 reviews)
Author: TheSoftwareHouse

File contents

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:

*.tf with provider "aws" → AWS Secrets Manager
*.tf with provider "azurerm" → Azure Key Vault
*.tf with provider "google" → GCP Secret Manager

Use context7 or cloud documentation MCP to look up provider-specific syntax.

Kubernetes Secrets Detection

Check for existing patterns:

SealedSecret resources → Bitnami Sealed Secrets
ExternalSecret resources → External Secrets Operator
*.enc.yaml files → SOPS encryption
vault-agent sidecars → 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 context7 or 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 setup
tsh-implementing-terraform-modules - For IaC secret resource patterns
tsh-optimizing-cloud-cost - Secret manager pricing considerations

---name: tsh-managing-secretsdescription: 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 DetectionCheck 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.## Kubernetes Secrets DetectionCheck for existing patterns:- `SealedSecret` resources → Bitnami Sealed Secrets- `ExternalSecret` resources → External Secrets Operator- `*.enc.yaml` files → SOPS encryption- `vault-agent` sidecars → 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.## Process1. **Discover context** → Check existing secret patterns in codebase2. **Choose solution** → Use decision matrix based on scenario3. **Look up implementation** → Use `context7` or cloud MCP for current syntax4. **Implement rotation** → Set rotation policy (30-90 days for credentials)5. **Enable auditing** → Configure access logging on secret store6. **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 setup- `tsh-implementing-terraform-modules` - For IaC secret resource patterns- `tsh-optimizing-cloud-cost` - Secret manager pricing considerations

Frequently asked questions

Tsh Managing Secrets