Back to Security & Vulnerability Analysis

secrets-management

secrets managementsecuritydevopsCI/CDVaultAWS Secrets Managercredentialsautomation
⭐ 36.8kπŸ“„ MITπŸ•’ 2026-06-16Source β†—

Install this skill

npx skills add wshobson/agents

Works across Claude Code, Cursor, Codex, Copilot & Antigravity

Secrets management involves programmatic control over sensitive data like API keys, database credentials, and TLS certificates within automated workflows. Instead of hardcoding plain-text values into scripts or configuration files, this skill focuses on fetching secrets at runtime from specialized vaults or managed cloud providers. By using tools like HashiCorp Vault, AWS Secrets Manager, or GitHub native secret stores, developers ensure that credentials remain encrypted at rest and in transit. This approach emphasizes reducing the blast radius of potential breaches through granular access controls, automatic secret rotation, and audit logs. It is a critical component for maintaining security posture in CI/CD pipelines, preventing accidental exposure of sensitive keys in version control systems while maintaining functional access for deployment processes and application runtime environments.

When to Use This Skill

  • β€’Injecting production database passwords into deployment pipelines without manual entry
  • β€’Providing ephemeral API tokens to ephemeral build containers
  • β€’Managing TLS certificate lifecycle for microservice communication
  • β€’Distributing environment-specific configuration values across staging and production environments

How to Invoke This Skill

Example prompts that trigger this skill in Claude Code, Cursor, or Antigravity:

  • β€œhow do I store API keys securely in my CI/CD pipeline
  • β€œretrieve secrets from HashiCorp Vault during a GitHub action
  • β€œrotate database passwords automatically using AWS secrets manager
  • β€œprevent hardcoding secrets in my infrastructure code
  • β€œconfigure secret injection for a GitLab runner

Pro Tips

  • πŸ’‘Always integrate your secrets management solution with your existing IAM/RBAC systems to enforce the principle of least-privilege access for all secrets.
  • πŸ’‘Automate secret rotation as frequently as possible, even for less critical secrets, to significantly reduce the window of vulnerability.
  • πŸ’‘Regularly audit secret access logs and usage patterns to detect unusual activity or potential breaches and ensure compliance with security policies.

What this skill does

  • β€’Dynamic injection of encrypted variables into CI/CD build environments
  • β€’Automated periodic rotation of database and service account credentials
  • β€’Centralized auditing of secret access patterns and modification history
  • β€’Version control for historical secret retrieval and rollback
  • β€’Provider-agnostic secret abstraction layers for multi-cloud deployments

When not to use it

  • βœ•Storing non-sensitive application configuration that requires public visibility
  • βœ•Local development environments where individual environment variables suffice and cloud vault latency is a hindrance

Example workflow

  1. Define a secret entry in a central vault provider like AWS Secrets Manager
  2. Assign specific read-only IAM permissions to the CI/CD service principal
  3. Update the pipeline configuration to call the vault provider API before application build steps
  4. Map the retrieved secret value to a masking environment variable
  5. Consume the variable within the deployment script
  6. Clear or expire the short-lived credentials post-deployment

Prerequisites

  • –Configured identity provider (IAM roles, service accounts, or OIDC tokens)
  • –Existing vault instance (Vault, AWS Secrets Manager, or cloud-native manager)
  • –Infrastructure access to define secrets and policies

Pitfalls & limitations

  • !Leaking secret values into plain-text build logs via improper echoing
  • !Managing lifecycle drift where secrets expire but rotation policies fail to trigger
  • !Over-permissioning the identity that fetches the secrets

FAQ

Should I store production secrets in my Git repository if they are encrypted?
No, never commit secrets to version control. Even encrypted blobs can become targets for decryption if your repository access is compromised.
How does dynamic secret generation work?
The secret manager generates unique, short-lived credentials on demand for your task, which automatically expire once the process completes.
Can I use the same secrets for different environments?
It is best practice to use separate keys or paths for each environment to prevent cross-environment access if one is compromised.

How it compares

Unlike manual variable entry which risks accidental exposure in log files and configuration history, this automated approach enforces centralized security policies and programmatic rotation that scales across hundreds of services.

Source & trust

