Secrets Manager secret's resource policy is shared beyond this account

What this check finds

The secret's resource policy names a principal in another AWS account, or grants Principal "*" narrowed only to an organisation (aws:PrincipalOrgID, aws:PrincipalOrgPaths) or to other accounts (aws:PrincipalAccount, aws:SourceAccount). If the secret's KMS key also lets them decrypt, those accounts can read the value, and their own administrators decide who there can.

Passing looks like: Secret resource policies are not shared beyond this account.

How to fix it

Confirm each account or organisation should have this access. If not, remove it from the resource policy: aws secretsmanager put-resource-policy --secret-id SECRET_NAME --resource-policy file://policy.json, or delete the policy with aws secretsmanager delete-resource-policy. If it should, grant only the actions it needs and name its role, not the account root or "*".

Compliance controls it is evidence for

A failing result counts against these controls in KloudLytics; a passing one is evidence towards them. How compliance mapping works

Checked on every scan

KloudLytics runs this check each time it scans a connected AWS account, through a read-only role, and lists every affected resource with its region. On Pro and Business a fix is written for the specific resource rather than the general case above. The exact access it needs

More Secrets Manager checks

• HighSecrets Manager secret's resource policy allows all principals
• MediumSecrets Manager secret does not have rotation enabled
• LowSecrets Manager secret has not been accessed in over 90 days
• LowVPC with private subnets has no Secrets Manager endpoint

All Secrets Manager checks