Token导航 LogoToken导航

Agent Skill · 研究检索

secrets-management(秘密管理)

用于辅助安全审计、权限检查、凭据风险、认证流程和常见漏洞排查。它适合让 Agent 梳理敏感配置、检查依赖风险、分析鉴权逻辑或生成安全复核清单。使用时不能把工具输出直接当最终结论,涉及密钥、令牌、用户数据或生产系统时,应先确认最小权限、脱敏方式和操作边界。

secrets-management 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为接触敏感数据;许可证为 MIT,暂无第三方扫描结果,按安装量在研究检索类的 73,675 个 Skill 里排第 61,288。

总安装 353周安装 15GitHub Stars 公开资料未说明下载 124核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:secrets-management(秘密管理)
来源仓库:https://github.com/melodic-software/claude-code-plugins
仓库路径:skills/secrets-management
安装命令:
npx skills add melodic-software/claude-code-plugins --skill "secrets-management"
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

AgentSkills.tonpx skills
npx skills add melodic-software/claude-code-plugins --skill "secrets-management"

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

辅助安全审计、权限检查和常见漏洞排查。适用于代码审查和安全加固场景。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。帮助识别敏感信息和认证风险点。不能替代专业安全评估,需人工复核关键结论。

secrets-management 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/secrets-management

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add melodic-software/claude-code-plugins --skill "secrets-management";命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要接触敏感数据,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

secrets-management 怎么安装?

在终端执行 npx skills add melodic-software/claude-code-plugins --skill "secrets-management"。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

secrets-management 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

secrets-management 需要什么权限?

权限级别是接触敏感数据。该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

secrets-management 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

secrets-management 用的人多吗?

公开数据是累计安装 353 次,近一周安装 15 次,下载 124 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

secrets-management 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 需要接触敏感数据,装到常用环境前要先评估影响面。
  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 环境里有大量密钥、凭证,不方便给第三方 Skill 读取的人。
  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
secrets-management

秘密管理 · 本页

353—接触敏感数据MIT未收录

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

name
secrets-management
description
Use when designing secret storage, rotation, or credential management systems. Covers HashiCorp Vault patterns, AWS Secrets Manager, Azure Key Vault, secret rotation, and zero-knowledge architectures.
allowed-tools
Read, Glob, Grep

Secrets Management

Comprehensive guide to managing secrets, credentials, and sensitive configuration - from storage to rotation to access control.

When to Use This Skill

  • Designing secret storage architecture
  • Implementing secret rotation
  • Integrating applications with secret stores
  • Managing API keys, passwords, certificates
  • Understanding Vault, AWS Secrets Manager, Azure Key Vault
  • Zero-knowledge and envelope encryption patterns

Secrets Management Fundamentals

What Are Secrets?

Types of Secrets:

Credentials:
├── Database passwords
├── API keys
├── OAuth client secrets
├── SSH private keys
└── Service account tokens

Certificates:
├── TLS certificates and private keys
├── Code signing certificates
├── Client certificates
└── CA certificates

Encryption Keys:
├── Data encryption keys (DEK)
├── Key encryption keys (KEK)
├── HMAC keys
└── Signing keys

Sensitive Configuration:
├── Connection strings
├── License keys
├── Webhook URLs with tokens
└── Third-party credentials

Secrets Lifecycle

Secret Lifecycle:

1. Generation
   └── Create with sufficient entropy
   └── Use cryptographic randomness
   └── Appropriate key length

2. Storage
   └── Encrypt at rest
   └── Access control
   └── Audit logging

3. Distribution
   └── Secure transport (TLS)
   └── Just-in-time access
   └── Minimize copies

4. Usage
   └── Memory protection
   └── Minimize exposure window
   └── Clear after use

5. Rotation
   └── Regular schedule
   └── Zero-downtime rotation
   └── Update all consumers

6. Revocation
   └── Immediate effect
   └── Propagate to all systems
   └── Audit trail

7. Destruction
   └── Secure deletion
   └── Verify removal
   └── Clear backups

Architecture Patterns

Centralized Secret Store

Centralized Architecture:

