# Kms And Secrets Management > Use when managing encryption keys and secrets in the cloud — key policies, envelope encryption, and secret stores — so encrypted data and stored credentials stay actually protected. - Skill: `jihedbfr-art/kms-and-secrets-management` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/kms-and-secrets-management` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/kms-and-secrets-management/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/kms-and-secrets-management --- ## Prerequisites - Target system, dependencies and environment configured. ## Usage ### Purpose Cloud encryption is easy to turn on and easy to get subtly wrong. The data is encrypted, but the key policy lets the wrong principal decrypt it; or secrets sit in plaintext env vars while a managed secret store goes unused. This skill covers using cloud KMS and secret managers so that "encrypted" actually means protected — the access to the key matters as much as the encryption itself. AWS KMS/Secrets Manager are the examples; Azure Key Vault and GCP KMS follow the same principles. ### When to use it Setting up encryption for data at rest, managing application secrets, or reviewing whether existing encryption and secret handling actually protect anything. Pairs with the credential-hygiene and S3 skills. ### Procedure 1. **Understand who can use the key, not just that data is encrypted.** In KMS, the **key policy** (plus IAM and grants) decides who can decrypt. Encryption is only as strong as that access control — a key any principal can use protects data from outsiders but not from a compromised insider role: ``` aws kms get-key-policy --key-id --policy-name default ``` 2. **Scope key access to the principals that need it.** Separate keys by purpose/sensitivity and grant decrypt to the minimal set of roles. A single key used everywhere with broad access means one compromised role decrypts everything. 3. **Use envelope encryption correctly** — KMS encrypts a data key, the data key encrypts the data. Let the cloud SDK handle this; the point is that the master key never leaves KMS and rotation is manageable. 4. **Enable key rotation** where supported, and prefer customer-managed keys over the account-default key when you need control over the policy and rotation. 5. **Put secrets in a secret manager, not in code or plain config.** Application credentials, API keys, DB passwords belong in Secrets Manager / Key Vault / Secret Manager — fetched at runtime, access-controlled, auditable, and rotatable. Env vars and committed config are leak vectors (ties into credential-hygiene and secret-scanning). 6. **Audit access.** KMS decrypt calls and secret retrievals are logged (CloudTrail) — confirm they're captured, and alert on unusual decrypt patterns or access from unexpected principals. ### Cheatsheet ```bash aws kms get-key-policy --key-id KEY --policy-name default aws kms list-grants --key-id KEY -> scope decrypt to minimal roles; separate keys by sensitivity aws kms enable-key-rotation --key-id KEY # rotate prefer customer-managed keys (control policy + rotation) over default aws secretsmanager get-secret-value --secret-id NAME -> NOT in code, NOT in plain env vars/config ``` ### Reading the review - **A key policy granting decrypt broadly** (a wildcard principal, or every role) = the encryption protects against outsiders but not a compromised insider role; access to the key is the weak link. Scope it down. - **One key for everything** = a single compromised principal decrypts all data classes. Separate keys by purpose/sensitivity. - **Secrets in plain env vars or committed config** = encryption at rest is undermined by credentials sitting in the open elsewhere. Move them to a secret manager. - **No key rotation / account-default key used for sensitive data** = less control and a longer-lived key; prefer customer-managed keys with rotation. - **Decrypt/secret-access not audited** = you can't detect misuse of the key; enable and alert on the CloudTrail events. ### The fix - **Treat the key policy as the control.** Grant decrypt to the minimum principals, separate keys by data sensitivity, and review key policies like you review IAM — because that's what they are. - **Use customer-managed keys with rotation** for sensitive data, so you control the policy and lifecycle. - **Envelope encryption via the SDK** — master key stays in KMS, data keys encrypt the data. - **Centralise secrets in a secret manager**, fetched at runtime with scoped access and rotation; never hardcode or plain-env them. - **Audit KMS and secret access** through CloudTrail and alert on anomalies (unexpected principal, unusual volume of decrypts). - Combine with the S3/storage encryption defaults so data is encrypted with keys you actually control. ### Pitfalls - **Confusing "encrypted" with "protected".** If the key policy lets a compromised role decrypt, the data isn't protected from that role. Access to the key is the point. - **One key, broad access, for everything.** Maximises blast radius — one compromise decrypts all. Separate and scope. - **Secrets outside the secret manager.** Encrypting data at rest while credentials sit in env vars or config is a half-measure that leaks the keys to the kingdom. - **No rotation or auditing.** A long-lived, unmonitored key is a latent risk; rotate and watch decrypt patterns. ### References - AWS KMS best practices and Secrets Manager documentation - Azure Key Vault / GCP KMS equivalents - OWASP Secrets Management and Cryptographic Storage Cheat Sheets - CWE-311 (missing encryption), CWE-522 (insufficiently protected credentials) ## Inputs - Relevant source code, logs, network traces, or system specifications. ## Outputs - Analysis findings, security audit report, or generated code artifacts.