[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AFCMQBGYHC6XYZFDE34AZ6":3,"skill-same:01M6AFCMQBGYHC6XYZFDE34AZ6":113},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":29,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":72,"commitSha":73,"skillDirectory":74,"forksCount":75,"repositoryHtmlUrl":76,"repositoryHomepageUrl":77,"ownerHtmlUrl":78,"ownerBlogUrl":79,"ownerDescription":80,"updatedAt":81,"install":82,"resources":95},"01M6AFCMQBGYHC6XYZFDE34AZ6","implementing-secrets-management-with-vault",null,"Deploy HashiCorp Vault for centralized secrets management, covering dynamic secret generation for databases and cloud providers, transit encryption, PKI certificate management, and Kubernetes integration. Use when eliminating hardcoded credentials from application code or CI\u002FCD pipelines, migrating to short-lived auto-rotated secrets, or giving Kubernetes workloads secure access to database or cloud provider credentials.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",36078,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-secrets-management-with-vault\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"implementing secrets management with vault","encryption","secrets-management","dynamic-secrets","HashiCorp-Vault","Providers","t1078","t1003","pki","zero-trust","kubernetes","ZeRO","cloud-security","ci","database","code","pr","secure","cybersecurity","security","2026-11-10 10:12:30",false,"---\nname: implementing-secrets-management-with-vault\ndescription: 'Deploy HashiCorp Vault for centralized secrets management, covering dynamic\n  secret generation for databases and cloud providers, transit encryption, PKI certificate\n  management, and Kubernetes integration. Use when eliminating hardcoded credentials\n  from application code or CI\u002FCD pipelines, migrating to short-lived auto-rotated\n  secrets, or giving Kubernetes workloads secure access to database or cloud provider\n  credentials.\n\n  '\ndomain: cybersecurity\nsubdomain: cloud-security\ntags:\n- hashicorp-vault\n- secrets-management\n- dynamic-secrets\n- credential-rotation\n- zero-trust\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.IR-01\n- ID.AM-08\n- GV.SC-06\n- DE.CM-01\nmitre_attack:\n- T1078.004\n- T1530\n- T1537\n- T1580\n- T1003\n---\n\n# Implementing Secrets Management with Vault\n\n## When to Use\n\n- When applications store database passwords, API keys, or certificates in environment variables or config files\n- When migrating from static long-lived credentials to dynamic short-lived secrets\n- When Kubernetes workloads need secure access to database credentials or cloud provider APIs\n- When compliance requirements mandate centralized credential management with audit logging\n- When CI\u002FCD pipelines contain hardcoded secrets that represent supply chain risk\n\n**Do not use** for AWS-only environments where AWS Secrets Manager suffices without multi-cloud requirements, for application-level encryption logic (though Vault Transit can help), or for identity federation (see managing-cloud-identity-with-okta).\n\n## Prerequisites\n\n- HashiCorp Vault server deployed in HA mode (Consul or Raft storage backend)\n- TLS certificates for Vault listener endpoints\n- Vault Enterprise license for namespaces, Sentinel policies, and replication (optional)\n- Kubernetes cluster with Vault Agent Injector or CSI provider for workload integration\n\n## Workflow\n\n### Step 1: Deploy Vault in High Availability Mode\n\nDeploy Vault using Integrated Storage (Raft) for HA without external dependencies. Configure TLS, audit logging, and auto-unseal using a cloud KMS.\n\n```hcl\n# vault-config.hcl\nstorage \"raft\" {\n  path    = \"\u002Fopt\u002Fvault\u002Fdata\"\n  node_id = \"vault-node-1\"\n\n  retry_join {\n    leader_api_addr = \"https:\u002F\u002Fvault-node-2.internal:8200\"\n  }\n  retry_join {\n    leader_api_addr = \"https:\u002F\u002Fvault-node-3.internal:8200\"\n  }\n}\n\nlistener \"tcp\" {\n  address     = \"0.0.0.0:8200\"\n  tls_cert_file = \"\u002Fopt\u002Fvault\u002Ftls\u002Fvault.crt\"\n  tls_key_file  = \"\u002Fopt\u002Fvault\u002Ftls\u002Fvault.key\"\n}\n\nseal \"awskms\" {\n  region     = \"us-east-1\"\n  kms_key_id = \"alias\u002Fvault-unseal-key\"\n}\n\napi_addr      = \"https:\u002F\u002Fvault-node-1.internal:8200\"\ncluster_addr  = \"https:\u002F\u002Fvault-node-1.internal:8201\"\n\ntelemetry {\n  prometheus_retention_time = \"30s\"\n  disable_hostname         = true\n}\n```\n\n```bash\n# Initialize Vault\nvault operator init -key-shares=5 -key-threshold=3\n\n# Enable audit logging\nvault audit enable file file_path=\u002Fvar\u002Flog\u002Fvault\u002Faudit.log\n\n# Enable syslog audit for SIEM integration\nvault audit enable syslog tag=\"vault\" facility=\"AUTH\"\n```\n\n### Step 2: Configure Authentication Methods\n\nEnable authentication backends for human operators, applications, and CI\u002FCD pipelines. Use AppRole for machine authentication and OIDC for human access.\n\n```bash\n# Enable OIDC auth for human users via Okta\nvault auth enable oidc\nvault write auth\u002Foidc\u002Fconfig \\\n  oidc_discovery_url=\"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\" \\\n  oidc_client_id=\"vault-client-id\" \\\n  oidc_client_secret=\"vault-client-secret\" \\\n  default_role=\"default\"\n\n# Enable AppRole for application authentication\nvault auth enable approle\nvault write auth\u002Fapprole\u002Frole\u002Fweb-app \\\n  secret_id_ttl=10m \\\n  token_num_uses=10 \\\n  token_ttl=20m \\\n  token_max_ttl=30m \\\n  secret_id_num_uses=1 \\\n  token_policies=\"web-app-policy\"\n\n# Enable Kubernetes auth for pod-based access\nvault auth enable kubernetes\nvault write auth\u002Fkubernetes\u002Fconfig \\\n  kubernetes_host=\"https:\u002F\u002Fkubernetes.default.svc:443\" \\\n  token_reviewer_jwt=@\u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Ftoken \\\n  kubernetes_ca_cert=@\u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Fca.crt\n```\n\n### Step 3: Enable Dynamic Secret Engines\n\nConfigure database secret engines to generate short-lived credentials on demand. Each credential set has a TTL and is automatically revoked when it expires.\n\n```bash\n# Enable database secrets engine for PostgreSQL\nvault secrets enable database\nvault write database\u002Fconfig\u002Fproduction-db \\\n  plugin_name=postgresql-database-plugin \\\n  allowed_roles=\"readonly,readwrite\" \\\n  connection_url=\"postgresql:\u002F\u002F{{username}}:{{password}}@db.internal:5432\u002Fproduction?sslmode=require\" \\\n  username=\"vault_admin\" \\\n  password=\"initial-password\"\n\n# Rotate the root credentials so Vault manages them exclusively\nvault write -force database\u002Frotate-root\u002Fproduction-db\n\n# Create a readonly role with 1-hour TTL\nvault write database\u002Froles\u002Freadonly \\\n  db_name=production-db \\\n  creation_statements=\"CREATE ROLE \\\"{{name}}\\\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \\\"{{name}}\\\";\" \\\n  revocation_statements=\"REVOKE ALL ON ALL TABLES IN SCHEMA public FROM \\\"{{name}}\\\"; DROP ROLE IF EXISTS \\\"{{name}}\\\";\" \\\n  default_ttl=\"1h\" \\\n  max_ttl=\"24h\"\n\n# Enable AWS secrets engine for dynamic IAM credentials\nvault secrets enable aws\nvault write aws\u002Fconfig\u002Froot \\\n  access_key=AKIAEXAMPLE \\\n  secret_key=secretkey \\\n  region=us-east-1\n\nvault write aws\u002Froles\u002Fdeploy-role \\\n  credential_type=iam_user \\\n  policy_document=@deploy-policy.json \\\n  default_sts_ttl=3600\n```\n\n### Step 4: Integrate with Kubernetes Workloads\n\nUse the Vault Agent Injector or CSI Provider to deliver secrets to pods without application code changes. Secrets are rendered as files in a shared volume.\n\n```yaml\n# Kubernetes deployment with Vault Agent Injector annotations\napiVersion: apps\u002Fv1\nkind: Deployment\nmetadata:\n  name: web-app\nspec:\n  template:\n    metadata:\n      annotations:\n        vault.hashicorp.com\u002Fagent-inject: \"true\"\n        vault.hashicorp.com\u002Frole: \"web-app\"\n        vault.hashicorp.com\u002Fagent-inject-secret-db-creds: \"database\u002Fcreds\u002Freadonly\"\n        vault.hashicorp.com\u002Fagent-inject-template-db-creds: |\n          {{- with secret \"database\u002Fcreds\u002Freadonly\" -}}\n          export DB_USERNAME=\"{{ .Data.username }}\"\n          export DB_PASSWORD=\"{{ .Data.password }}\"\n          {{- end }}\n    spec:\n      serviceAccountName: web-app\n      containers:\n        - name: web-app\n          image: company\u002Fweb-app:v2.1\n          command: [\"\u002Fbin\u002Fsh\", \"-c\", \"source \u002Fvault\u002Fsecrets\u002Fdb-creds && .\u002Fstart.sh\"]\n```\n\n### Step 5: Implement Transit Encryption and PKI\n\nUse the Transit secrets engine for application-level encryption without managing keys in application code. Deploy the PKI engine for automatic TLS certificate management.\n\n```bash\n# Enable Transit engine for encryption as a service\nvault secrets enable transit\nvault write -f transit\u002Fkeys\u002Fpayment-data type=aes256-gcm96\n\n# Encrypt sensitive data\nvault write transit\u002Fencrypt\u002Fpayment-data \\\n  plaintext=$(echo \"card-number-4111-1111-1111-1111\" | base64)\n\n# Enable PKI for internal certificate management\nvault secrets enable pki\nvault secrets tune -max-lease-ttl=87600h pki\n\n# Generate root CA\nvault write pki\u002Froot\u002Fgenerate\u002Finternal \\\n  common_name=\"Internal Root CA\" \\\n  ttl=87600h\n\n# Configure intermediate CA for issuing certificates\nvault secrets enable -path=pki_int pki\nvault write pki_int\u002Fintermediate\u002Fgenerate\u002Finternal \\\n  common_name=\"Internal Intermediate CA\" \\\n  ttl=43800h\n\n# Create a role for issuing certificates\nvault write pki_int\u002Froles\u002Finternal-services \\\n  allowed_domains=\"internal.company.com\" \\\n  allow_subdomains=true \\\n  max_ttl=720h\n```\n\n### Step 6: Establish Policies and Audit Trail\n\nDefine fine-grained ACL policies following least privilege. Enable comprehensive audit logging for all secret access and administrative operations.\n\n```hcl\n# web-app-policy.hcl\npath \"database\u002Fcreds\u002Freadonly\" {\n  capabilities = [\"read\"]\n}\n\npath \"transit\u002Fencrypt\u002Fpayment-data\" {\n  capabilities = [\"update\"]\n}\n\npath \"transit\u002Fdecrypt\u002Fpayment-data\" {\n  capabilities = [\"update\"]\n}\n\npath \"secret\u002Fdata\u002Fweb-app\u002F*\" {\n  capabilities = [\"read\", \"list\"]\n}\n\n# Deny access to admin paths\npath \"sys\u002F*\" {\n  capabilities = [\"deny\"]\n}\n```\n\n```bash\n# Apply the policy\nvault policy write web-app-policy web-app-policy.hcl\n\n# Verify audit log captures all operations\nvault audit list -detailed\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Dynamic Secrets | Credentials generated on-demand with automatic expiration and revocation, eliminating long-lived static credentials |\n| Secret Engine | Vault component that stores, generates, or encrypts data; includes KV, database, AWS, PKI, and Transit engines |\n| Auto-Unseal | Cloud KMS-based mechanism that automatically unseals Vault nodes on restart without manual key entry |\n| AppRole | Machine-oriented authentication method using Role ID and Secret ID for application and CI\u002FCD pipeline access |\n| Transit Engine | Encryption-as-a-service engine that handles cryptographic operations without exposing encryption keys to applications |\n| Lease | Time-bound credential with a TTL that Vault automatically revokes on expiration unless renewed |\n| Namespace | Vault Enterprise feature providing tenant isolation with separate auth, secrets, and policy management |\n| Response Wrapping | Technique that wraps secret responses in a single-use token to prevent man-in-the-middle exposure during delivery |\n\n## Tools & Systems\n\n- **HashiCorp Vault**: Core secrets management platform providing dynamic secrets, encryption, and identity-based access\n- **Vault Agent Injector**: Kubernetes mutating webhook that automatically injects Vault secrets into pod volumes via sidecar containers\n- **Vault CSI Provider**: Kubernetes CSI driver that mounts Vault secrets directly into pod volumes without sidecar containers\n- **consul-template**: Template rendering daemon that watches Vault secrets and re-renders configuration files when secrets change\n- **Vault Radar**: Secret scanning tool that detects hardcoded credentials in source code, CI\u002FCD pipelines, and cloud configurations\n\n## Common Scenarios\n\n### Scenario: Eliminating Hardcoded Database Credentials from CI\u002FCD Pipeline\n\n**Context**: A DevOps team stores PostgreSQL credentials in GitHub Actions secrets and Jenkins credential stores. The same credentials are shared across staging and production environments with no rotation for 18 months.\n\n**Approach**:\n1. Deploy Vault with AppRole auth enabled for CI\u002FCD systems\n2. Configure the database secrets engine with separate roles for staging (readwrite, 2h TTL) and production (readonly, 1h TTL)\n3. Create separate Vault policies for each pipeline stage restricting access to the appropriate database role\n4. Update GitHub Actions workflows to authenticate via AppRole and request dynamic credentials at the start of each job\n5. Rotate the static PostgreSQL credentials and hand root access to Vault exclusively\n6. Enable audit logging to track every credential request with pipeline job metadata\n\n**Pitfalls**: Failing to rotate the original static credentials after Vault migration leaves the old credentials valid. Setting TTLs too short causes credential expiry mid-deployment for long-running jobs.\n\n## Output Format\n\n```\nVault Secrets Management Audit Report\n=======================================\nVault Cluster: vault.internal.company.com\nVersion: 1.18.1 Enterprise\nHA Mode: Raft (3 nodes)\nSeal Type: AWS KMS Auto-Unseal\nReport Date: 2025-02-23\n\nSECRET ENGINES:\n  database\u002F         PostgreSQL dynamic creds   Leases Active: 47\n  aws\u002F              Dynamic IAM credentials    Leases Active: 12\n  transit\u002F          Encryption as a service    Keys: 8\n  pki\u002F              Root CA                    Certs Issued: 0\n  pki_int\u002F          Intermediate CA            Certs Issued: 234\n  secret\u002F           KV v2 static secrets       Versions: 1,892\n\nAUTH METHODS:\n  oidc\u002F             Okta SSO for humans        Active Tokens: 23\n  approle\u002F          CI\u002FCD pipelines            Active Tokens: 156\n  kubernetes\u002F       Pod-based auth             Active Tokens: 89\n\nAUDIT FINDINGS:\n  [WARN] 3 AppRole secret_id_num_uses set to 0 (unlimited)\n  [WARN] 12 KV secrets not accessed in 90+ days (potential orphans)\n  [PASS] All dynamic secret TTLs under 24 hours\n  [PASS] Audit logging enabled on all nodes\n  [PASS] Root token revoked after initial setup\n\nCREDENTIAL HYGIENE:\n  Static Secrets (KV): 234\n  Dynamic Secrets Active: 59\n  Average Lease TTL: 2.3 hours\n  Secrets Rotated This Month: 12,456\n```\n","# Implementing Secrets Management with Vault\n\n## When to Use\n\n- When applications store database passwords, API keys, or certificates in environment variables or config files\n- When migrating from static long-lived credentials to dynamic short-lived secrets\n- When Kubernetes workloads need secure access to database credentials or cloud provider APIs\n- When compliance requirements mandate centralized credential management with audit logging\n- When CI\u002FCD pipelines contain hardcoded secrets that represent supply chain risk\n\n**Do not use** for AWS-only environments where AWS Secrets Manager suffices without multi-cloud requirements, for application-level encryption logic (though Vault Transit can help), or for identity federation (see managing-cloud-identity-with-okta).\n\n## Prerequisites\n\n- HashiCorp Vault server deployed in HA mode (Consul or Raft storage backend)\n- TLS certificates for Vault listener endpoints\n- Vault Enterprise license for namespaces, Sentinel policies, and replication (optional)\n- Kubernetes cluster with Vault Agent Injector or CSI provider for workload integration\n\n## Workflow\n\n### Step 1: Deploy Vault in High Availability Mode\n\nDeploy Vault using Integrated Storage (Raft) for HA without external dependencies. Configure TLS, audit logging, and auto-unseal using a cloud KMS.\n\n```hcl\n# vault-config.hcl\nstorage \"raft\" {\n  path    = \"\u002Fopt\u002Fvault\u002Fdata\"\n  node_id = \"vault-node-1\"\n\n  retry_join {\n    leader_api_addr = \"https:\u002F\u002Fvault-node-2.internal:8200\"\n  }\n  retry_join {\n    leader_api_addr = \"https:\u002F\u002Fvault-node-3.internal:8200\"\n  }\n}\n\nlistener \"tcp\" {\n  address     = \"0.0.0.0:8200\"\n  tls_cert_file = \"\u002Fopt\u002Fvault\u002Ftls\u002Fvault.crt\"\n  tls_key_file  = \"\u002Fopt\u002Fvault\u002Ftls\u002Fvault.key\"\n}\n\nseal \"awskms\" {\n  region     = \"us-east-1\"\n  kms_key_id = \"alias\u002Fvault-unseal-key\"\n}\n\napi_addr      = \"https:\u002F\u002Fvault-node-1.internal:8200\"\ncluster_addr  = \"https:\u002F\u002Fvault-node-1.internal:8201\"\n\ntelemetry {\n  prometheus_retention_time = \"30s\"\n  disable_hostname         = true\n}\n```\n\n```bash\n# Initialize Vault\nvault operator init -key-shares=5 -key-threshold=3\n\n# Enable audit logging\nvault audit enable file file_path=\u002Fvar\u002Flog\u002Fvault\u002Faudit.log\n\n# Enable syslog audit for SIEM integration\nvault audit enable syslog tag=\"vault\" facility=\"AUTH\"\n```\n\n### Step 2: Configure Authentication Methods\n\nEnable authentication backends for human operators, applications, and CI\u002FCD pipelines. Use AppRole for machine authentication and OIDC for human access.\n\n```bash\n# Enable OIDC auth for human users via Okta\nvault auth enable oidc\nvault write auth\u002Foidc\u002Fconfig \\\n  oidc_discovery_url=\"https:\u002F\u002Fcompany.okta.com\u002Foauth2\u002Fdefault\" \\\n  oidc_client_id=\"vault-client-id\" \\\n  oidc_client_secret=\"vault-client-secret\" \\\n  default_role=\"default\"\n\n# Enable AppRole for application authentication\nvault auth enable approle\nvault write auth\u002Fapprole\u002Frole\u002Fweb-app \\\n  secret_id_ttl=10m \\\n  token_num_uses=10 \\\n  token_ttl=20m \\\n  token_max_ttl=30m \\\n  secret_id_num_uses=1 \\\n  token_policies=\"web-app-policy\"\n\n# Enable Kubernetes auth for pod-based access\nvault auth enable kubernetes\nvault write auth\u002Fkubernetes\u002Fconfig \\\n  kubernetes_host=\"https:\u002F\u002Fkubernetes.default.svc:443\" \\\n  token_reviewer_jwt=@\u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Ftoken \\\n  kubernetes_ca_cert=@\u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Fca.crt\n```\n\n### Step 3: Enable Dynamic Secret Engines\n\nConfigure database secret engines to generate short-lived credentials on demand. Each credential set has a TTL and is automatically revoked when it expires.\n\n```bash\n# Enable database secrets engine for PostgreSQL\nvault secrets enable database\nvault write database\u002Fconfig\u002Fproduction-db \\\n  plugin_name=postgresql-database-plugin \\\n  allowed_roles=\"readonly,readwrite\" \\\n  connection_url=\"postgresql:\u002F\u002F{{username}}:{{password}}@db.internal:5432\u002Fproduction?sslmode=require\" \\\n  username=\"vault_admin\" \\\n  password=\"initial-password\"\n\n# Rotate the root credentials so Vault manages them exclusively\nvault write -force database\u002Frotate-root\u002Fproduction-db\n\n# Create a readonly role with 1-hour TTL\nvault write database\u002Froles\u002Freadonly \\\n  db_name=production-db \\\n  creation_statements=\"CREATE ROLE \\\"{{name}}\\\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \\\"{{name}}\\\";\" \\\n  revocation_statements=\"REVOKE ALL ON ALL TABLES IN SCHEMA public FROM \\\"{{name}}\\\"; DROP ROLE IF EXISTS \\\"{{name}}\\\";\" \\\n  default_ttl=\"1h\" \\\n  max_ttl=\"24h\"\n\n# Enable AWS secrets engine for dynamic IAM credentials\nvault secrets enable aws\nvault write aws\u002Fconfig\u002Froot \\\n  access_key=AKIAEXAMPLE \\\n  secret_key=secretkey \\\n  region=us-east-1\n\nvault write aws\u002Froles\u002Fdeploy-role \\\n  credential_type=iam_user \\\n  policy_document=@deploy-policy.json \\\n  default_sts_ttl=3600\n```\n\n### Step 4: Integrate with Kubernetes Workloads\n\nUse the Vault Agent Injector or CSI Provider to deliver secrets to pods without application code changes. Secrets are rendered as files in a shared volume.\n\n```yaml\n# Kubernetes deployment with Vault Agent Injector annotations\napiVersion: apps\u002Fv1\nkind: Deployment\nmetadata:\n  name: web-app\nspec:\n  template:\n    metadata:\n      annotations:\n        vault.hashicorp.com\u002Fagent-inject: \"true\"\n        vault.hashicorp.com\u002Frole: \"web-app\"\n        vault.hashicorp.com\u002Fagent-inject-secret-db-creds: \"database\u002Fcreds\u002Freadonly\"\n        vault.hashicorp.com\u002Fagent-inject-template-db-creds: |\n          {{- with secret \"database\u002Fcreds\u002Freadonly\" -}}\n          export DB_USERNAME=\"{{ .Data.username }}\"\n          export DB_PASSWORD=\"{{ .Data.password }}\"\n          {{- end }}\n    spec:\n      serviceAccountName: web-app\n      containers:\n        - name: web-app\n          image: company\u002Fweb-app:v2.1\n          command: [\"\u002Fbin\u002Fsh\", \"-c\", \"source \u002Fvault\u002Fsecrets\u002Fdb-creds && .\u002Fstart.sh\"]\n```\n\n### Step 5: Implement Transit Encryption and PKI\n\nUse the Transit secrets engine for application-level encryption without managing keys in application code. Deploy the PKI engine for automatic TLS certificate management.\n\n```bash\n# Enable Transit engine for encryption as a service\nvault secrets enable transit\nvault write -f transit\u002Fkeys\u002Fpayment-data type=aes256-gcm96\n\n# Encrypt sensitive data\nvault write transit\u002Fencrypt\u002Fpayment-data \\\n  plaintext=$(echo \"card-number-4111-1111-1111-1111\" | base64)\n\n# Enable PKI for internal certificate management\nvault secrets enable pki\nvault secrets tune -max-lease-ttl=87600h pki\n\n# Generate root CA\nvault write pki\u002Froot\u002Fgenerate\u002Finternal \\\n  common_name=\"Internal Root CA\" \\\n  ttl=87600h\n\n# Configure intermediate CA for issuing certificates\nvault secrets enable -path=pki_int pki\nvault write pki_int\u002Fintermediate\u002Fgenerate\u002Finternal \\\n  common_name=\"Internal Intermediate CA\" \\\n  ttl=43800h\n\n# Create a role for issuing certificates\nvault write pki_int\u002Froles\u002Finternal-services \\\n  allowed_domains=\"internal.company.com\" \\\n  allow_subdomains=true \\\n  max_ttl=720h\n```\n\n### Step 6: Establish Policies and Audit Trail\n\nDefine fine-grained ACL policies following least privilege. Enable comprehensive audit logging for all secret access and administrative operations.\n\n```hcl\n# web-app-policy.hcl\npath \"database\u002Fcreds\u002Freadonly\" {\n  capabilities = [\"read\"]\n}\n\npath \"transit\u002Fencrypt\u002Fpayment-data\" {\n  capabilities = [\"update\"]\n}\n\npath \"transit\u002Fdecrypt\u002Fpayment-data\" {\n  capabilities = [\"update\"]\n}\n\npath \"secret\u002Fdata\u002Fweb-app\u002F*\" {\n  capabilities = [\"read\", \"list\"]\n}\n\n# Deny access to admin paths\npath \"sys\u002F*\" {\n  capabilities = [\"deny\"]\n}\n```\n\n```bash\n# Apply the policy\nvault policy write web-app-policy web-app-policy.hcl\n\n# Verify audit log captures all operations\nvault audit list -detailed\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Dynamic Secrets | Credentials generated on-demand with automatic expiration and revocation, eliminating long-lived static credentials |\n| Secret Engine | Vault component that stores, generates, or encrypts data; includes KV, database, AWS, PKI, and Transit engines |\n| Auto-Unseal | Cloud KMS-based mechanism that automatically unseals Vault nodes on restart without manual key entry |\n| AppRole | Machine-oriented authentication method using Role ID and Secret ID for application and CI\u002FCD pipeline access |\n| Transit Engine | Encryption-as-a-service engine that handles cryptographic operations without exposing encryption keys to applications |\n| Lease | Time-bound credential with a TTL that Vault automatically revokes on expiration unless renewed |\n| Namespace | Vault Enterprise feature providing tenant isolation with separate auth, secrets, and policy management |\n| Response Wrapping | Technique that wraps secret responses in a single-use token to prevent man-in-the-middle exposure during delivery |\n\n## Tools & Systems\n\n- **HashiCorp Vault**: Core secrets management platform providing dynamic secrets, encryption, and identity-based access\n- **Vault Agent Injector**: Kubernetes mutating webhook that automatically injects Vault secrets into pod volumes via sidecar containers\n- **Vault CSI Provider**: Kubernetes CSI driver that mounts Vault secrets directly into pod volumes without sidecar containers\n- **consul-template**: Template rendering daemon that watches Vault secrets and re-renders configuration files when secrets change\n- **Vault Radar**: Secret scanning tool that detects hardcoded credentials in source code, CI\u002FCD pipelines, and cloud configurations\n\n## Common Scenarios\n\n### Scenario: Eliminating Hardcoded Database Credentials from CI\u002FCD Pipeline\n\n**Context**: A DevOps team stores PostgreSQL credentials in GitHub Actions secrets and Jenkins credential stores. The same credentials are shared across staging and production environments with no rotation for 18 months.\n\n**Approach**:\n1. Deploy Vault with AppRole auth enabled for CI\u002FCD systems\n2. Configure the database secrets engine with separate roles for staging (readwrite, 2h TTL) and production (readonly, 1h TTL)\n3. Create separate Vault policies for each pipeline stage restricting access to the appropriate database role\n4. Update GitHub Actions workflows to authenticate via AppRole and request dynamic credentials at the start of each job\n5. Rotate the static PostgreSQL credentials and hand root access to Vault exclusively\n6. Enable audit logging to track every credential request with pipeline job metadata\n\n**Pitfalls**: Failing to rotate the original static credentials after Vault migration leaves the old credentials valid. Setting TTLs too short causes credential expiry mid-deployment for long-running jobs.\n\n## Output Format\n\n```\nVault Secrets Management Audit Report\n=======================================\nVault Cluster: vault.internal.company.com\nVersion: 1.18.1 Enterprise\nHA Mode: Raft (3 nodes)\nSeal Type: AWS KMS Auto-Unseal\nReport Date: 2025-02-23\n\nSECRET ENGINES:\n  database\u002F         PostgreSQL dynamic creds   Leases Active: 47\n  aws\u002F              Dynamic IAM credentials    Leases Active: 12\n  transit\u002F          Encryption as a service    Keys: 8\n  pki\u002F              Root CA                    Certs Issued: 0\n  pki_int\u002F          Intermediate CA            Certs Issued: 234\n  secret\u002F           KV v2 static secrets       Versions: 1,892\n\nAUTH METHODS:\n  oidc\u002F             Okta SSO for humans        Active Tokens: 23\n  approle\u002F          CI\u002FCD pipelines            Active Tokens: 156\n  kubernetes\u002F       Pod-based auth             Active Tokens: 89\n\nAUDIT FINDINGS:\n  [WARN] 3 AppRole secret_id_num_uses set to 0 (unlimited)\n  [WARN] 12 KV secrets not accessed in 90+ days (potential orphans)\n  [PASS] All dynamic secret TTLs under 24 hours\n  [PASS] Audit logging enabled on all nodes\n  [PASS] Root token revoked after initial setup\n\nCREDENTIAL HYGIENE:\n  Static Secrets (KV): 234\n  Dynamic Secrets Active: 59\n  Average Lease TTL: 2.3 hours\n  Secrets Rotated This Month: 12,456\n```\n",{"name":5,"tags":55,"author":58,"domain":48,"license":15,"version":59,"nist_csf":60,"subdomain":42,"description":65,"mitre_attack":66},[56,32,33,57,39],"hashicorp-vault","credential-rotation","mahipal","1.0.0",[61,62,63,64],"PR.IR-01","ID.AM-08","GV.SC-06","DE.CM-01","Deploy HashiCorp Vault for centralized secrets management, covering dynamic secret generation for databases and cloud providers, transit encryption, PKI certificate management, and Kubernetes integration. Use when eliminating hardcoded credentials from application code or CI\u002FCD pipelines, migrating to short-lived auto-rotated secrets, or giving Kubernetes workloads secure access to database or cloud provider credentials.\n",[67,68,69,70,71],"T1078.004","T1530","T1537","T1580","T1003","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fimplementing-secrets-management-with-vault",4414,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":83,"prompt":93,"zipAvailable":94},[84,87,90],{"tool":85,"command":86},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-secrets-management-with-vault",{"tool":88,"command":89},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-secrets-management-with-vault",{"tool":91,"command":92},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-secrets-management-with-vault","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-secrets-management-with-vault\u002FSKILL.md",true,[96,101,107],{"path":97,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":99,"sourceHtmlUrl":100},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-secrets-management-with-vault\u002FLICENSE",{"path":102,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fapi-reference.md","REFERENCE","参考文档",4193,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-secrets-management-with-vault\u002Freferences\u002Fapi-reference.md",{"path":108,"resourceType":109,"resourceTypeDesc":110,"sizeBytes":111,"sourceHtmlUrl":112},"scripts\u002Fagent.py","SCRIPT","脚本",10933,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-secrets-management-with-vault\u002Fscripts\u002Fagent.py",[114,137,160,187,213,240],{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":121,"publishedAt":50},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[120],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[122,123,124,125,49,48,126,127,46,45,128,43,129,130,131,132,133,134,135,136],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","identity","artifacts","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":144,"publishedAt":50},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[143],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[145,133,146,147,49,148,48,46,149,41,150,151,152,153,154,155,156,157,158,159],"boot","TPM","validating tpm measured boot attestation","policy","verification","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":170,"publishedAt":50},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[166,169],{"categoryNo":167,"categoryName":168,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[154,171,172,173,174,48,175,176,149,177,178,179,180,181,182,36,183,184,185,186],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":194,"publishedAt":50},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[193],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[195,196,197,48,198,199,200,201,202,203,204,205,206,207,208,209,151,210,211,212],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":217,"categories":218,"keywords":220,"publishedAt":50},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[219],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[221,222,223,48,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":241,"name":242,"nameZh":6,"description":243,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":244,"categories":245,"keywords":247,"publishedAt":50},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[246],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[49,248,48,249,250,251,252,253,254,255,256,36,257,183,258,259,260,261,262,263],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]