PluginBench
Skill
Review
Audit score 70

secrets-management

wshobson/agents

Secure secrets management for CI/CD pipelines using Vault, AWS Secrets Manager, and platform-native solutions.

What is secrets-management?

Implement secure storage and rotation of sensitive credentials, API keys, and certificates in CI/CD environments. Use this skill when handling secrets that must never be hardcoded, need automatic rotation, or require audit logging and fine-grained access control.

  • Store and retrieve API keys, database passwords, and TLS certificates securely
  • Integrate with HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Secret Manager
  • Automate secret rotation with scheduled jobs or event-driven triggers
  • Implement least-privilege access control with audit logging
  • Mask secrets in CI/CD logs to prevent accidental exposure
  • Scan repositories for accidentally committed secrets using tools like TruffleHog

How to install secrets-management

npx skills add https://github.com/wshobson/agents --skill secrets-management
Prerequisites
  • Access to a secrets management platform (Vault, AWS Secrets Manager, Azure Key Vault, or GitHub/GitLab native secrets)
  • CI/CD platform configured (GitHub Actions, GitLab CI, or similar)
  • Appropriate IAM or RBAC permissions to create and manage secrets
Claude Code
Cursor
Windsurf
Cline

How to use secrets-management

  1. 1.Choose a secrets management solution based on your infrastructure (Vault for on-prem, AWS Secrets Manager for AWS, GitHub Secrets for GitHub Actions)
  2. 2.Store sensitive values in your chosen platform using the provided setup commands or UI
  3. 3.Configure your CI/CD pipeline to authenticate with the secrets manager using the provided workflow examples
  4. 4.Reference secrets as environment variables in your pipeline jobs, ensuring they are masked in logs
  5. 5.Implement automatic secret rotation using the provided Lambda function or manual rotation process
  6. 6.Add secret scanning to your CI/CD pipeline using TruffleHog or similar tools to catch accidental commits

Use cases

Good for
  • Inject database credentials into GitHub Actions or GitLab CI workflows without hardcoding them
  • Rotate RDS passwords automatically using AWS Lambda and Secrets Manager
  • Sync Vault secrets to Kubernetes pods using External Secrets Operator
  • Retrieve API keys in Terraform configurations for infrastructure provisioning
  • Prevent secret leaks by scanning commits with pre-commit hooks before they reach the repository
Who it's for
  • DevOps engineers managing CI/CD pipelines
  • Platform engineers securing multi-environment deployments
  • Security teams implementing credential management policies
  • Application developers integrating secrets into deployment workflows

secrets-management FAQ

Should I use platform-native secrets (GitHub Secrets, GitLab Variables) or a dedicated tool like Vault?

Use platform-native secrets for simple deployments with few secrets and a single environment. Use Vault or AWS Secrets Manager for complex multi-environment setups, automatic rotation requirements, or when you need centralized audit logging and fine-grained access control across teams.

How do I prevent secrets from being printed in CI/CD logs?

Use the `echo '::add-mask::$SECRET'` command in GitHub Actions or mark variables as masked in GitLab CI. The provided examples show this pattern. Never use `echo` or `print` statements with secrets in production.

How often should I rotate secrets?

Rotate credentials every 30–90 days depending on sensitivity and compliance requirements. Use automatic rotation where possible (AWS Secrets Manager supports this natively). The skill includes a Lambda example for automating rotation.

Can I use secrets management with Kubernetes?

Yes. The skill includes an External Secrets Operator example that syncs secrets from Vault or other backends into Kubernetes as native Secret objects, refreshing them automatically.

What's the difference between storing a secret as a file vs. an environment variable?

Environment variables are simpler for most use cases and are automatically masked in logs. File-based secrets are useful for large payloads (certificates, keys) or when tools expect file paths. GitLab CI supports both; choose based on your application's needs.

Full instructions (SKILL.md)

Source of truth, from wshobson/agents.


name: secrets-management description: Implement secure secrets management for CI/CD pipelines using Vault, AWS Secrets Manager, or native platform solutions. Use when handling sensitive credentials, rotating secrets, or securing CI/CD environments.

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:1.17
  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

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
  env:
    API_KEY: ${{ secrets.API_KEY }}
    DATABASE_URL: ${{ secrets.DATABASE_URL }}
  run: |
    # Secrets are injected as env vars — never print them to logs
    ./deploy.sh

Environment Secrets

deploy:
  runs-on: ubuntu-latest
  environment: production
  steps:
    - name: Deploy
      env:
        PROD_API_KEY: ${{ secrets.PROD_API_KEY }}
      run: |
        # Secret injected as env var — never print to logs
        ./deploy.sh

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:3.88 \
  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:3.88
  script:
    - trufflehog filesystem .
  allow_failure: false

Related Skills

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