⭐ 37k starsπŸ“„ MITπŸ•’ Updated 2026-06-16
πŸ“„ Full skill instructions β€” original source: wshobson/agents
# Secrets Management

Secure secrets management practices for CI/CD pipelines using Vault, AWS Secrets Manager, and other tools.

## Purpose

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

## When to Use

- Store API keys and credentials
- Manage database passwords
- Handle TLS certificates
- Rotate secrets automatically
- Implement least-privilege access

## Secrets Management Tools

### HashiCorp Vault

- Centralized secrets management
- Dynamic secrets generation
- Secret rotation
- Audit logging
- Fine-grained access control

### AWS Secrets Manager

- AWS-native solution
- Automatic rotation
- Integration with RDS
- CloudFormation support

### Azure Key Vault

- Azure-native solution
- HSM-backed keys
- Certificate management
- RBAC integration

### Google Secret Manager

- GCP-native solution
- Versioning
- IAM integration

## HashiCorp Vault Integration

### Setup Vault

# Start Vault dev server
vault server -dev

# Set environment
export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='root'

# Enable secrets engine
vault secrets enable -path=secret kv-v2

# Store secret
vault kv put secret/database/config username=admin password=secret


### GitHub Actions with Vault

name: Deploy with Vault Secrets

on: [push]

jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

- name: Import Secrets from Vault
uses: hashicorp/vault-action@v2
with:
url: https://vault.example.com:8200
token: ${{ secrets.VAULT_TOKEN }}
secrets: |
secret/data/database username | DB_USERNAME ;
secret/data/database password | DB_PASSWORD ;
secret/data/api key | API_KEY

- name: Use secrets
run: |
echo "Connecting to database as $DB_USERNAME"
# Use $DB_PASSWORD, $API_KEY


### GitLab CI with Vault

deploy:
image: vault:latest
before_script:
- export VAULT_ADDR=https://vault.example.com:8200
- export VAULT_TOKEN=$VAULT_TOKEN
- apk add curl jq
script:
- |
DB_PASSWORD=$(vault kv get -field=password secret/database/config)
API_KEY=$(vault kv get -field=key secret/api/credentials)
echo "Deploying with secrets..."
# Use $DB_PASSWORD, $API_KEY


**Reference:** See references/vault-setup.md

## AWS Secrets Manager

### Store Secret

aws secretsmanager create-secret \
--name production/database/password \
--secret-string "super-secret-password"


### Retrieve in GitHub Actions

- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-west-2

- name: Get secret from AWS
run: |
SECRET=$(aws secretsmanager get-secret-value \
--secret-id production/database/password \
--query SecretString \
--output text)
echo "::add-mask::$SECRET"
echo "DB_PASSWORD=$SECRET" >> $GITHUB_ENV

- name: Use secret
run: |
# Use $DB_PASSWORD
./deploy.sh


### Terraform with AWS Secrets Manager

data "aws_secretsmanager_secret_version" "db_password" {
secret_id = "production/database/password"
}

resource "aws_db_instance" "main" {
allocated_storage = 100
engine = "postgres"
instance_class = "db.t3.large"
username = "admin"
password = jsondecode(data.aws_secretsmanager_secret_version.db_password.secret_string)["password"]
}


## GitHub Secrets

### Organization/Repository Secrets

- name: Use GitHub secret
run: |
echo "API Key: ${{ secrets.API_KEY }}"
echo "Database URL: ${{ secrets.DATABASE_URL }}"


### Environment Secrets

deploy:
runs-on: ubuntu-latest
environment: production
steps:
- name: Deploy
run: |
echo "Deploying with ${{ secrets.PROD_API_KEY }}"


**Reference:** See references/github-secrets.md

## GitLab CI/CD Variables

### Project Variables

deploy:
script:
- echo "Deploying with $API_KEY"
- echo "Database: $DATABASE_URL"


### Protected and Masked Variables

- Protected: Only available in protected branches
- Masked: Hidden in job logs
- File type: Stored as file

## Best Practices

1. **Never commit secrets** to Git
2. **Use different secrets** per environment
3. **Rotate secrets regularly**
4. **Implement least-privilege access**
5. **Enable audit logging**
6. **Use secret scanning** (GitGuardian, TruffleHog)
7. **Mask secrets in logs**
8. **Encrypt secrets at rest**
9. **Use short-lived tokens** when possible
10. **Document secret requirements**

