Reviewing Secrets Manager Access Policy Trust

Reviewing secrets-manager access-policy trust: who can actually read the secret

A managed secrets store is only as strong as the policy that decides who reads each secret, and that decision is rarely written in one place. The effective read set is the union of the secret's resource policy, the identity policies of every principal in the account, and the permission to decrypt the key that protects the secret. A secret can look locked down on its resource policy while a broad identity policy elsewhere grants read on every secret, or while a wide key-decrypt grant lets a principal decrypt what the store would otherwise deny. Wildcards on secret names or paths quietly sweep in unrelated secrets. You review these by computing who the combined policy actually admits and comparing that to the secret's intended consumers.

When to use

• Applications fetch secrets from a managed secrets manager or a vault-style store.
• Access is governed by a combination of resource policy, identity policy, and key-decrypt permission.
• Secret names or paths are matched by wildcard in any policy that grants read.

Scope check

Review secret access only in accounts and stores you own or are authorized to assess. Confirming a read retrieves a real secret value, so stay inside the authorized store and treat any retrieved value as sensitive within scope, never exfiltrating it. If you can't name the authorization, stop.

The loop

1. Establish the secret's intended consumers first. For each secret, name the principals that legitimately need to read it: the specific service role, the specific workload. This is the false-positive killer: a policy admitting exactly those consumers is correct however powerful the store is. Name the consumers, then compute the actual read set against them.

2. Read the resource policy for who it admits. The secret's own policy grants read to named principals or patterns. Determine the true set it admits, noting any broad principal (an account, a wildcard) and any condition that is meant to scope it. This is one term of the union, not the whole answer.

3. Add the identity policies. A principal can read the secret if its own identity policy grants read on it, independent of the resource policy. Look for identity policies that grant secret-read broadly, on all secrets or a wide path, since these admit readers the resource policy never named. The effective read set includes every principal granted by either side.

4. Add the key-decrypt permission. The secret is protected by a key; reading the plaintext requires decrypting with that key. A principal with a broad decrypt grant on the key can obtain the plaintext even where the secret policy is tight, so the key policy is a third term of the union. Confirm the decrypt grant is no broader than the secret's read set.

5. Resolve wildcards on names and paths. A wildcard on the secret name or path in any granting policy matches every secret under it, so a grant meant for one secret can cover a family of unrelated ones. Expand the wildcards against the real secret inventory and confirm each match is an intended consumer.

6. Confirm and record. Confirm by reading the secret as a principal that should not be a consumer but is admitted by the combined policy, within scope, without exfiltrating the value. Kill the lead if the union of resource policy, identity policies, and key-decrypt permission admits only the intended consumers, and no wildcard sweeps in unrelated secrets. Record the admitting policy term, the secret-read sink, and the reader beyond the intended consumers.

Where secrets-manager access trust leaks

• The read set is a union, not the resource policy alone. A tight secret policy is undone by a broad identity policy or a wide key-decrypt grant elsewhere.
• A broad identity policy grants read on every secret. A principal with secret-read on all resources reads secrets no resource policy ever named.
• Key-decrypt is a back door to plaintext. Decrypting the protecting key yields the value even where the secret policy denies; the decrypt grant must match the read set.
• A wildcard path sweeps in unrelated secrets. A grant scoped to a prefix covers every secret under it, intended or not.
• Conditions must actually constrain. A condition on a spoofable or caller-controlled value does not narrow the admitted set.

Worked example (a confirm and a kill)

Confirm. A database secret's resource policy names only the application role, but a broad identity policy on an operations role grants secret-read on all secrets, and that role also holds decrypt on the protecting key. The operations role, never an intended consumer, reads the database secret. Confirmed over-broad secret access through an identity policy, high, remediation = scope the operations identity policy to the specific secrets it needs, restrict key-decrypt to the secret's read set, and confirm the effective union admits only intended consumers.

Kill. Each secret's effective read set, computed as the union of its resource policy, all identity policies, and key-decrypt permission, admits only the specific consuming role, and no wildcard path grants read beyond the intended secret. A principal outside the consumer set is denied by every term. Killed, kill_reason = "the combined resource, identity, and key-decrypt policies admit only the intended consumers and no wildcard sweeps in other secrets; no unintended principal can read the plaintext."

Rationalizations to reject

• "The secret policy only allows the app role." → The read set is the union with identity policies and key-decrypt; compute all three before concluding it is tight.
• "Operations needs broad access." → Broad secret-read on an operations role makes it a reader of every secret; scope it to the specific secrets required.
• "The key is separate." → Decrypting the protecting key yields the plaintext; a broad decrypt grant is a read grant in effect.
• "The wildcard is just for that service's secrets." → Expand it against the real inventory; a prefix wildcard often matches secrets it was never meant to cover.
• "There is a condition on it." → Confirm the condition constrains an unspoofable value; otherwise it does not narrow the admitted set.

Executing this in practice

You need each secret's intended consumers, its resource policy, the identity policies that grant read on it, the key-decrypt permissions on its protecting key, and the wildcard matches across the secret inventory. Compute the effective read set as the union and compare it to the consumers. Reading the policies shows the intended boundary; reading the secret as an unintended-but-admitted principal shows whether it holds.

Related

• auditing-kms-key-policy-and-envelope-encryption - the key side of the union; a broad decrypt grant on the protecting key is a back door this review must include.
• hunting-non-human-identity-and-secret-reachability - the reachability companion; once the read set is known, that skill traces which reachable identity actually pulls the secret.
• hunting-iam-privilege-escalation-paths - a principal that can read a secret granting further access is an escalation edge worth chaining from here.
• adjudicating-taint-paths - use it to confirm an admitted principal's credentials actually reach the secret-read call.
• FINDING-SCHEMA.md - source = the principal the combined policy admits, sink = the secret read, evidence = the reader beyond the secret's intended consumers.