# Ensure Secrets Manager Secret Resource Policy Does Not Allow Public Access

- Source: https://support.icompaas.com/support/solutions/articles/a_1788890047659654-ensure-secrets-manager-secret-resource-policy-does-not-allow-public-access
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS Cloud](https://support.icompaas.com/support/solutions/c_1788889426924716) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1788889470630116)
- Last updated: 2026-09-08
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that AWS Secrets Manager resource policies attached to secrets do not grant access to the wildcard principal (\*) without a restrictive condition, which could allow any AWS account, or in some misconfigurations any unauthenticated caller, to retrieve the secret's value.

**Rationale**

Secrets Manager is intended to store sensitive credentials and other secret values; a resource policy that grants access to Principal '\*' without a scoping condition effectively negates the confidentiality protection Secrets Manager is meant to provide, potentially exposing the secret to any AWS account in existence. Access to a secret's value should always be scoped to the specific accounts, roles, or users that legitimately require it.

**Impact**

-   Prevents unauthorized AWS accounts or principals from retrieving a secret's value
    
-   Ensures access to secrets follows least-privilege principles
    
-   Requires identifying and explicitly authorizing any legitimate cross-account consumers of the secret before removing a broad grant
    

**Default Value**

Secrets Manager secrets do not have a resource policy by default; access is governed by IAM identity-based policies unless a resource policy is explicitly added.

**Pre-Requisites**

-   IAM permissions to view and update secret resource policies (secretsmanager:GetResourcePolicy, secretsmanager:PutResourcePolicy)
    

**Test Plan**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Navigate to AWS Secrets Manager > Secrets and select the secret to review.
    
3.  Open the Overview tab and review the Resource permissions (resource policy) section.
    
4.  Review each policy statement's Principal and Condition elements.
    
5.  Verify that no statement grants access to Principal '\*' without a restrictive condition (such as a specific aws:PrincipalAccount or aws:SourceArn) scoping it appropriately.
    
6.  If an overly permissive resource policy is found, follow the implementation steps.
    

**Implementation Steps**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Navigate to AWS Secrets Manager > Secrets and select the affected secret.
    
3.  Open the Overview tab, locate Resource permissions, and select Edit permissions.
    
4.  Replace the wildcard principal with the specific AWS account ID(s), role ARN(s), or user ARN(s) that legitimately need access, adding conditions as appropriate.
    
5.  Save the updated resource policy.
    
6.  Verify that legitimate consumers of the secret can still retrieve it, and that the previously broad access is no longer possible.
    

**Backout Plan**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Navigate to AWS Secrets Manager > Secrets and select the affected secret.
    
3.  Open the Overview tab, locate Resource permissions, and select Edit permissions.
    
4.  Restore the previous, broader policy statement, if reverting is required.
    

**Reference**

-   [https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access\_resource-based-policies.html](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-based-policies.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.