## Secret Rotation

### Automated Rotation with AWS

import boto3
import json

def lambda_handler(event, context):
client = boto3.client('secretsmanager')

# Get current secret
response = client.get_secret_value(SecretId='my-secret')
current_secret = json.loads(response['SecretString'])

# Generate new password
new_password = generate_strong_password()

# Update database password
update_database_password(new_password)

# Update secret
client.put_secret_value(
SecretId='my-secret',
SecretString=json.dumps({
'username': current_secret['username'],
'password': new_password
})
)

return {'statusCode': 200}


### Manual Rotation Process

1. Generate new secret
2. Update secret in secret store
3. Update applications to use new secret
4. Verify functionality
5. Revoke old secret

## External Secrets Operator

### Kubernetes Integration

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: vault-backend
namespace: production
spec:
provider:
vault:
server: "https://vault.example.com:8200"
path: "secret"
version: "v2"
auth:
kubernetes:
mountPath: "kubernetes"
role: "production"

---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: database-credentials
namespace: production
spec:
refreshInterval: 1h
secretStoreRef:
name: vault-backend
kind: SecretStore
target:
name: database-credentials
creationPolicy: Owner
data:
- secretKey: username
remoteRef:
key: database/config
property: username
- secretKey: password
remoteRef:
key: database/config
property: password


## Secret Scanning

### Pre-commit Hook

#!/bin/bash
# .git/hooks/pre-commit

# Check for secrets with TruffleHog
docker run --rm -v "$(pwd):/repo" \
trufflesecurity/trufflehog:latest \
filesystem --directory=/repo

if [ $? -ne 0 ]; then
echo "❌ Secret detected! Commit blocked."
exit 1
fi


### CI/CD Secret Scanning

secret-scan:
stage: security
image: trufflesecurity/trufflehog:latest
script:
- trufflehog filesystem .
allow_failure: false


## Reference Files

- references/vault-setup.md - HashiCorp Vault configuration
- references/github-secrets.md - GitHub Secrets best practices

## Related Skills

- github-actions-templates - For GitHub Actions integration
- gitlab-ci-patterns - For GitLab CI integration
- deployment-pipeline-design - For pipeline architecture

How to Use This Skill Unit

Option A: Project-Specific (Recommended)

  1. Click "Download" above
  2. In your project, create the directory: .agent/skills/secrets-management/
  3. Save the file as SKILL.md
  4. The agent will automatically discover the skill based on its description.

Option B: Global Installation (All Agents)

Save the file to these locations to make it available across all projects:

  • Claude Code: ~/.claude/skills/wshobson/agents/secrets-management/SKILL.md
  • Cursor: ~/.cursor/skills/wshobson/agents/secrets-management/SKILL.md
  • Antigravity: ~/.gemini/antigravity/skills/wshobson/agents/secrets-management/SKILL.md

πŸš€ Install with CLI:
npx skills add wshobson/agents

Read the Master Guide: Mastering Agent Skills β†’

Recommended Rules

View more rules β†’

Recommended Workflows

View more workflows β†’

Recommended MCP Servers

View more MCP servers β†’

Take It Further

Maximize your productivity with these powerful resources

πŸ“‹

Define Your Standards

Set up coding standards to ensure this workflow produces consistent, high-quality results.

Browse Rules Library
πŸ“–

Master Workflows

Learn how to create custom workflows, use Turbo Mode, and build your automation library.

Complete Guide

How to use this Skill in Claude Code & Cursor

For Claude Code (CLI)

To use this skill in Claude Code, copy the rule content into your project's custom instructions or follow our Add-Skill CLI guide. This ensures Claude follows your standards during every code generation.

For Cursor & Windsurf

For Cursor or Windsurf, individual skills are best used in the "Rules for AI" section. This specific unit helps the agent avoid security & vulnerability analysis issues, leading to cleaner, more efficient code.

Why the skill format matters: the standardized Agent Skills format lets your AI agent load detailed instructions only when they are relevant, keeping your prompt clean while improving results.

Source & attribution

This skill is categorized under Security & Vulnerability Analysis and is published by W. Shobson, maintained in wshobson/agents.

← Browse All Agent Skills
Sponsored AI assistant. Recommendations may be paid.