┌─────────────────────────────────────────────────┐
│              Secret Store                        │
│  ┌─────────────────────────────────────────┐    │
│  │  • Encrypted storage                    │    │
│  │  • Access control                       │    │
│  │  • Audit logging                        │    │
│  │  • Rotation management                  │    │
│  │  • High availability                    │    │
│  └─────────────────────────────────────────┘    │
└─────────────────────┬───────────────────────────┘
                      │
        ┌─────────────┼─────────────┐
        │             │             │
   ┌────▼────┐  ┌────▼────┐  ┌────▼────┐
   │ App A   │  │ App B   │  │ App C   │
   │         │  │         │  │         │
   │Fetches  │  │Fetches  │  │Fetches  │
   │secrets  │  │secrets  │  │secrets  │
   │on start │  │on demand│  │cached   │
   └─────────┘  └─────────┘  └─────────┘

Benefits:
+ Single source of truth
+ Centralized audit
+ Consistent policies
+ Easier rotation

Challenges:
- Single point of failure
- Network dependency
- Latency for secret access

Envelope Encryption

Envelope Encryption:

┌─────────────────────────────────────────────────┐
│                 Key Hierarchy                    │
│                                                  │
│  ┌─────────────┐                                │
│  │ Master Key  │  (Never leaves KMS)            │
│  │   (KEK)     │                                │
│  └──────┬──────┘                                │
│         │ Encrypts                              │
│         ▼                                       │
│  ┌─────────────┐                                │
│  │  Data Key   │  (Wrapped/encrypted)           │
│  │   (DEK)     │                                │
│  └──────┬──────┘                                │
│         │ Encrypts                              │
│         ▼                                       │
│  ┌─────────────┐                                │
│  │    Data     │  (Your secrets/data)           │
│  │             │                                │
│  └─────────────┘                                │
└─────────────────────────────────────────────────┘

Flow:
1. Generate DEK locally
2. Encrypt data with DEK
3. Send DEK to KMS for wrapping with KEK
4. Store: encrypted data + wrapped DEK
5. To decrypt: unwrap DEK with KMS, decrypt data

Benefits:
- Master key never exposed
- Can rotate DEK without re-encrypting all data
- Distributed encryption (KMS not a bottleneck)

Zero-Knowledge Architecture

