agentleFS
SuarezPMSuarezPM/Apohara-Catalyst/.agents/skills/secrets-management/SKILL.md

secrets-management

Skill1 starsChanged 6 months agoMITView on GitHub

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.

  • Reads credentials

33 other projects use a version of this, 12 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use background-jobs, input-validation and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • YepAPISkill

    background-jobs

    Queue workers with BullMQ/Inngest/Trigger.dev, job retries, dead letter queues, concurrency.

    Also in 3 projects that use this

  • hereshecodesSkill

    input-validation

    Use when processing user input, form data, file uploads, or query parameters

    Also in 3 projects that use this

  • mattpartidaSkill

    agent-security

    Review and harden OpenClaw/Hermes agent security, including tool permissions, elevated access, exec approvals, allowlists, sandboxing, browser and web exposure, prompt-injection risk, model risk, persistence, and personal-vs-shared trust boundaries. Use when the task is primarily about agent or runtime security rather than host firewall or OS hardening.

    Also in 3 projects that use this

  • harperaaSkill

    rate-limiting

    Implement rate limiting to prevent brute force attacks, spam, and resource abuse. Use this skill when you need to protect endpoints from automated attacks, prevent API abuse, limit request frequency, or control infrastructure costs. Triggers include "rate limiting", "rate limit", "brute force", "prevent spam", "API abuse", "resource exhaustion", "DoS", "withRateLimit", "too many requests", "429 error".

    Also in 3 projects that use this

  • jefflesterSkill

    api-security

    API security best practices and common vulnerability prevention. Enforces security checks for authentication, input validation, SQL injection, XSS, and OWASP Top 10 vulnerabilities. Use when building or modifying APIs.

    Also in 4 projects that use this

  • MicrosoftSkill

    supply-chain-security

    Activate when reviewing or modifying dependency resolution, lockfile schema, package downloaders, signature/integrity checks, file integration cleanup, or anything that could expose APM to dependency confusion, typosquatting, malicious packages, or token leakage.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 30 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use short-lived tokens: when possible

    line 228
  2. Distinctive:

    Update secret in secret store

    line 267
  3. Distinctive:

    Update applications to use new secret

    line 268

“Common” is measured: kept by at least 6 in 10 of the 30 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

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

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.