# Authentication and access control for AWS Secrets Manager Authentication and access control Secrets Manager uses [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) to secure access to secrets. IAM provides authentication and access control. *Authentication* verifies the identity of individuals' requests. Secrets Manager uses a sign-in process with passwords, access keys, and multi-factor authentication (MFA) tokens to verify the identity of the users. See [Signing in to AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/console.html). *Access control* ensures that only approved individuals can perform operations on AWS resources such as secrets. Secrets Manager uses policies to define who has access to which resources, and which actions the identity can take on those resources. See [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html). **Topics** + [ ## Permissions reference for AWS Secrets Manager ](#reference_iam-permissions) + [ ## Secrets Manager administrator permissions ](#auth-and-access_admin) + [ ## Permissions to access secrets ](#auth-and-access_secrets) + [ ## Permissions for Lambda rotation functions ](#auth-and-access_rotate) + [ ## Permissions for encryption keys ](#auth-and-access_encrypt) + [ ## Permissions for replication ](#auth-and-access_replication) + [ # Identity-based policies ](auth-and-access_iam-policies.md) + [ # Resource-based policies ](auth-and-access_resource-policies.md) + [ # Control access to secrets using attribute-based access control (ABAC) ](auth-and-access-abac.md) + [ # AWS managed policy for AWS Secrets Manager ](reference_available-policies.md) + [ # Determine who has permissions to your AWS Secrets Manager secrets ](determine-acccess_examine-iam-policies.md) + [ # Access AWS Secrets Manager secrets from a different account ](auth-and-access_examples_cross.md) + [ # Access secrets from an on-premises environment ](auth-and-access-on-prem.md) ## Permissions reference for AWS Secrets Manager Permissions reference The permissions reference for Secrets Manager is available at [Actions, resources, and condition keys for AWS Secrets Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssecretsmanager.html) in the *Service Authorization Reference*. ## Secrets Manager administrator permissions To grant Secrets Manager administrator permissions, follow the instructions at [Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html), and attach the following policies: + [SecretsManagerReadWrite](reference_available-policies.md#security-iam-awsmanpol-SecretsManagerReadWrite) + [https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) We recommend you do not grant administrator permissions to end users. While this allows your users to create and manage their secrets, the permission required to enable rotation (IAMFullAccess) grants significant permissions that are not appropriate for end users. ## Permissions to access secrets By using IAM permission policies, you control which users or services have access to your secrets. A *permissions policy* describes who can perform which actions on which resources. You can: + [Identity-based policies](auth-and-access_iam-policies.md) + [Resource-based policies](auth-and-access_resource-policies.md) ## Permissions for Lambda rotation functions Secrets Manager uses AWS Lambda functions to [rotate secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html). The Lambda function must have access to the secret as well as the database or service that the secret contains credentials for. See [Permissions for rotation](rotating-secrets-required-permissions-function.md). ## Permissions for encryption keys Secrets Manager uses AWS Key Management Service (AWS KMS) keys to [encrypt secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html). The AWS managed key `aws/secretsmanager` automatically has the correct permissions. If you use a different KMS key, Secrets Manager needs permissions to that key. See [Permissions for the KMS key](security-encryption.md#security-encryption-authz). ## Permissions for replication By using IAM permission policies, you control which users or services can replicate your secrets to other Regions. See [Prevent AWS Secrets Manager replication](replicate-secrets-permissions.md). # Identity-based policies You can attach permissions policies to [IAM identities: users, user groups, and roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html). In an identity-based policy, you specify which secrets the identity can access and the actions the identity can perform on the secrets. For more information, see [Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html). You can grant permissions to a role that represents an application or user in another service. For example, an application running on an Amazon EC2 instance might need access to a database. You can create an IAM role attached to the EC2 instance profile and then use a permissions policy to grant the role access to the secret that contains credentials for the database. For more information, see [Using an IAM role to grant permissions to applications running on Amazon EC2 instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html). Other services that you can attach roles to include [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/c-getting-started-using-spectrum.html), [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html), and [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html). You can also grant permissions to users authenticated by an identity system other than IAM. For example, you can associate IAM roles to mobile app users who sign in with Amazon Cognito. The role grants the app temporary credentials with the permissions in the role permission policy. Then you can use a permissions policy to grant the role access to the secret. For more information, see [Identity providers and federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html). You can use identity-based policies to: + Grant an identity access to multiple secrets. + Control who can create new secrets, and who can access secrets that haven't been created yet. + Grant an IAM group access to secrets. **Topics** + [ ## Example: Permission to retrieve individual secret values ](#auth-and-access_examples_identity_read) + [ ## Example: Permission to read and describe individual secrets ](#auth-and-access_examples-read-and-describe) + [ ## Example: Permission to retrieve a group of secret values in a batch ](#auth-and-access_examples_batch) + [ ## Example: Wildcards ](#auth-and-access_examples_wildcard) + [ ## Example: Permission to create secrets ](#auth-and-access_examples_create) + [ ## Example: Deny a specific AWS KMS key to encrypt secrets ](#auth-and-access_examples_kmskey) ## Example: Permission to retrieve individual secret values To grant permission to retrieve secret values, you can attach policies to secrets or identities. For help determining which type of policy to use, see [Identity-based policies and resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). For information about how to attach a policy, see [Resource-based policies](auth-and-access_resource-policies.md) and [Identity-based policies](#auth-and-access_iam-policies). This example is useful when you want to grant access to an IAM group. To grant permission to retrieve a group of secrets in a batch API call, see [Example: Permission to retrieve a group of secret values in a batch](#auth-and-access_examples_batch). **Example Read a secret that is encrypted using a customer managed key** If a secret is encrypted using a customer managed key, you can grant access to read the secret by attaching the following policy to an identity. \$1 **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf" }, { "Effect": "Allow", "Action": "kms:Decrypt", "Resource": "arn:aws:kms:us-east-1:123456789012:key/key-id" } ] } ``` ## Example: Permission to read and describe individual secrets **Example Read and describe one secret** You can grant access to a secret by attaching the following policy to an identity. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf" } ] } ``` ## Example: Permission to retrieve a group of secret values in a batch **Example Read a group of secrets in a batch** You can grant access to retrieve a group of secrets in a batch API call by attaching the following policy to an identity. The policy restricts the caller so that they can only retrieve the secrets specified by *SecretARN1*, *SecretARN2*, and *SecretARN3*, even if the batch call includes other secrets. If the caller also requests other secrets in the batch API call, Secrets Manager won't return them. For more information, see [`BatchGetSecretValue`.](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_BatchGetSecretValue.html). **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:BatchGetSecretValue", "secretsmanager:ListSecrets" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName1-AbCdEf", "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName2-AbCdEf", "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName3-AbCdEf" ] } ] } ``` ## Example: Wildcards You can use wildcards to include a set of values in a policy element. **Example Access all secrets in a path** The following policy grants access to retrieve all secrets with a name beginning with "*TestEnv/*". **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:TestEnv/*" } } ``` **Example Access metadata on all secrets** The following policy grants `DescribeSecret` and permissions beginning with `List`: `ListSecrets` and `ListSecretVersionIds`. **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:List*" ], "Resource": "*" } } ``` **Example Match secret name** The following policy grants all Secrets Manager permissions for a secret by name. To use this policy, see [Identity-based policies](#auth-and-access_iam-policies). To match a secret name, you create the ARN for the secret by putting together the Region, Account ID, secret name, and the wildcard (`?`) to match individual random characters. Secrets Manager appends six random characters to secret names as part of their ARN, so you can use this wildcard to match those characters. If you use the syntax `"another_secret_name-*"`, Secrets Manager matches not only the intended secret with the 6 random characters, but also matches `"another_secret_name-a1b2c3"`. Because you can predict all of the parts of the ARN of a secret except the 6 random characters, using the wildcard character `'??????'` syntax enables you to securely grant permissions to a secret that doesn't yet exist. Be aware, however, if you delete the secret and recreate it with the same name, the user automatically receives permission to the new secret, even though the 6 characters changed. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:*", "Resource": [ "arn:aws:secretsmanager:us-east-1:123456789012:secret:a_specific_secret_name-a1b2c3", "arn:aws:secretsmanager:us-east-1:123456789012:secret:another_secret_name-??????" ] } ] } ``` ## Example: Permission to create secrets To grant a user permissions to create a secret, we recommend you attach a permissions policy to an IAM group the user belongs to. See [IAM user groups](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html). **Example Create secrets** The following policy grants permission to create secrets and view a list of secrets. To use this policy, see [Identity-based policies](#auth-and-access_iam-policies). **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:CreateSecret", "secretsmanager:ListSecrets" ], "Resource": "*" } ] } ``` ## Example: Deny a specific AWS KMS key to encrypt secrets **Important** To deny a customer managed key, we recommend you restrict access using a key policy or key grant. For more information, see [Authentication and access control for AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) in the *AWS Key Management Service Developer Guide*. **Example Deny the AWS managed key `aws/secretsmanager`** The following policy denies the use of the AWS managed key `aws/secretsmanager` for creating or updating secrets. This policy requires secrets to be encrypted using a customer managed key. The policy includes two statements: 1. The first statement, `Sid: "RequireCustomerManagedKeysOnSecrets"`, denies requests for creating or updating secrets using the AWS managed key `aws/secretsmanager`. 1. The second statement, `Sid: "RequireKmsKeyIdParameterOnCreate"`, denies requests for creating secrets that don't include a KMS key, because Secrets Manager would default to using the AWS managed key `aws/secretsmanager`. **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "RequireCustomerManagedKeysOnSecrets", "Effect": "Deny", "Action": [ "secretsmanager:CreateSecret", "secretsmanager:UpdateSecret" ], "Resource": "*", "Condition": { "StringLikeIfExists": { "secretsmanager:KmsKeyArn": "" } } }, { "Sid": "RequireKmsKeyIdParameterOnCreate", "Effect": "Deny", "Action": "secretsmanager:CreateSecret", "Resource": "*", "Condition": { "Null": { "secretsmanager:KmsKeyArn": "true" } } } ] } ``` # Resource-based policies In a resource-based policy, you specify who can access the secret and the actions they can perform on the secret. You can use resource-based policies to: + Grant access to a single secret to multiple users and roles. + Grant access to users or roles in other AWS accounts. When you attach a resource-based policy to a secret in the console, Secrets Manager uses the automated reasoning engine [Zelkova](https://aws.amazon.com/blogs/security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova/) and the API `ValidateResourcePolicy` to prevent you from granting a wide range of IAM principals access to your secrets. Alternatively, you can call the `PutResourcePolicy` API with the `BlockPublicPolicy` parameter from the CLI or SDK. **Important** Resource policy validation and the `BlockPublicPolicy` parameter help protect your resources by preventing public access from being granted through the resource policies that are directly attached to your secrets. In addition to using these features, carefully inspect the following policies to confirm that they do not grant public access: Identity-based policies attached to associated AWS principals (for example, IAM roles) Resource-based policies attached to associated AWS resources (for example, AWS Key Management Service (AWS KMS) keys) To review permissions to your secrets, see [Determine who has permissions to your secrets](determine-acccess_examine-iam-policies.md). **To view, change, or delete the resource policy for a secret (console)** 1. Open the Secrets Manager console at [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). 1. From the list of secrets, choose your secret. 1. On the secret details page, on the **Overview** tab, in the **Resource permissions** section, choose **Edit permissions**. 1. In the code field, do one of the following, and then choose **Save**: + To attach or modify a resource policy, enter the policy. + To delete the policy, clear the code field. ## AWS CLI **Example Retrieve a resource policy** The following [https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-resource-policy.html](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-resource-policy.html) example retrieves the resource-based policy attached to a secret. ``` aws secretsmanager get-resource-policy \ --secret-id MyTestSecret ``` **Example Delete a resource policy** The following [https://docs.aws.amazon.com//cli/latest/reference/secretsmanager/delete-resource-policy.html](https://docs.aws.amazon.com//cli/latest/reference/secretsmanager/delete-resource-policy.html) example deletes the resource-based policy attached to a secret. ``` aws secretsmanager delete-resource-policy \ --secret-id MyTestSecret ``` **Example Add a resource policy** The following [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) example adds a permissions policy to a secret, checking first that the policy does not provide broad access to the secret. The policy is read from a file. For more information, see [Loading AWS CLI parameters from a file](https://docs.aws.amazon.com//cli/latest/userguide/cli-usage-parameters-file.html) in the AWS CLI User Guide. ``` aws secretsmanager put-resource-policy \ --secret-id MyTestSecret \ --resource-policy file://mypolicy.json \ --block-public-policy ``` Contents of `mypolicy.json`: **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/MyRole" }, "Action": "secretsmanager:GetSecretValue", "Resource": "*" } ] } ``` ## AWS SDK To retrieve the policy attached to a secret, use [https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetResourcePolicy.html](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetResourcePolicy.html). To delete a policy attached to a secret, use [https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_DeleteResourcePolicy.html](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_DeleteResourcePolicy.html). To attach a policy to a secret, use [https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_PutResourcePolicy.html](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_PutResourcePolicy.html). If there is already a policy attached, the command replaces it with the new policy. The policy must be formatted as JSON structured text. See [JSON policy document structure](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies-introduction). For more information, see [AWS SDKs](asm_access.md#asm-sdks). ## Examples **Topics** + [ ### Example: Permission to retrieve individual secret values ](#auth-and-access_examples_read) + [ ### Example: Permissions and VPCs ](#auth-and-access_examples_vpc) + [ ### Example: Service principal ](#auth-and-access_service) ### Example: Permission to retrieve individual secret values To grant permission to retrieve secret values, you can attach policies to secrets or identities. For help determining which type of policy to use, see [Identity-based policies and resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). For information about how to attach a policy, see [Resource-based policies](#auth-and-access_resource-policies) and [Identity-based policies](auth-and-access_iam-policies.md). This example is useful when you want to grant access to a single secret to multiple users or roles. To grant permission to retrieve a group of secrets in a batch API call, see [Example: Permission to retrieve a group of secret values in a batch](auth-and-access_iam-policies.md#auth-and-access_examples_batch). **Example Read one secret** You can grant access to a secret by attaching the following policy to the secret. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/EC2RoleToAccessSecrets" }, "Action": "secretsmanager:GetSecretValue", "Resource": "*" } ] } ``` ### Example: Permissions and VPCs If you need to access Secrets Manager from within a VPC, you can make sure that requests to Secrets Manager come from the VPC by including a condition in your permissions policies. For more information, see [Limit requests with VPC endpoint conditions](best-practices.md#iam-contextkeys-vpcendpoint) and [Using an AWS Secrets Manager VPC endpoint](vpc-endpoint-overview.md). Make sure that requests to access the secret from other AWS services also come from the VPC, otherwise this policy will deny them access. **Example Require requests to come through a VPC endpoint** The following policy allows a user to perform Secrets Manager operations only when the request comes through the VPC endpoint *`vpce-1234a5678b9012c`*. **** ``` { "Id": "example-policy-1", "Version":"2012-10-17", "Statement": [ { "Sid": "RestrictGetSecretValueoperation", "Effect": "Deny", "Principal": "*", "Action": "secretsmanager:GetSecretValue", "Resource": "*", "Condition": { "StringNotEquals": { "aws:sourceVpce": "vpce-12345678" } } } ] } ``` **Example Require requests to come from a VPC** The following policy allows commands to create and manage secrets only when they come from *`vpc-12345678`*. In addition, the policy allows operations that use access the secret encrypted value only when the requests come from `vpc-2b2b2b2b`. You might use a policy like this one if you run an application in one VPC, but you use a second, isolated VPC for management functions. **** ``` { "Id": "example-policy-2", "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAdministrativeActionsfromONLYvpc-12345678", "Effect": "Deny", "Principal": "*", "Action": [ "secretsmanager:Create*", "secretsmanager:Put*", "secretsmanager:Update*", "secretsmanager:Delete*", "secretsmanager:Restore*", "secretsmanager:RotateSecret", "secretsmanager:CancelRotate*", "secretsmanager:TagResource", "secretsmanager:UntagResource" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:sourceVpc": "vpc-12345678" } } }, { "Sid": "AllowSecretValueAccessfromONLYvpc-2b2b2b2b", "Effect": "Deny", "Principal": "*", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:sourceVpc": "vpc-2b2b2b2b" } } } ] } ``` ### Example: Service principal If the resource policy attached to your secret includes an [AWS service principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services), we recommend that you use the [aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition keys. The ARN and account values are included in the authorization context only when a request comes to Secrets Manager from another AWS service. This combination of conditions avoids a potential [confused deputy scenario](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). If a resource ARN includes characters that are not permitted in a resource policy, you cannot use that resource ARN in the value of the `aws:SourceArn` condition key. Instead, use the `aws:SourceAccount` condition key. For more information, see [IAM requirements](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-names). Service principals are not typically used as principals in a policy attached to a secret, but some AWS services require it. For information about resource policies that a service requires you to attach to a secret, see the service's documentation. **Example Allow a service to access a secret using a service principal** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "s3.amazonaws.com" ] }, "Action": "secretsmanager:GetSecretValue", "Resource": "*", "Condition": { "ArnLike": { "aws:sourceArn": "arn:aws:s3::123456789012:*" }, "StringEquals": { "aws:sourceAccount": "123456789012" } } } ] } ``` # Control access to secrets using attribute-based access control (ABAC) Control access to secrets using tags Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes or characteristics of the user, the data, or the environment, such as the department, business unit, or other factors that could affect the authorization outcome. In AWS, these attributes are called *tags*. Using tags to control permissions is helpful in environments that are growing rapidly and helps with situations where policy management becomes cumbersome. ABAC rules are evaluated dynamically at runtime, which means that the users' access to applications and data and the type of allowed operations automatically change based on the contextual factors in the policy. For example, if a user changes department, access is automatically adjusted without the need to update permissions or request new roles. For more information, see: [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html), [Define permissions to access secrets based on tags.](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html), and [Scale your authorization needs for Secrets Manager using ABAC with IAM Identity Center](https://aws.amazon.com/blogs/security/scale-your-authorization-needs-for-secrets-manager-using-abac-with-iam-identity-center/). ## Example: Allow an identity access to secrets that have specific tags The following policy allows `DescribeSecret` access on secrets with a tag with the key *ServerName* and the value *ServerABC*. If you attach this policy to an identity, the identity has permission to any secrets with that tag in the account. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "secretsmanager:DescribeSecret", "Resource": "*", "Condition": { "StringEquals": { "secretsmanager:ResourceTag/ServerName": "ServerABC" } } } } ``` ------ ## Example: Allow access only to identities with tags that match secrets' tags The following policy allows any identities in the account `GetSecretValue` access to any secrets in the account where the identity's *`AccessProject`* tag has the same value as the secret's *`AccessProject`* tag. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "AWS": "123456789012" }, "Condition": { "StringEquals": { "aws:ResourceTag/AccessProject": "${ aws:PrincipalTag/AccessProject }" } }, "Action": "secretsmanager:GetSecretValue", "Resource": "*" } } ``` ------ # AWS managed policy for AWS Secrets Manager AWS managed policies An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. ## AWS managed policy: SecretsManagerReadWrite SecretsManagerReadWrite This policy provides read/write access to AWS Secrets Manager, including permission to describe Amazon RDS, Amazon Redshift, and Amazon DocumentDB resources, and permission to use AWS KMS to encrypt and decrypt secrets. This policy also provides permission to create AWS CloudFormation change sets, get rotation templates from an Amazon S3 bucket that is managed by AWS, list AWS Lambda functions, and describe Amazon EC2 VPCs. These permissions are required by the console to set up rotation with existing rotation functions. To create new rotation functions, you must also have permission to create AWS CloudFormation stacks and AWS Lambda execution roles. You can assign the [IAMFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/IAMFullAccess.html) managed policy. See [Permissions for rotation](rotating-secrets-required-permissions-function.md). **Permissions details** This policy includes the following permissions. + `secretsmanager` – Allows principals to perform all Secrets Manager actions. + `cloudformation` – Allows principals to create CloudFormation stacks. This is required so that principals using the console to turn on rotation can create Lambda rotation functions through CloudFormation stacks. For more information, see [How Secrets Manager uses AWS CloudFormation](cloudformation.md#how-asm-uses-cfn). + `ec2` – Allows principals to describe Amazon EC2 VPCs. This is required so that principals using the console can create rotation functions in the same VPC as the database of the credentials they are storing in a secret. + `kms` – Allows principals to use AWS KMS keys for cryptographic operations. This is required so that Secrets Manager can encrypt and decrypt secrets. For more information, see [Secret encryption and decryption in AWS Secrets Manager](security-encryption.md). + `lambda` – Allows principals to list Lambda rotation functions. This is required so that principals using the console can choose existing rotation functions. + `rds` – Allows principals to describe clusters and instances in Amazon RDS. This is required so that principals using the console can choose Amazon RDS clusters or instances. + `redshift` – Allows principals to describe clusters in Amazon Redshift. This is required so that principals using the console can choose Amazon Redshift clusters. + `redshift-serverless` – Allows principals to describe namespaces in Amazon Redshift Serverless. This is required so that principals using the console can choose Amazon Redshift Serverless namespaces. + `docdb-elastic` – Allows principals to describe elastic clusters in Amazon DocumentDB. This is required so that principals using the console can choose Amazon DocumentDB elastic clusters. + `tag` – Allows principals to get all resources in the account that are tagged. + `serverlessrepo` – Allows principals to create CloudFormation change sets. This is required so that principals using the console can create Lambda rotation functions. For more information, see [How Secrets Manager uses AWS CloudFormation](cloudformation.md#how-asm-uses-cfn). + `s3` – Allows principals to get objects from an Amazon S3 bucket that is managed by AWS. This bucket contains Lambda [Rotation function templates](reference_available-rotation-templates.md). This permission is required so that principals using the console can create Lambda rotation functions based on the templates in the bucket. For more information, see [How Secrets Manager uses AWS CloudFormation](cloudformation.md#how-asm-uses-cfn). To view the policy, see [SecretsManagerReadWrite JSON policy document](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecretsManagerReadWrite.html#SecretsManagerReadWrite-json). ## AWS managed policy: AWSSecretsManagerClientReadOnlyAccess AWSSecretsManagerClientReadOnlyAccess This policy provides read-only access to AWS Secrets Manager secrets for client applications. It allows principals to retrieve secret values and describe secret metadata, along with the necessary AWS KMS permissions to decrypt secrets that are encrypted with customer-managed keys. **Permissions details** This policy includes the following permissions. + `secretsmanager` – Allows principals to retrieve secret values and describe secret metadata. + `kms` – Allows principals to decrypt secrets using AWS KMS keys. This permission is scoped to keys used by Secrets Manager through service-specific conditions. To view more details about the policy, including the latest version of the JSON policy document, see [AWSSecretsManagerClientReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSSecretsManagerClientReadOnlyAccess.html) in the *AWS Managed Policy Reference Guide*. ## Secrets Manager updates to AWS managed policies Policy updates View details about updates to AWS managed policies for Secrets Manager. | Change | Description | Date | Version | | --- | --- | --- | --- | | [AWSSecretsManagerClientReadOnlyAccess](#security-iam-awsmanpol-AWSSecretsManagerClientReadOnlyAccess) – New managed policy | Secrets Manager created a new managed policy to provide read-only access to secrets for client applications. This policy allows retrieving secret values and describing secret metadata, with the necessary AWS KMS permissions to decrypt secrets. | November 5, 2025 | v1 | | [SecretsManagerReadWrite](#security-iam-awsmanpol-SecretsManagerReadWrite) – Update to an existing policy | This policy was updated to allow describe access to Amazon Redshift Serverless so that console users can choose a Amazon Redshift Serverless namespace when they create an Amazon Redshift secret. | March 12, 2024 | v5 | | [SecretsManagerReadWrite](#security-iam-awsmanpol-SecretsManagerReadWrite) – Update to an existing policy | This policy was updated to allow describe access to Amazon DocumentDB elastic clusters so that console users can choose an elastic cluster when they create an Amazon DocumentDB secret. | September 12, 2023 | v4 | | [SecretsManagerReadWrite](#security-iam-awsmanpol-SecretsManagerReadWrite) – Update to an existing policy | This policy was updated to allow describe access to Amazon Redshift so that console users can choose a Amazon Redshift cluster when they create an Amazon Redshift secret. The update also added new permissions to allow read access to an Amazon S3 bucket managed by AWS that stores the Lambda rotation function templates. | June 24, 2020 | v3 | | [SecretsManagerReadWrite](#security-iam-awsmanpol-SecretsManagerReadWrite) – Update to an existing policy | This policy was updated to allow describe access to Amazon RDS clusters so that console users can choose a cluster when they create an Amazon RDS secret. | May 3, 2018 | v2 | | [SecretsManagerReadWrite](#security-iam-awsmanpol-SecretsManagerReadWrite) – New policy | Secrets Manager created a policy to grant permissions that are needed for using the console with all read/write access to Secrets Manager. | April 04, 2018 | v1 | # Determine who has permissions to your AWS Secrets Manager secrets Determine who has permissions to your secrets By default, IAM identities don't have permission to access secrets. When authorizing access to a secret, Secrets Manager evaluates the resource-based policy attached to the secret and all identity-based policies attached to the IAM user or role sending the request. To do this, Secrets Manager uses a process similar to the one described in [Determining whether a request is allowed or denied](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow) in the *IAM User Guide*. When multiple policies apply to a request, Secrets Manager uses a hierarchy to control permissions: 1. If a statement in any policy with an explicit `deny` matches the request action and resource: The explicit `deny` overrides everything else and blocks the action. 1. If there is no explicit `deny`, but a statement with an explicit `allow` matches the request action and resource: The explicit `allow` grants the action in the request access to the resources in the statement. If the identity and the secret are in two different accounts, there must be an `allow` in both the resource policy for the secret and the policy attached to the identity, otherwise AWS denies the request. For more information, see [Cross-account access](auth-and-access_examples_cross.md). 1. If there is no statement with an explicit `allow` that matches the request action and resource: AWS denies the request by default, which is called an *implicit* deny. **To view the resource-based policy for a secret** + Do one of the following: + Open the Secrets Manager console at [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). In the secret details page for your secret, in the **Resource permissions** section, choose **Edit permissions**. + Use the AWS CLI to call [https://docs.aws.amazon.com//cli/latest/reference/secretsmanager/get-resource-policy.html](https://docs.aws.amazon.com//cli/latest/reference/secretsmanager/get-resource-policy.html) or AWS SDK to call [https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetResourcePolicy.html](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetResourcePolicy.html). **To determine who has access through identity-based policies** + Use the IAM policy simulator. See [Testing IAM policies with the IAM policy simulator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html) # Access AWS Secrets Manager secrets from a different account Cross-account access To allow users in one account to access secrets in another account (*cross-account access*), you must allow access both in a resource policy and in an identity policy. This is different than granting access to identities in the same account as the secret. Cross-account permission is effective only for the following operations: + [CancelRotateSecret](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_CancelRotateSecret.html) + [DeleteResourcePolicy](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_DeleteResourcePolicy.html) + [DeleteSecret](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_DeleteSecret.html) + [DescribeSecret](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_DescribeSecret.html) + [GetRandomPassword](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_GetRandomPassword.html) + [GetResourcePolicy](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_GetResourcePolicy.html) + [GetSecretValue](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_GetSecretValue.html) + [ListSecretVersionIds](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_ListSecretVersionIds.html) + [PutResourcePolicy](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_PutResourcePolicy.html) + [PutSecretValue](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_PutSecretValue.html) + [RemoveRegionsFromReplication](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_RemoveRegionsFromReplication.html) + [ReplicateSecretToRegions](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_ReplicateSecretToRegions.html) + [RestoreSecret](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_RestoreSecret.html) + [RotateSecret](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_RotateSecret.html) + [StopReplicationToReplica](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_StopReplicationToReplica.html) + [TagResource](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_TagResource.html) + [UntagResource](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_UntagResource.html) + [UpdateSecret](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_UpdateSecret.html) + [UpdateSecretVersionStage](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_UpdateSecretVersionStage.html) + [ValidateResourcePolicy](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_ValidateResourcePolicy.html) You can use the `BlockPublicPolicy` parameter with the [PutResourcePolicy](https://docs.aws.amazon.com//secretsmanager/latest/apireference/API_PutResourcePolicy.html) action to help protect your resources by preventing public access from being granted through the resource policies that are directly attached to your secrets. You can also use [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-preview-access) to verify cross-account access. You must also allow the identity to use the KMS key that the secret is encrypted with. This is because you can't use the AWS managed key (`aws/secretsmanager`) for cross-account access. Instead, you must encrypt your secret with a KMS key that you create, and then attach a key policy to it. There is a charge for creating KMS keys. To change the encryption key for a secret, see [Modify an AWS Secrets Manager secret](manage_update-secret.md). **Important** Resource-based policies granting `secretsmanager:PutResourcePolicy` permission gives principals, even those in other accounts, the ability to modify your resource-based policies. This permission lets principals escalate existing permissions like obtaining full administrative access to secrets. We recommend you apply the principle of [least privileged access](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) to your policies. For more information, see [Resource-based policies](auth-and-access_resource-policies.md). The following example policies assume you have a secret and encryption key in *Account1*, and an identity in *Account2* that you want to allow to access the secret value. **Step 1: Attach a resource policy to the secret in *Account1*** + The following policy allows *ApplicationRole* in *Account2* to access the secret in *Account1*. To use this policy, see [Resource-based policies](auth-and-access_resource-policies.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/ApplicationRole" }, "Action": "secretsmanager:GetSecretValue", "Resource": "*" } ] } ``` ------ **Step 2: Add a statement to the key policy for the KMS key in *Account1*** + The following key policy statement allows *ApplicationRole* in *Account2* to use the KMS key in *Account1* to decrypt the secret in *Account1*. To use this statement, add it to the key policy for your KMS key. For more information, see [Changing a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html). ``` { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::Account2:role/ApplicationRole" }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" } ``` **Step 3: Attach an identity policy to the identity in *Account2*** + The following policy allows *ApplicationRole* in *Account2* to access the secret in *Account1* and decrypt the secret value by using the encryption key which is also in *Account1*. To use this policy, see [Identity-based policies](auth-and-access_iam-policies.md). You can find the ARN for your secret in the Secrets Manager console on the secret details page under **Secret ARN**. Alternatively, you can call [https://docs.aws.amazon.com//cli/latest/reference/secretsmanager/describe-secret.html](https://docs.aws.amazon.com//cli/latest/reference/secretsmanager/describe-secret.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf" }, { "Effect": "Allow", "Action": "kms:Decrypt", "Resource": "arn:aws:kms:us-east-1:123456789012:key/EncryptionKey" } ] } ``` ------ # Access secrets from an on-premises environment On-premises access You can use AWS Identity and Access Management Roles Anywhere to obtain temporary security credentials in IAM for workloads such as servers, containers, and applications that run outside of AWS. Your workloads can use the same IAM policies and IAM roles that you use with AWS applications to access AWS resources. With IAM Roles Anywhere, you can use Secrets Manager to store and manage credentials that can be accessed by resources in AWS as well as on-premises devices such as application servers. For more information, see the [IAM Roles Anywhere User Guide](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html).