Zero-Knowledge Secret Access:

                                    ┌──────────────┐
                                    │    Client    │
                                    │              │
                                    │ Has: secret  │
                                    │ key derived  │
                                    │ from password│
                                    └──────┬───────┘
                                           │
                    ┌──────────────────────▼───────────────────────┐
                    │                   Server                      │
                    │                                               │
                    │  Stores: encrypted secrets                    │
                    │  Cannot decrypt (doesn't have key)            │
                    │                                               │
                    │  User's secrets = Encrypt(data, userDerivedKey)│
                    └───────────────────────────────────────────────┘

Properties:
- Server cannot read secrets even if compromised
- User password never transmitted
- Key derived client-side using KDF
- Server only sees encrypted blobs

Trade-offs:
+ Maximum privacy
+ Server breach doesn't expose secrets
- Can't recover if user forgets password
- Can't audit what's stored
- Server can't validate secrets

HashiCorp Vault

Vault Architecture

Vault Components:

┌─────────────────────────────────────────────────────┐
│                     Vault                            │
│                                                      │
│  ┌──────────────────────────────────────────────┐  │
│  │                 API Layer                     │  │
│  │  (HTTP/HTTPS interface for all operations)   │  │
│  └─────────────────────┬────────────────────────┘  │
│                        │                            │
│  ┌─────────────────────▼────────────────────────┐  │
│  │              Auth Methods                     │  │
│  │  Token │ OIDC │ LDAP │ K8s │ AWS │ Azure    │  │
│  └─────────────────────┬────────────────────────┘  │
│                        │                            │
│  ┌─────────────────────▼────────────────────────┐  │
│  │             Secrets Engines                   │  │
│  │  KV │ Database │ PKI │ Transit │ AWS │ SSH   │  │
│  └─────────────────────┬────────────────────────┘  │
│                        │                            │
│  ┌─────────────────────▼────────────────────────┐  │
│  │              Storage Backend                  │  │
│  │  Consul │ Raft │ S3 │ DynamoDB │ etcd        │  │
│  └──────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────┘

Vault Secrets Engines

Common Secrets Engines:

1. KV (Key-Value)
   - Static secrets storage
   - Versioning support
   - Simplest engine

2. Database
   - Dynamic database credentials
   - Auto-rotation
   - Short-lived credentials

   vault write database/roles/my-role \
     db_name=my-database \
     creation_statements="CREATE USER..." \
     default_ttl="1h" \
     max_ttl="24h"

3. PKI
   - Certificate authority
   - Issue short-lived certificates
   - Auto-renewal

4. Transit
   - Encryption as a service
   - Key management
   - Sign/verify operations

5. AWS/Azure/GCP
   - Dynamic cloud credentials
   - IAM role assumption
   - Temporary access

Vault Authentication

Auth Method Selection:

Kubernetes:
- Best for: Pods in Kubernetes
- Identity: Service account token
- Config: Bound namespace/SA

vault auth enable kubernetes
vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes:443" \
   [email protected] 

AppRole:
- Best for: CI/CD, applications
- Identity: Role ID + Secret ID
- Config: Bound CIDR, metadata

vault auth enable approle
vault write auth/approle/role/my-app \
  token_ttl=1h \
  token_max_ttl=4h \
  secret_id_num_uses=1

OIDC:
- Best for: Human users
- Identity: JWT from IdP
- Config: OIDC provider connection

Cloud Secret Managers

AWS Secrets Manager

AWS Secrets Manager Features:

Capabilities:
├── Automatic rotation (Lambda-based)
├── Cross-region replication
├── IAM integration
├── CloudTrail auditing
└── Resource policies

Rotation Flow:
┌─────────────────────────────────────────────────┐
│ 1. createSecret   - Create new secret version  │
│ 2. setSecret      - Update resource (RDS, etc) │
│ 3. testSecret     - Verify new secret works    │
│ 4. finishSecret   - Mark rotation complete     │
└─────────────────────────────────────────────────┘

Access Pattern:
aws secretsmanager get-secret-value \
  --secret-id my-secret \
  --version-stage AWSCURRENT

SDK Integration:
client = boto3.client('secretsmanager')
response = client.get_secret_value(SecretId='my-secret')
secret = json.loads(response['SecretString'])

Azure Key Vault

Azure Key Vault Features:

Object Types:
├── Secrets - Generic key/value
├── Keys - Cryptographic keys (HSM-backed)
└── Certificates - X.509 certificates

Access Control:
- RBAC (recommended)
- Access policies (legacy)
- Managed identities for Azure resources

Soft Delete + Purge Protection:
- Deleted secrets retained for recovery period
- Purge protection prevents permanent deletion
- Required for compliance scenarios

Integration:
// .NET example with DefaultAzureCredential
var client = new SecretClient(
    new Uri("https://my-vault.vault.azure.net/"),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync("my-secret");

GCP Secret Manager

GCP Secret Manager Features:

Capabilities:
├── Automatic replication (regional/global)
├── IAM integration
├── Audit logging
├── Secret versioning
└── Expiration support

Access Control:
- roles/secretmanager.secretAccessor
- roles/secretmanager.admin
- IAM conditions for fine-grained access

Workload Identity:
- GKE pods use service accounts
- No credential files needed
- Automatic token refresh

Access Pattern:
gcloud secrets versions access latest --secret=my-secret

# Python
from google.cloud import secretmanager
client = secretmanager.SecretManagerServiceClient()
response = client.access_secret_version(name=secret_version_name)
secret = response.payload.data.decode('UTF-8')

Secret Rotation

Zero-Downtime Rotation

Dual-Version Strategy:

Phase 1: Create New Version
┌─────────────────────────────────┐
│ Secret Store                     │
│ ├── Version 1 (current) ✓       │
│ └── Version 2 (pending)  NEW    │
└─────────────────────────────────┘

Phase 2: Update Consumers
┌─────────────────────────────────┐
│ Apps accept: Version 1 OR 2     │
│ Resource updated to Version 2   │
└─────────────────────────────────┘

Phase 3: Verify New Version
┌─────────────────────────────────┐
│ Test connections with Version 2 │
│ Monitor for errors              │
└─────────────────────────────────┘

Phase 4: Deprecate Old Version
┌─────────────────────────────────┐
│ Secret Store                     │
│ ├── Version 1 (deprecated)      │
│ └── Version 2 (current) ✓       │
└─────────────────────────────────┘

Phase 5: Remove Old Version
┌─────────────────────────────────┐
│ Secret Store                     │
│ └── Version 2 (current) ✓       │
└─────────────────────────────────┘

Database Credential Rotation

Database Rotation Pattern:

Approach 1: Dual Users
┌─────────────────────────────────────────────────┐
│ Database has TWO users for the app:            │
│ - app_user_a (current)                          │
│ - app_user_b (standby)                          │
│                                                 │
│ Rotation:                                       │
│ 1. Generate new password for app_user_b        │
│ 2. Update secret to point to app_user_b        │
│ 3. Apps pick up new credentials                │
│ 4. Change app_user_a password (now standby)    │
└─────────────────────────────────────────────────┘

Approach 2: Dynamic Credentials (Vault)
┌─────────────────────────────────────────────────┐
│ Each credential request creates new user:       │
│ - v-app-abc123-ttl-1h (expires in 1 hour)      │
│                                                 │
│ Benefits:                                       │
│ - No rotation needed                            │
│ - Automatic cleanup                             │
│ - Per-request credentials                       │
│                                                 │
│ Vault handles:                                  │
│ - Creating users                                │
│ - Setting expiration                            │
│ - Revoking expired credentials                  │
└─────────────────────────────────────────────────┘

Application Integration

Sidecar Pattern

Sidecar Secret Injection:

┌─────────────────────────────────────────────────┐
│                    Pod                           │
│  ┌─────────────────┐  ┌─────────────────────┐  │
│  │   Vault Agent   │  │      App            │  │
│  │   (Sidecar)     │  │                     │  │
│  │                 │  │                     │  │
│  │  - Authenticates│  │  Reads secrets from │  │
│  │  - Fetches      │──►  /vault/secrets/    │  │
│  │  - Renders      │  │  (shared volume)    │  │
│  │  - Refreshes    │  │                     │  │
│  └─────────────────┘  └─────────────────────┘  │
│            │                    │               │
│            ▼                    │               │
│     [Shared Volume]◄────────────┘               │
│     /vault/secrets/                             │
│     └── db-password                             │
│     └── api-key                                 │
└─────────────────────────────────────────────────┘

CSI Driver Pattern

Secrets Store CSI Driver:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    volumeMounts:
    - name: secrets
      mountPath: "/mnt/secrets"
      readOnly: true
  volumes:
  - name: secrets
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: "vault-database"

---
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: vault-database
spec:
  provider: vault
  parameters:
    vaultAddress: "https://vault:8200"
    roleName: "db-role"
    objects: |
      - objectName: "db-password"
        secretPath: "secret/data/db"
        secretKey: "password"

Best Practices

Security Best Practices:

1. Never Store Secrets In:
   ❌ Source code
   ❌ Environment variables (visible in logs)
   ❌ Container images
   ❌ Kubernetes ConfigMaps
   ❌ Plain text files

2. Access Control:
   □ Least privilege access
   □ Service-specific credentials
   □ Time-limited access where possible
   □ Regular access reviews

3. Audit and Monitoring:
   □ Log all secret access
   □ Alert on unusual patterns
   □ Regular audit reviews
   □ Compliance reporting

4. Rotation:
   □ Automate all rotations
   □ Short credential lifetimes
   □ Test rotation procedures
   □ Document emergency rotation

5. High Availability:
   □ Secret store must be HA
   □ Cache secrets for availability
   □ Graceful degradation plan
   □ Recovery procedures documented

Related Skills

  • zero-trust-architecture - Overall security architecture
  • api-security - API authentication and authorization
  • mtls-service-mesh - Certificate management for services
  • container-orchestration - Kubernetes secrets integration

平台分布

trae

26.59%
按下载量换算33

Antigravity

25.17%
按下载量换算31

windsurf

17.44%
按下载量换算22

Claude Code

12.26%
按下载量换算15

Codex

8.56%
按下载量换算11

Gemini CLI

3.79%
按下载量换算5

安全审计

暂无安全审计结果可展示。

权限和风险

接触敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills