# Ensure Secrets Manager secret resource policy does not allow public access - Source: https://support.icompaas.com/support/solutions/articles/a_1793292248275221-ensure-secrets-manager-secret-resource-policy-does-not-allow-public-access - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that no AWS Secrets Manager secret has a resource-based policy that grants access to everyone. A policy is considered public when an Allow statement uses a wildcard principal, such as "Principal": "\*" or "Principal": {"AWS": "\*"}, without a condition that limits access to your own account, organization or network. Only secrets that have a resource policy are evaluated. **Rationale** A public resource policy allows any AWS principal to retrieve the secret value, which exposes credentials and other sensitive data. If the policy also allows broader actions, an attacker could change or delete the secret, affecting the applications that rely on it, and use the exposed credentials for unauthorized access and lateral movement. Resource policies should grant access only to specific principals, use conditions such as source account, organization or VPC endpoint where needed, and block public policies. **Impact** - Prevents retrieval of the secret by principals outside your control - Principals that rely on the wildcard statement for legitimate access will lose access unless they are named explicitly in the new policy - Passing --block-public-policy makes Secrets Manager reject the new policy if it allows broad access; this check applies only to that request and is not a persistent setting, so always pass it on policy updates or enforce it with an SCP or IAM condition **Default Value** A new secret has no resource-based policy, so access is controlled only by IAM identity policies in the same account. **Pre-Requisites** - IAM permissions: secretsmanager:ListSecrets, secretsmanager:GetResourcePolicy, secretsmanager:PutResourcePolicy and secretsmanager:DeleteResourcePolicy - A list of the principals (roles, users or accounts) that legitimately need access to the secret **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the AWS Secrets Manager console and select a secret. 3. On the **Overview** tab, find **Resource permissions**. 4. Check whether any statement has "Effect": "Allow" and a principal of "\*" or {"AWS": "\*"} without a condition that restricts access to your account, organization or network. 5. Repeat for each secret in each region in use. 6. If such a statement exists, follow the implementation steps. **CLI:** List the secrets in a region: aws secretsmanager list-secrets --region --query "SecretList\[\].\[Name,ARN\]" --output table Show the resource policy of a secret: aws secretsmanager get-resource-policy --region --secret-id --query "ResourcePolicy" --output text A secret fails if its policy contains an Allow statement with a principal of "\*" or {"AWS": "\*"} and no condition that restricts access to your account, organization or network. Secrets without a resource policy are not evaluated. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the AWS Secrets Manager console and select the secret. 3. On the **Overview** tab, in **Resource permissions**, choose **Edit permissions**. 4. Remove each statement whose principal is "\*" or {"AWS": "\*"}, or replace the wildcard with the specific principals that need access. 5. If no resource policy is needed, choose **Delete** to remove it. 6. Choose **Save**. 7. Repeat for each affected secret in each region in use. **CLI:** Save the following as policy.json, listing only the principals that need access: {"Version":"2012-10-17","Statement":\[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam:::role/"},"Action":"secretsmanager:GetSecretValue","Resource":"\*"}\]} Replace the policy. The --block-public-policy option makes Secrets Manager reject this policy if it allows broad access; it applies only to this request and is not a persistent setting. To prevent public policies in the future, always pass --block-public-policy when updating a resource policy, or enforce it with an SCP or IAM policy condition (for example secretsmanager:BlockPublicPolicy). aws secretsmanager put-resource-policy --region --secret-id --resource-policy file://policy.json --block-public-policy If the secret does not need a resource policy, remove it: aws secretsmanager delete-resource-policy --region --secret-id **Backout Plan** Before making changes, save the current policy: aws secretsmanager get-resource-policy --region --secret-id > secret-policy-backup.json To roll back: 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the AWS Secrets Manager console and select the secret. 3. On the **Overview** tab, in **Resource permissions**, choose **Edit permissions**. 4. Paste the previous policy from the ResourcePolicy value in the saved backup. 5. Choose **Save**. Note: rolling back makes the secret publicly accessible again. Grant access to the specific principals that need it instead. **Reference** - [https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access\_resource-policies.html](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-policies.html) - [https://docs.aws.amazon.com/secretsmanager/latest/userguide/determine-acccess\_examine-iam-policies.html](https://docs.aws.amazon.com/secretsmanager/latest/userguide/determine-acccess_examine-iam-policies.html) - [https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/put-resource-policy.html](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/put-resource-policy.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.