# Example IAM identity-based policies Example policies A [policy](access_policies.md) is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents that are attached to an IAM identity (user, group of users, or role). Identity-based policies include AWS managed policies, customer managed policies, and inline policies. To learn how to create an IAM policy using these example JSON policy documents, see [Creating policies using the JSON editor](access_policies_create-console.md#access_policies_create-json-editor). By default all requests are denied, so you must provide access to the services, actions, and resources that you intend for the identity to access. If you also want to allow access to complete the specified actions in the IAM console, you need to provide additional permissions. The following library of policies can help you define permissions for your IAM identities. After you find the policy that you need, choose **view this policy** to view the JSON for the policy. You can use the JSON policy document as a template for your own policies. **Note** If you would like to submit a policy to be included in this reference guide, use the **Feedback** button at the bottom of this page. ## Example policies: AWS + Allows access during a specific range of dates. ([View this policy](reference_policies_examples_aws-dates.md).) + Allows enabling and disabling AWS Regions. ([View this policy](reference_policies_examples_aws-enable-disable-regions.md).) + Allows MFA-authenticated users to manage their own credentials on the **Security credentials** page. ([View this policy](reference_policies_examples_aws_my-sec-creds-self-manage.md).) + Allows specific access when using MFA during a specific range of dates. ([View this policy](reference_policies_examples_aws_mfa-dates.md).) + Allows users to manage their own credentials on the **Security credentials** page. ([View this policy](reference_policies_examples_aws_my-sec-creds-self-manage-no-mfa.md).) + Allows users to manage their own MFA device on the **Security credentials** page. ([View this policy](reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.md).) + Allows users to manage their own password on the **Security credentials** page. ([View this policy](reference_policies_examples_aws_my-sec-creds-self-manage-password-only.md).) + Allows users to manage their own password, access keys, and SSH public keys on the **Security credentials** page. ([View this policy](reference_policies_examples_aws_my-sec-creds-self-manage-pass-accesskeys-ssh.md).) + Denies access to AWS based on the requested Region. ([View this policy](reference_policies_examples_aws_deny-requested-region.md).) + Denies access to AWS based on the source IP address. ([View this policy](reference_policies_examples_aws_deny-ip.md).) ## Example policy: AWS Data Exchange + Deny access to Amazon S3 resources outside of your account except AWS Data Exchange. ([View this policy](reference_policies_examples_resource_account_data_exch.md).) ## Example policies: AWS Data Pipeline + Denies access to pipelines that a user did not create ([View this policy](reference_policies_examples_datapipeline_not-owned.md).) ## Example policies: Amazon DynamoDB + Allows access to a specific Amazon DynamoDB table ([View this policy](reference_policies_examples_dynamodb_specific-table.md).) + Allows access to specific Amazon DynamoDB attributes ([View this policy](reference_policies_examples_dynamodb_attributes.md).) + Allows item-level access to Amazon DynamoDB based on an Amazon Cognito ID ([View this policy](reference_policies_examples_dynamodb_items.md).) ## Example policies: Amazon EC2 + Allows attaching or detaching Amazon EBS volumes to Amazon EC2 instances based on tags ([View this policy](reference_policies_examples_ec2_ebs-owner.md).) + Allows launching Amazon EC2 instances in a specific subnet, programmatically and in the console ([View this policy](reference_policies_examples_ec2_instances-subnet.md).) + Allows managing Amazon EC2 security groups associated with a specific VPC, programmatically and in the console ([View this policy](reference_policies_examples_ec2_securitygroups-vpc.md).) + Allows starting or stopping Amazon EC2 instances a user has tagged, programmatically and in the console ([View this policy](reference_policies_examples_ec2_tag-owner.md).) + Allows starting or stopping Amazon EC2 instances based on resource and principal tags, programmatically and in the console ([View this policy](reference_policies_examples_ec2-start-stop-tags.md).) + Allows starting or stopping Amazon EC2 instances when the resource and principal tags match ([View this policy](reference_policies_examples_ec2-start-stop-match-tags.md).) + Allows full Amazon EC2 access within a specific Region, programmatically and in the console. ([View this policy](reference_policies_examples_ec2_region.md).) + Allows starting or stopping a specific Amazon EC2 instance and modifying a specific security group, programmatically and in the console ([View this policy](reference_policies_examples_ec2_instance-securitygroup.md).) + Denies access to specific Amazon EC2 operations without MFA ([View this policy](reference_policies_examples_ec2_require-mfa.md).) + Limits terminating Amazon EC2 instances to a specific IP address range ([View this policy](reference_policies_examples_ec2_terminate-ip.md).) ## Example policies: AWS Identity and Access Management (IAM) + Allows access to the policy simulator API ([View this policy](reference_policies_examples_iam_policy-sim.md).) + Allows access to the policy simulator console ([View this policy](reference_policies_examples_iam_policy-sim-console.md).) + Allows assuming any roles that have a specific tag, programmatically and in the console ([View this policy](reference_policies_examples_iam-assume-tagged-role.md).) + Allows and denies access to multiple services, programmatically and in the console ([View this policy](reference_policies_examples_iam_multiple-services-console.md).) + Allows adding a specific tag to an IAM user with a different specific tag, programmatically and in the console ([View this policy](reference_policies_examples_iam-add-tag.md).) + Allows adding a specific tag to any IAM user or role, programmatically and in the console ([View this policy](reference_policies_examples_iam-add-tag-user-role.md).) + Allows creating a new user only with specific tags ([View this policy](reference_policies_examples_iam-new-user-tag.md).) + Allows generating and retrieving IAM credential reports ([View this policy](reference_policies_examples_iam-credential-report.md).) + Allows managing a group's membership, programmatically and in the console ([View this policy](reference_policies_examples_iam_manage-group-membership.md).) + Allows managing a specific tag ([View this policy](reference_policies_examples_iam-manage-tags.md).) + Allows passing an IAM role to a specific service ([View this policy](reference_policies_examples_iam-passrole-service.md).) + Allows read-only access to the IAM console without reporting ([View this policy](reference_policies_examples_iam_read-only-console-no-reporting.md).) + Allows read-only access to the IAM console ([View this policy](reference_policies_examples_iam_read-only-console.md).) + Allows specific users to manage a group, programmatically and in the console ([View this policy](reference_policies_examples_iam_users-manage-group.md).) + Allows setting the account password requirements, programmatically and in the console ([View this policy](reference_policies_examples_iam_set-account-pass-policy.md).) + Allows using the policy simulator API for users with a specific path ([View this policy](reference_policies_examples_iam_policy-sim-path.md).) + Allows using the policy simulator console for users with a specific path ([View this policy](reference_policies_examples_iam_policy-sim-path-console.md).) + Allows IAM users to self-manage an MFA device. ([View this policy](reference_policies_examples_iam_mfa-selfmanage.md).) + Allows IAM users to set their own credentials, programmatically and in the console. ([View this policy](reference_policies_examples_iam_credentials_console.md).) + Allows viewing service last accessed information for an AWS Organizations policy in the IAM console. ([View this policy](reference_policies_examples_iam_service-accessed-data-orgs.md).) + Limits managed policies that can be applied to an IAM user, group, or role ([View this policy](reference_policies_examples_iam_limit-managed.md).) + Allows access to IAM policies only in your account ([View this policy](resource_examples_iam_policies_resource_account.md).) ## Example policies: AWS Lambda + Allows an AWS Lambda function to access an Amazon DynamoDB table ([View this policy](reference_policies_examples_lambda-access-dynamodb.md).) ## Example policies: Amazon RDS + Allows full Amazon RDS database access within a specific Region. ([View this policy](reference_policies_examples_rds_region.md).) + Allows restoring Amazon RDS databases, programmatically and in the console ([View this policy](reference_policies_examples_rds_db-console.md).) + Allows tag owners full access to Amazon RDS resources that they have tagged ([View this policy](reference_policies_examples_rds_tag-owner.md).) ## Example policies: Amazon S3 + Allows an Amazon Cognito user to access objects in their own Amazon S3 bucket ([View this policy](reference_policies_examples_s3_cognito-bucket.md).) + Allows a user with temporary credentials to access their own home directory in Amazon S3, programmatically and in the console ([View this policy](reference_policies_examples_s3_federated-home-directory-console.md).) + Allows full S3 access, but explicitly denies access to the Production bucket if the administrator has not signed in using MFA within the last thirty minutes ([View this policy](reference_policies_examples_s3_full-access-except-production.md).) + Allows IAM users to access their own home directory in Amazon S3, programmatically and in the console ([View this policy](reference_policies_examples_s3_home-directory-console.md).) + Allows a user to manage a single Amazon S3 bucket and denies every other AWS action and resource ([View this policy](reference_policies_examples_s3_deny-except-bucket.md).) + Allows `Read` and `Write` access to a specific Amazon S3 bucket ([View this policy](reference_policies_examples_s3_rw-bucket.md).) + Allows `Read` and `Write` access to a specific Amazon S3 bucket, programmatically and in the console ([View this policy](reference_policies_examples_s3_rw-bucket-console.md).) # AWS: Allows access based on date and time AWS: Specific access during a date range This example shows how you might create an identity-based policy that allows access to actions based on date and time. This policy restricts access to actions that occur between April 1, 2020 and June 30, 2020 (UTC), inclusive. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). To learn about using multiple conditions within the `Condition` block of an IAM policy, see [Multiple values in a condition](reference_policies_elements_condition.md#Condition-multiple-conditions). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "service-prefix:action-name", "Resource": "*", "Condition": { "DateGreaterThan": {"aws:CurrentTime": "2020-04-01T00:00:00Z"}, "DateLessThan": {"aws:CurrentTime": "2020-06-30T23:59:59Z"} } } ] } ``` ------ **Note** You cannot use a policy variable with the Date condition operator. To learn more see [Condition element](reference_policies_variables.md#policy-vars-conditionelement) # AWS: Allows enabling and disabling AWS Regions AWS: Enable or disable AWS Regions This example shows how you might create an identity-based policy that allows an administrator to enable and disable the Asia Pacific (Hong Kong) Region (ap-east-1). This policy defines permissions for programmatic and console access. This setting appears in the **Account settings** page in the AWS Management Console. This page includes sensitive account-level information that should be viewed and managed only by account administrators. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). **Important** You cannot enable or disable regions that are enabled by default. You can only include regions that are *disabled* by default. For more information, see [Managing AWS Regions](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) in the *AWS General Reference*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EnableDisableHongKong", "Effect": "Allow", "Action": [ "account:EnableRegion", "account:DisableRegion" ], "Resource": "*", "Condition": { "StringEquals": {"account:TargetRegion": "ap-east-1"} } }, { "Sid": "ViewConsole", "Effect": "Allow", "Action": [ "account:ListRegions" ], "Resource": "*" } ] } ``` ------ # AWS: Allows MFA-authenticated IAM users to manage their own credentials on the Security credentials page AWS: Self-manage credentials with MFA (Security credentials) This example shows how you might create an identity-based policy that allows IAM users that are authenticated using [multi-factor authentication (MFA)](id_credentials_mfa.md) to manage their own credentials on the **Security credentials** page. This AWS Management Console page displays account information such as the account ID and canonical user ID. Users can also view and edit their own passwords, access keys, MFA devices, X.509 certificates, and SSH keys and Git credentials. This example policy includes the permissions required to view and edit all of the information on the page. It also requires the user to set up and authenticate using MFA before performing any other operations in AWS. To allow users to manage their own credentials without using MFA, see [AWS: Allows IAM users to manage their own credentials on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage-no-mfa.md). To learn how users can access the **Security credentials** page, see [How IAM users change their own password (console)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console). **Note** This example policy does not allow users to reset a password while signing in to the AWS Management Console for the first time. We recommend that you do not grant permissions to new users until after they sign in. For more information, see [How do I securely create IAM users?](troubleshoot.md#troubleshoot_general_securely-create-iam-users). This also prevents users with an expired password from resetting their password during sign in. You can allow this by adding `iam:ChangePassword` and `iam:GetAccountPasswordPolicy` to the statement `DenyAllExceptListedIfNoMFA`. However, we do not recommend this because allowing users to change their password without MFA can be a security risk. If you intend to use this policy for programmatic access you must call [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) to authenticate with MFA. For more information, see [Secure API access with MFA](id_credentials_mfa_configure-api-require.md). **What does this policy do?** + The `AllowViewAccountInfo` statement allows the user to view account-level information. These permissions must be in their own statement because they do not support or do not need to specify a resource ARN. Instead the permissions specify `"Resource" : "*"`. This statement includes the following actions that allow the user to view specific information: + `GetAccountPasswordPolicy` – View the account password requirements while changing their own IAM user password. + `ListVirtualMFADevices` – View details about a virtual MFA device that is enabled for the user. + The `AllowManageOwnPasswords` statement allows the user to change their own password. This statement also includes the `GetUser` action, which is required to view most of the information on the **My security credentials** page. + The `AllowManageOwnAccessKeys` statement allows the user to create, update, and delete their own access keys. The user can also retrieve information about when the specified access key was last used. + The `AllowManageOwnSigningCertificates` statement allows the user to upload, update, and delete their own signing certificates. + The `AllowManageOwnSSHPublicKeys` statement allows the user to upload, update, and delete their own SSH public keys for CodeCommit. + The `AllowManageOwnGitCredentials` statement allows the user to create, update, and delete their own Git credentials for CodeCommit. + The `AllowManageOwnVirtualMFADevice` statement allows the user to create their own virtual MFA device. The resource ARN in this statement allows the user to create an MFA device with any name, but the other statements in the policy only allow the user to attach the device to the currently signed-in user. + The `AllowManageOwnUserMFA` statement allows the user to view or manage the virtual, U2F, or hardware MFA device for their own user. The resource ARN in this statement allows access to only the user's own IAM user. Users can't view or manage the MFA device for other users. + The `DenyAllExceptListedIfNoMFA` statement denies access to every action in all AWS services, except a few listed actions, but ***only if*** the user is not signed in with MFA. The statement uses a combination of `"Deny"` and `"NotAction"` to explicitly deny access to every action that is not listed. The items listed are not denied or allowed by this statement. However, the actions are allowed by other statements in the policy. For more information about the logic for this statement, see [NotAction with Deny](reference_policies_elements_notaction.md). If the user is signed in with MFA, then the `Condition` test fails and this statement does not deny any actions. In this case, other policies or statements for the user determine the user's permissions. This statement ensures that when the user is not signed in with MFA that they can perform only the listed actions. In addition, they can perform the listed actions only if another statement or policy allows access to those actions. This does not allow a user to create a password at sign-in, because `iam:ChangePassword` action should not be allowed without MFA authorization. The `...IfExists` version of the `Bool` operator ensures that if the `aws:MultiFactorAuthPresent` key is missing, the condition returns true. This means that a user accessing an API with long-term credentials, such as an access key, is denied access to the non-IAM API operations. This policy does not allow users to view the **Users** page in the IAM console or use that page to access their own user information. To allow this, add the `iam:ListUsers` action to the `AllowViewAccountInfo` statement and the `DenyAllExceptListedIfNoMFA` statement. It also does not allow users to change their password on their own user page. To allow this, add the `iam:GetLoginProfile` and `iam:UpdateLoginProfile` actions to the `AllowManageOwnPasswords` statement. To also allow a user to change their password from their own user page without signing in using MFA, add the `iam:UpdateLoginProfile` action to the `DenyAllExceptListedIfNoMFA` statement. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowViewAccountInfo", "Effect": "Allow", "Action": [ "iam:GetAccountPasswordPolicy", "iam:ListVirtualMFADevices" ], "Resource": "*" }, { "Sid": "AllowManageOwnPasswords", "Effect": "Allow", "Action": [ "iam:ChangePassword", "iam:GetUser" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnAccessKeys", "Effect": "Allow", "Action": [ "iam:CreateAccessKey", "iam:DeleteAccessKey", "iam:ListAccessKeys", "iam:UpdateAccessKey", "iam:GetAccessKeyLastUsed" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnSigningCertificates", "Effect": "Allow", "Action": [ "iam:DeleteSigningCertificate", "iam:ListSigningCertificates", "iam:UpdateSigningCertificate", "iam:UploadSigningCertificate" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnSSHPublicKeys", "Effect": "Allow", "Action": [ "iam:DeleteSSHPublicKey", "iam:GetSSHPublicKey", "iam:ListSSHPublicKeys", "iam:UpdateSSHPublicKey", "iam:UploadSSHPublicKey" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnGitCredentials", "Effect": "Allow", "Action": [ "iam:CreateServiceSpecificCredential", "iam:DeleteServiceSpecificCredential", "iam:ListServiceSpecificCredentials", "iam:ResetServiceSpecificCredential", "iam:UpdateServiceSpecificCredential" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnVirtualMFADevice", "Effect": "Allow", "Action": [ "iam:CreateVirtualMFADevice" ], "Resource": "arn:aws:iam::*:mfa/*" }, { "Sid": "AllowManageOwnUserMFA", "Effect": "Allow", "Action": [ "iam:DeactivateMFADevice", "iam:EnableMFADevice", "iam:ListMFADevices", "iam:ResyncMFADevice" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "DenyAllExceptListedIfNoMFA", "Effect": "Deny", "NotAction": [ "iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:GetMFADevice", "iam:ListMFADevices", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice", "sts:GetSessionToken" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } } ] } ``` ------ # AWS: Allows specific access using MFA within specific dates AWS: Specific access with MFA during a date range This example shows how you might create an identity-based policy that uses multiple conditions, which are evaluated using a logical `AND`. It allows full access to the service named `SERVICE-NAME-1`, and access to the `ACTION-NAME-A` and `ACTION-NAME-B` actions in the service named `SERVICE-NAME-2`. These actions are allowed only when the user is authenticated using [multifactor authentication (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html). Access is restricted to actions that occur between July 1, 2017 and December 31, 2017 (UTC), inclusive. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). To learn about using multiple conditions within the `Condition` block of an IAM policy, see [Multiple values in a condition](reference_policies_elements_condition.md#Condition-multiple-conditions). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "service-prefix-1:*", "service-prefix-2:action-name-a", "service-prefix-2:action-name-b" ], "Resource": "*", "Condition": { "Bool": {"aws:MultiFactorAuthPresent": true}, "DateGreaterThan": {"aws:CurrentTime": "2017-07-01T00:00:00Z"}, "DateLessThan": {"aws:CurrentTime": "2017-12-31T23:59:59Z"} } } } ``` ------ # AWS: Allows IAM users to manage their own credentials on the Security credentials page AWS: Self-manage credentials no MFA (Security credentials) This example shows how you might create an identity-based policy that allows IAM users to manage all of their own credentials on the **Security credentials** page. This AWS Management Console page displays account information such as the account ID and canonical user ID. Users can also view and edit their own passwords, access keys, X.509 certificates, SSH keys, and Git credentials. This example policy includes the permissions required to view and edit all information on the page *except* the user's MFA device. To allow users to manage their own credentials with MFA, see [AWS: Allows MFA-authenticated IAM users to manage their own credentials on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage.md). To learn how users can access the **Security credentials** page, see [How IAM users change their own password (console)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console). **What does this policy do? ** + The `AllowViewAccountInfo` statement allows the user to view account-level information. These permissions must be in their own statement because they do not support or do not need to specify a resource ARN. Instead the permissions specify `"Resource" : "*"`. This statement includes the following actions that allow the user to view specific information: + `GetAccountPasswordPolicy` – View the account password requirements while changing their own IAM user password. + `GetAccountSummary` – View the account ID and the account [canonical user ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId). + The `AllowManageOwnPasswords` statement allows the user to change their own password. This statement also includes the `GetUser` action, which is required to view most of the information on the **My security credentials** page. + The `AllowManageOwnAccessKeys` statement allows the user to create, update, and delete their own access keys. The user can also retrieve information about when the specified access key was last used. + The `AllowManageOwnSigningCertificates` statement allows the user to upload, update, and delete their own signing certificates. + The `AllowManageOwnSSHPublicKeys` statement allows the user to upload, update, and delete their own SSH public keys for CodeCommit. + The `AllowManageOwnGitCredentials` statement enables the user to create, update, and delete their own Git credentials for CodeCommit. This policy does not allow users to view or manage their own MFA devices. They also cannot view the **Users** page in the IAM console or use that page to access their own user information. To allow this, add the `iam:ListUsers` action to the `AllowViewAccountInfo` statement. It also does not allow users to change their password on their own user page. To allow this, add the `iam:CreateLoginProfile`, `iam:DeleteLoginProfile`, `iam:GetLoginProfile`, and `iam:UpdateLoginProfile` actions to the `AllowManageOwnPasswords` statement. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowViewAccountInfo", "Effect": "Allow", "Action": [ "iam:GetAccountPasswordPolicy", "iam:GetAccountSummary" ], "Resource": "*" }, { "Sid": "AllowManageOwnPasswords", "Effect": "Allow", "Action": [ "iam:ChangePassword", "iam:GetUser" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnAccessKeys", "Effect": "Allow", "Action": [ "iam:CreateAccessKey", "iam:DeleteAccessKey", "iam:ListAccessKeys", "iam:UpdateAccessKey", "iam:GetAccessKeyLastUsed" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnSigningCertificates", "Effect": "Allow", "Action": [ "iam:DeleteSigningCertificate", "iam:ListSigningCertificates", "iam:UpdateSigningCertificate", "iam:UploadSigningCertificate" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnSSHPublicKeys", "Effect": "Allow", "Action": [ "iam:DeleteSSHPublicKey", "iam:GetSSHPublicKey", "iam:ListSSHPublicKeys", "iam:UpdateSSHPublicKey", "iam:UploadSSHPublicKey" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnGitCredentials", "Effect": "Allow", "Action": [ "iam:CreateServiceSpecificCredential", "iam:DeleteServiceSpecificCredential", "iam:ListServiceSpecificCredentials", "iam:ResetServiceSpecificCredential", "iam:UpdateServiceSpecificCredential" ], "Resource": "arn:aws:iam::*:user/${aws:username}" } ] } ``` ------ # AWS: Allows MFA-authenticated IAM users to manage their own MFA device on the Security credentials page AWS: Self-manage MFA device (Security credentials) This example shows how you might create an identity-based policy that allows IAM users that are authenticated through [multi-factor authentication (MFA)](id_credentials_mfa.md) to manage their own MFA device on the **Security credentials** page. This AWS Management Console page displays account and user information, but the user can only view and edit their own MFA device. To allow users to manage all of their own credentials with MFA, see [AWS: Allows MFA-authenticated IAM users to manage their own credentials on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage.md). **Note** If an IAM user with this policy is not MFA-authenticated, this policy denies access to all AWS actions except those necessary to authenticate using MFA. To use the AWS CLI and AWS API, IAM users must first retrieve their MFA token using the AWS STS [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) operation and then use that token to authenticate the desired operation. Other policies, such as resource-based policies or other identity-based policies can allow actions in other services. This policy will deny that access if the IAM user is not MFA-authenticated. To learn how users can access the **Security credentials** page, see [How IAM users change their own password (console)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console). **What does this policy do? ** + The `AllowViewAccountInfo` statement allows the user to view details about a virtual MFA device that is enabled for the user. This permission must be in its own statement because it does not support specifying a resource ARN. Instead you must specify `"Resource" : "*"`. + The `AllowManageOwnVirtualMFADevice` statement allows the user to create their own virtual MFA device. The resource ARN in this statement allows the user to create an MFA device with any name, but the other statements in the policy only allow the user to attach the device to the currently signed-in user. + The `AllowManageOwnUserMFA` statement allows the user to view or manage their own virtual, U2F, or hardware MFA device. The resource ARN in this statement allows access to only the user's own IAM user. Users can't view or manage the MFA device for other users. + The `DenyAllExceptListedIfNoMFA` statement denies access to every action in all AWS services, except a few listed actions, but ***only if*** the user is not signed in with MFA. The statement uses a combination of `"Deny"` and `"NotAction"` to explicitly deny access to every action that is not listed. The items listed are not denied or allowed by this statement. However, the actions are allowed by other statements in the policy. For more information about the logic for this statement, see [NotAction with Deny](reference_policies_elements_notaction.md). If the user is signed in with MFA, then the `Condition` test fails and this statement does not deny any actions. In this case, other policies or statements for the user determine the user's permissions. This statement ensures that when the user is not signed in with MFA, they can perform only the listed actions. In addition, they can perform the listed actions only if another statement or policy allows access to those actions. The `...IfExists` version of the `Bool` operator ensures that if the `aws:MultiFactorAuthPresent` key is missing, the condition returns true. This means that a user accessing an API operation with long-term credentials, such as an access key, is denied access to the non-IAM API operations. This policy does not allow users to view the **Users** page in the IAM console or use that page to access their own user information. To allow this, add the `iam:ListUsers` action to the `AllowViewAccountInfo` statement and the `DenyAllExceptListedIfNoMFA` statement. **Warning** Do not add permission to delete an MFA device without MFA authentication. Users with this policy might attempt to assign themselves a virtual MFA device and receive an error that they are not authorized to perform `iam:DeleteVirtualMFADevice`. If this happens, **do not** add that permission to the `DenyAllExceptListedIfNoMFA` statement. Users that are not authenticated using MFA should never be allowed to delete their MFA device. Users might see this error if they previously began assigning a virtual MFA device to their user and cancelled the process. To resolve this issue, you or another administrator must delete the user's existing virtual MFA device using the AWS CLI or AWS API. For more information, see [I am not authorized to perform: iam:DeleteVirtualMFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowViewAccountInfo", "Effect": "Allow", "Action": "iam:ListVirtualMFADevices", "Resource": "*" }, { "Sid": "AllowManageOwnVirtualMFADevice", "Effect": "Allow", "Action": [ "iam:CreateVirtualMFADevice" ], "Resource": "arn:aws:iam::*:mfa/*" }, { "Sid": "AllowManageOwnUserMFA", "Effect": "Allow", "Action": [ "iam:DeactivateMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:GetMFADevice", "iam:ListMFADevices", "iam:ResyncMFADevice" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "DenyAllExceptListedIfNoMFA", "Effect": "Deny", "NotAction": [ "iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice", "sts:GetSessionToken" ], "Resource": "*", "Condition": { "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"} } } ] } ``` ------ # AWS: Allows IAM users to change their own console password on the Security credentials page AWS: Self-manage console password (Security credentials) This example shows how you might create an identity-based policy that allows IAM users to change their own AWS Management Console password on the **Security credentials** page. This AWS Management Console page displays account and user information, but the user can only access their own password. To allow users to manage all of their own credentials with MFA, see [AWS: Allows MFA-authenticated IAM users to manage their own credentials on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage.md). To allow users to manage their own credentials without using MFA, see [AWS: Allows IAM users to manage their own credentials on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage-no-mfa.md). To learn how users can access the **Security credentials** page, see [How IAM users change their own password (console)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console). **What does this policy do? ** + The `ViewAccountPasswordRequirements` statement allows the user to view the account password requirements while changing their own IAM user password. + The `ChangeOwnPassword` statement allows the user to change their own password. This statement also includes the `GetUser` action, which is required to view most of the information on the **My security credentials** page. This policy does not allow users to view the **Users** page in the IAM console or use that page to access their own user information. To allow this, add the `iam:ListUsers` action to the `ViewAccountPasswordRequirements` statement. It also does not allow users to change their password on their own user page. To allow this, add the `iam:GetLoginProfile` and `iam:UpdateLoginProfile` actions to the `ChangeOwnPasswords` statement. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ViewAccountPasswordRequirements", "Effect": "Allow", "Action": "iam:GetAccountPasswordPolicy", "Resource": "*" }, { "Sid": "ChangeOwnPassword", "Effect": "Allow", "Action": [ "iam:GetUser", "iam:ChangePassword" ], "Resource": "arn:aws:iam::*:user/${aws:username}" } ] } ``` ------ # AWS: Allows IAM users to manage their own password, access keys, and SSH public keys on the Security credentials page AWS: Self-manage password, access keys, & SSH public keys (My security credentials) This example shows how you might create an identity-based policy that allows IAM users to manage their own password, access keys, and X.509 certificates on the **Security credentials** page. This AWS Management Console page displays account information such as the account ID and canonical user ID. Users can also view and edit their own passwords, access keys, MFA devices, X.509 certificates, SSH keys, and Git credentials. This example policy includes the permissions that are required to view and edit only their password, access keys, and X.509 certificate. To allow users to manage all of their own credentials with MFA, see [AWS: Allows MFA-authenticated IAM users to manage their own credentials on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage.md). To allow users to manage their own credentials without using MFA, see [AWS: Allows IAM users to manage their own credentials on the Security credentials page](reference_policies_examples_aws_my-sec-creds-self-manage-no-mfa.md). To learn how users can access the **Security credentials** page, see [How IAM users change their own password (console)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console). **What does this policy do? ** + The `AllowViewAccountInfo` statement allows the user to view account-level information. These permissions must be in their own statement because they do not support or do not need to specify a resource ARN. Instead the permissions specify `"Resource" : "*"`. This statement includes the following actions that allow the user to view specific information: + `GetAccountPasswordPolicy` – View the account password requirements while changing their own IAM user password. + `GetAccountSummary` – View the account ID and the account [canonical user ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId). + The `AllowManageOwnPasswords` statement allows the user to change their own password. This statement also includes the `GetUser` action, which is required to view most of the information on the **My security credentials** page. + The `AllowManageOwnAccessKeys` statement allows the user to create, update, and delete their own access keys. The user can also retrieve information about when the specified access key was last used. + The `AllowManageOwnSSHPublicKeys` statement allows the user to upload, update, and delete their own SSH public keys for CodeCommit. This policy does not allow users to view or manage their own MFA devices. They also cannot view the **Users** page in the IAM console or use that page to access their own user information. To allow this, add the `iam:ListUsers` action to the `AllowViewAccountInfo` statement. It also does not allow users to change their password on their own user page. To allow this, add the `iam:GetLoginProfile` and `iam:UpdateLoginProfile` actions to the `AllowManageOwnPasswords` statement. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowViewAccountInfo", "Effect": "Allow", "Action": [ "iam:GetAccountPasswordPolicy", "iam:GetAccountSummary" ], "Resource": "*" }, { "Sid": "AllowManageOwnPasswords", "Effect": "Allow", "Action": [ "iam:ChangePassword", "iam:GetUser" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnAccessKeys", "Effect": "Allow", "Action": [ "iam:CreateAccessKey", "iam:DeleteAccessKey", "iam:ListAccessKeys", "iam:UpdateAccessKey", "iam:GetAccessKeyLastUsed" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowManageOwnSSHPublicKeys", "Effect": "Allow", "Action": [ "iam:DeleteSSHPublicKey", "iam:GetSSHPublicKey", "iam:ListSSHPublicKeys", "iam:UpdateSSHPublicKey", "iam:UploadSSHPublicKey" ], "Resource": "arn:aws:iam::*:user/${aws:username}" } ] } ``` ------ # AWS: Denies access to AWS based on the requested Region AWS: Deny access based on requested Region This example shows how you might create an identity-based policy that denies access to any actions outside the Regions specified using the [`aws:RequestedRegion` condition key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requestedregion), except for actions in the services specified using `NotAction`. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). This policy uses the `NotAction` element with the `Deny` effect, which explicitly denies access to all of the actions *not* listed in the statement. Actions in the CloudFront, IAM, Route 53, and Support services should not be denied because these are popular AWS global services with a single endpoint that is physically located in the `us-east-1` Region. Because all requests to these services are made to the `us-east-1` Region, the requests would be denied without the `NotAction` element. Edit this element to include actions for other AWS global services that you use, such as `budgets`, `globalaccelerator`, `importexport`, `organizations`, or `waf`. Some other global services, such as Amazon Q Developer in chat applications and AWS Device Farm, are global services with endpoints that are physically located in the `us-west-2` region. To learn about all of the services that have a single global endpoint, see [AWS Regions and Endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html) in the *AWS General Reference*. For more information about using the `NotAction` element with the `Deny` effect, see [IAM JSON policy elements: NotAction](reference_policies_elements_notaction.md). **Important** This policy does not allow any actions. Use this policy in combination with other policies that allow specific actions. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAllOutsideRequestedRegions", "Effect": "Deny", "NotAction": [ "cloudfront:*", "iam:*", "organizations:*", "route53:*", "support:*" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "eu-central-1", "eu-west-1", "eu-west-2", "eu-west-3" ] } } } ] } ``` ------ # AWS: Denies access to AWS based on the source IP AWS: Deny access based on source IP This example shows how you might create an identity-based policy that denies access to all AWS actions in the account when the request comes from *principals* outside the specified IP range. The policy is useful when the IP addresses for your company are within the specified ranges. In this example, the request will be denied unless it originates from the CIDR range 192.0.2.0/24 or 203.0.113.0/24. The policy does not deny requests made by AWS services using [Forward access sessions](access_forward_access_sessions.md) as the original requester’s IP address is preserved. Be careful using negative conditions in the same policy statement as `"Effect": "Deny"`. When you do, the actions specified in the policy statement are explicitly denied in all conditions *except* for the ones specified. **Important** This policy does not allow any actions. Use this policy in combination with other policies that allow specific actions. When other policies allow actions, principals can make requests from within the IP address range. An AWS service can also make requests using the principal's credentials. When a principal makes a request from outside the IP range, the request is denied. For more information about using the `aws:SourceIp` condition key, including information about when `aws:SourceIp` may not work in your policy, see [AWS global condition context keys](reference_policies_condition-keys.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "203.0.113.0/24" ] } } } } ``` ------ # AWS: Deny access to Amazon S3 resources outside your account except AWS Data Exchange This example shows how you might create an identity-based policy that denies access to all resources in AWS that don't belong to your account, except for the resources that AWS Data Exchange requires for normal operation. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). You can create a similar policy to restrict access to resources within an organization or an organizational unit, while accounting for AWS Data Exchange owned resources by using the condition keys `aws:ResourceOrgPaths` and `aws:ResourceOrgID`. If you use AWS Data Exchange in your environment, the service creates and interacts with resources such as Amazon S3 buckets owned by the service account. For example, AWS Data Exchange sends requests to Amazon S3 buckets owned by the AWS Data Exchange service on behalf of the IAM principal (user or role) invoking the AWS Data Exchange APIs. In that case, using `aws:ResourceAccount`, `aws:ResourceOrgPaths`, or `aws:ResourceOrgID` in a policy, without accounting for AWS Data Exchange owned resources, denies access to the buckets owned by the service account. + The statement, `DenyAllAwsResourcesOutsideAccountExceptS3`, uses the `NotAction` element with the [Deny](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_effect.html) effect which explicitly denies access to every action not listed in the statement that also do not belong to the listed account. The `NotAction` element indicates the exceptions to this statement. These actions are the exception to this statement because if the actions are performed on resources created by AWS Data Exchange, the policy denies them. + The statement, `DenyAllS3ResoucesOutsideAccountExceptDataExchange`, uses a combination of the `ResourceAccount` and `CalledVia` conditions to deny access to the three Amazon S3 actions excluded in the previous statement. The statement denies the actions if resources do not belong in the listed account and if the calling service is not AWS Data Exchange. The statement does not deny the actions if either the resource belongs to the listed account or the listed service principal, `dataexchange.amazonaws.com`, performs the operations. **Important** This policy does not allow any actions. It uses the `Deny` effect which explicitly denies access to all of the resources listed in the statement that do not belong to the listed account. Use this policy in combination with other policies that allow access to specific resources. The following example shows how you can configure the policy to allow access to the required Amazon S3 buckets. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAllAwsReourcesOutsideAccountExceptAmazonS3", "Effect": "Deny", "NotAction": [ "s3:GetObject", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:ResourceAccount": [ "111122223333" ] } } }, { "Sid": "DenyAllS3ResourcesOutsideAccountExceptDataExchange", "Effect": "Deny", "Action": [ "s3:GetObject", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:ResourceAccount": [ "111122223333" ] }, "ForAllValues:StringNotEquals": { "aws:CalledVia": [ "dataexchange.amazonaws.com" ] } } } ] } ``` ------ # AWS Data Pipeline: Denies access to DataPipeline pipelines that a user did not create Data Pipeline: Deny access to pipelines not created by user This example shows how you might create an identity-based policy that denies access to pipelines that a user did not create. If the value of the `PipelineCreator` field matches the IAM user name, then the specified actions are not denied. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. **Important** This policy does not allow any actions. Use this policy in combination with other policies that allow specific actions. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ExplicitDenyIfNotTheOwner", "Effect": "Deny", "Action": [ "datapipeline:ActivatePipeline", "datapipeline:AddTags", "datapipeline:DeactivatePipeline", "datapipeline:DeletePipeline", "datapipeline:DescribeObjects", "datapipeline:EvaluateExpression", "datapipeline:GetPipelineDefinition", "datapipeline:PollForTask", "datapipeline:PutPipelineDefinition", "datapipeline:QueryObjects", "datapipeline:RemoveTags", "datapipeline:ReportTaskProgress", "datapipeline:ReportTaskRunnerHeartbeat", "datapipeline:SetStatus", "datapipeline:SetTaskStatus", "datapipeline:ValidatePipelineDefinition" ], "Resource": ["*"], "Condition": { "StringNotEquals": {"datapipeline:PipelineCreator": "${aws:userid}"} } } ] } ``` ------ # Amazon DynamoDB: Allows access to a specific table DynamoDB: Access specific table This example shows how you might create an identity-based policy that allows full access to the `MyTable` DynamoDB table. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). **Important** This policy allows all actions that can be performed on a DynamoDB table. To review these actions, see [DynamoDB API Permissions: Actions, Resources, and Conditions Reference](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/api-permissions-reference.html) in the* Amazon DynamoDB Developer Guide*. You could provide the same permissions by listing each individual action. However, if you use the wildcard (`*`) in the `Action` element, such as `"dynamodb:List*"`, then you don't have to update your policy if DynamoDB adds a new List action. This policy allows actions only on DynamoDB tables that exist with the specified name. To allow your users `Read` access to everything in DynamoDB, you can also attach the [AmazonDynamoDBReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess) AWS managed policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ListAndDescribe", "Effect": "Allow", "Action": [ "dynamodb:List*", "dynamodb:DescribeReservedCapacity*", "dynamodb:DescribeLimits", "dynamodb:DescribeTimeToLive" ], "Resource": "*" }, { "Sid": "SpecificTable", "Effect": "Allow", "Action": [ "dynamodb:BatchGet*", "dynamodb:DescribeStream", "dynamodb:DescribeTable", "dynamodb:Get*", "dynamodb:Query", "dynamodb:Scan", "dynamodb:BatchWrite*", "dynamodb:CreateTable", "dynamodb:Delete*", "dynamodb:Update*", "dynamodb:PutItem" ], "Resource": "arn:aws:dynamodb:*:*:table/MyTable" } ] } ``` ------ # Amazon DynamoDB: Allows access to specific attributes DynamoDB: Allow access to specific attributes This example shows how you might create an identity-based policy that allows access to the specific DynamoDB attributes. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). The `dynamodb:Select` requirement prevents the API action from returning any attributes that aren't allowed, such as from an index projection. To learn more about DynamoDB condition keys, see [Specifying Conditions: Using Condition Keys](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/specifying-conditions.html#FGAC_DDB.ConditionKeys) in the* Amazon DynamoDB Developer Guide*. To learn about using multiple conditions or multiple condition keys within the `Condition` block of an IAM policy, see [Multiple values in a condition](reference_policies_elements_condition.md#Condition-multiple-conditions). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource": ["arn:aws:dynamodb:*:*:table/table-name"], "Condition": { "ForAllValues:StringEquals": { "dynamodb:Attributes": [ "column-name-1", "column-name-2", "column-name-3" ] }, "StringEqualsIfExists": {"dynamodb:Select": "SPECIFIC_ATTRIBUTES"} } } ] } ``` ------ # Amazon DynamoDB: Allows item-level access to DynamoDB based on an Amazon Cognito ID DynamoDB: Allow item access based on a Amazon Cognito ID This example shows how you might create an identity-based policy that allows item-level access to the `MyTable` DynamoDB table based on an Amazon Cognito identity pool user ID. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). To use this policy, you must structure your DynamoDB table so the Amazon Cognito identity pool user ID is the partition key. For more information, see [Creating a Table](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.Basics.html#WorkingWithTables.Basics.CreateTable) in the *Amazon DynamoDB Developer Guide*. To learn more about DynamoDB condition keys, see [Specifying Conditions: Using Condition Keys](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/specifying-conditions.html#FGAC_DDB.ConditionKeys) in the* Amazon DynamoDB Developer Guide*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query", "dynamodb:UpdateItem" ], "Resource": ["arn:aws:dynamodb:*:*:table/MyTable"], "Condition": { "ForAllValues:StringEquals": { "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"] } } } ] } ``` ------ # Amazon EC2: Attach or detach Amazon EBS volumes to EC2 instances based on tags EC2: Attach or detach tagged EBS volumes This example shows how you might create an identity-based policy that allows EBS volume owners to attach or detach their EBS volumes defined using the tag `VolumeUser` to EC2 instances that are tagged as development instances (`Department=Development`). This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). For more information about creating IAM policies to control access to Amazon EC2 resources, see [Controlling Access to Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html) in the *Amazon EC2 User Guide*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AttachVolume", "ec2:DetachVolume" ], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringEquals": {"aws:ResourceTag/Department": "Development"} } }, { "Effect": "Allow", "Action": [ "ec2:AttachVolume", "ec2:DetachVolume" ], "Resource": "arn:aws:ec2:*:*:volume/*", "Condition": { "StringEquals": {"aws:ResourceTag/VolumeUser": "${aws:username}"} } } ] } ``` ------ # Amazon EC2: Allows launching EC2 instances in a specific subnet, programmatically and in the console EC2: Launch instances in a subnet (includes console) This example shows how you might create an identity-based policy that allows listing information for all EC2 objects and launching EC2 instances in a specific subnet. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:Describe*", "ec2:GetConsole*" ], "Resource": "*" }, { "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:subnet/subnet-subnet-id", "arn:aws:ec2:*:*:network-interface/*", "arn:aws:ec2:*:*:instance/*", "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*::image/ami-*", "arn:aws:ec2:*:*:key-pair/*", "arn:aws:ec2:*:*:security-group/*" ] } ] } ``` ------ # Amazon EC2: Allows managing EC2 security groups with a specific tag key-value pair programmatically and in the console EC2: Manage security groups with the same tags (includes console) This example shows how you might create an identity-based policy that grants users permission to take certain actions for security groups that have the same tag. This policy grants permissions to view security groups in the Amazon EC2 console, add and remove inbound and outbound rules, and list and modify rule descriptions for existing security groups with the tag `Department=Test`. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "ec2:DescribeSecurityGroups", "ec2:DescribeSecurityGroupRules", "ec2:DescribeTags" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:AuthorizeSecurityGroupIngress", "ec2:RevokeSecurityGroupIngress", "ec2:AuthorizeSecurityGroupEgress", "ec2:RevokeSecurityGroupEgress", "ec2:ModifySecurityGroupRules", "ec2:UpdateSecurityGroupRuleDescriptionsIngress", "ec2:UpdateSecurityGroupRuleDescriptionsEgress" ], "Resource": [ "arn:aws:ec2:us-east-1:111122223333:security-group/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/Department": "Test" } } }, { "Effect": "Allow", "Action": [ "ec2:ModifySecurityGroupRules" ], "Resource": [ "arn:aws:ec2:us-east-1:111122223333:security-group-rule/*" ] } ] } ``` ------ # Amazon EC2: Allows starting or stopping EC2 instances a user has tagged, programmatically and in the console EC2: Start or stop instances a user has tagged (includes console) This example shows how you might create an identity-based policy that allows an IAM user to start or stop EC2 instances, but only if the instance tag `Owner` has the value of that user's user name. This policy defines permissions for programmatic and console access. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringEquals": { "aws:ResourceTag/Owner": "${aws:username}" } } }, { "Effect": "Allow", "Action": "ec2:DescribeInstances", "Resource": "*" } ] } ``` ------ # EC2: Start or stop instances based on tags EC2: Start or stop instances based on tags This example shows how you might create an identity-based policy that allows starting or stopping instances with the tag key–value pair `Project = DataAnalytics`, but only by principals with the tag key–value pair `Department = Data`. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). The condition in the policy returns true if both parts of the condition are true. The instance must have the `Project=DataAnalytics` tag. In addition, the IAM principal (user or role) making the request must have the `Department=Data` tag. **Note** As a best practice, attach policies with the `aws:PrincipalTag` condition key to IAM groups, for the case where some users might have the specified tag and some might not. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "StartStopIfTags", "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*", "Condition": { "StringEquals": { "aws:ResourceTag/Project": "DataAnalytics", "aws:PrincipalTag/Department": "Data" } } } ] } ``` ------ # EC2: Start or stop instances based on matching principal and resource tags EC2: Start or stop for matching tags This example shows how you might create an identity-based policy that allows a principal to start or stop an Amazon EC2 instance when the instance's resource tag and the principal's tag have the same value for the tag key `CostCenter`. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). **Note** As a best practice, attach policies with the `aws:PrincipalTag` condition key to IAM groups, for the case where some users might have the specified tag and some might not. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "ec2:startInstances", "ec2:stopInstances" ], "Resource": "*", "Condition": {"StringEquals": {"aws:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"}} } } ``` ------ # Amazon EC2: Allows full EC2 access within a specific Region, programmatically and in the console EC2: Full access within a Region (includes console) This example shows how you might create an identity-based policy that allows full EC2 access within a specific Region. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). For a list of Region codes, see [Available Regions](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions) in the *Amazon EC2 User Guide*. Alternatively, you can use the global condition key [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requestedregion](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requestedregion), which is supported by all Amazon EC2 API actions. For more information, see [Example: Restricting access to a specific Region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region) in the *Amazon EC2 User Guide*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ec2:*", "Resource": "*", "Effect": "Allow", "Condition": { "StringEquals": { "ec2:Region": "us-east-2" } } } ] } ``` ------ # Amazon EC2: Allows starting or stopping an EC2 instance and modifying a security group, programmatically and in the console EC2: Start or stop an instance, modify security group (includes console) This example shows how you might create an identity-based policy that allows starting or stopping a specific EC2 instance and modifying a specific security group. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeInstances", "ec2:DescribeSecurityGroups", "ec2:DescribeSecurityGroupReferences", "ec2:DescribeStaleSecurityGroups" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "ec2:AuthorizeSecurityGroupEgress", "ec2:AuthorizeSecurityGroupIngress", "ec2:RevokeSecurityGroupEgress", "ec2:RevokeSecurityGroupIngress", "ec2:StartInstances", "ec2:StopInstances" ], "Resource": [ "arn:aws:ec2:*:*:instance/i-instance-id", "arn:aws:ec2:*:*:security-group/sg-security-group-id" ], "Effect": "Allow" } ] } ``` ------ # Amazon EC2: Requires MFA (GetSessionToken) for specific EC2 operations EC2: Requires MFA (GetSessionToken) for operations This example shows how you might create an identity-based policy that allows full access to all AWS API operations in Amazon EC2. However, it explicitly denies access to `StopInstances` and `TerminateInstances` API operations if the user is not authenticated using [multi-factor authentication (MFA)](id_credentials_mfa.md). To do this programmatically, the user must include optional `SerialNumber` and `TokenCode` values while calling the `GetSessionToken` operation. This operation returns temporary credentials that were authenticated using MFA. To learn more about GetSessionToken, see [Requesting credentials for users in untrusted environments](id_credentials_temp_request.md#api_getsessiontoken). What does this policy do? + The `AllowAllActionsForEC2` statement allows all Amazon EC2 actions. + The `DenyStopAndTerminateWhenMFAIsNotPresent` statement denies the `StopInstances` and `TerminateInstances` actions when the MFA context is missing. This means that the actions are denied when the multi-factor authentication context is missing (meaning MFA was not used). A deny overrides the allow. **Note** The condition check for `MultiFactorAuthPresent` in the `Deny` statement should not be a `{"Bool":{"aws:MultiFactorAuthPresent":false}}` because that key is not present and cannot be evaluated when MFA is not used. So instead, use the `BoolIfExists` check to see whether the key is present before checking the value. For more information, see [...IfExists condition operators](reference_policies_elements_condition_operators.md#Conditions_IfExists). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAllActionsForEC2", "Effect": "Allow", "Action": "ec2:*", "Resource": "*" }, { "Sid": "DenyStopAndTerminateWhenMFAIsNotPresent", "Effect": "Deny", "Action": [ "ec2:StopInstances", "ec2:TerminateInstances" ], "Resource": "*", "Condition": { "BoolIfExists": {"aws:MultiFactorAuthPresent": false} } } ] } ``` ------ # Amazon EC2: Limits terminating EC2 instances to an IP address range EC2: Limit terminating instances to IP range This example shows how you might create an identity-based policy that limits EC2 instances by allowing the action, but explicitly denying access when the request comes from outside the specified IP range. The policy is useful when the IP addresses for your company are within the specified ranges. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). If this policy is used in combination with other policies that allow the `ec2:TerminateInstances` action (such as the [AmazonEC2FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2FullAccess) AWS managed policy), then access is denied. This is because an explicit deny statement takes precedence over allow statements. For more information, see [How AWS enforcement code logic evaluates requests to allow or deny access](reference_policies_evaluation-logic_policy-eval-denyallow.md). **Important** The `aws:SourceIp` condition key denies access to an AWS service, such as AWS CloudFormation, that makes calls on your behalf. For more information about using the `aws:SourceIp` condition key, see [AWS global condition context keys](reference_policies_condition-keys.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["ec2:TerminateInstances"], "Resource": ["*"] }, { "Effect": "Deny", "Action": ["ec2:TerminateInstances"], "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "203.0.113.0/24" ] } }, "Resource": ["*"] } ] } ``` ------ # IAM: Access the policy simulator API IAM: Access the policy simulator API This example shows how you might create an identity-based policy that allows using the policy simulator API for policies attached to a user, group, or role in the current AWS account. This policy also allows access to simulate less sensitive policies passed to the API as strings. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "iam:GetContextKeysForCustomPolicy", "iam:GetContextKeysForPrincipalPolicy", "iam:SimulateCustomPolicy", "iam:SimulatePrincipalPolicy" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ **Note** To allow a user to access the policy simulator console to simulate policies attached to a user, group, or role in the current AWS account, see [IAM: Access the policy simulator console](reference_policies_examples_iam_policy-sim-console.md). # IAM: Access the policy simulator console IAM: Access the policy simulator console This example shows how you might create an identity-based policy that allows using the policy simulator console for policies attached to a user, group, or role in the current AWS account. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. You can access the IAM Policy Simulator console at: [https://policysim.aws.amazon.com/](https://policysim.aws.amazon.com/) ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "iam:GetGroup", "iam:GetGroupPolicy", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:GetRole", "iam:GetRolePolicy", "iam:GetUser", "iam:GetUserPolicy", "iam:ListAttachedGroupPolicies", "iam:ListAttachedRolePolicies", "iam:ListAttachedUserPolicies", "iam:ListGroups", "iam:ListGroupPolicies", "iam:ListGroupsForUser", "iam:ListRolePolicies", "iam:ListRoles", "iam:ListUserPolicies", "iam:ListUsers" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ # IAM: Assume roles that have a specific tag IAM: Assume tagged roles This example shows how you might create an identity-based policy that allows an IAM user to assume roles with the tag key-value pair `Project = ExampleCorpABC`. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). If a role with this tag exists in the same account as the user, then the user can assume that role. If a role with this tag exists in an account other than the user's, it requires additional permissions. The cross-account role's trust policy must also allow the user or all members of the user's account to assume the role. For information about using roles for cross-account access, see [Access for an IAM user in another AWS account that you own](id_roles_common-scenarios_aws-accounts.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeTaggedRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "*", "Condition": { "StringEquals": {"iam:ResourceTag/Project": "ExampleCorpABC"} } } ] } ``` ------ # IAM: Allows and denies access to multiple services programmatically and in the console IAM: Allows and denies multiple services (includes console) This example shows how you might create an identity-based policy that allows full access to several services and limited self-managing access in IAM. It also denies access to the Amazon S3 `logs` bucket or the Amazon EC2 `i-1234567890abcdef0` instance. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). **Warning** This policy allows full access to every action and resource in multiple services. This policy should be applied only to trusted administrators. You can use this policy as a permissions boundary to define the maximum permissions that an identity-based policy can grant to an IAM user. For more information, see [Delegating responsibility to others using permissions boundaries](access_policies_boundaries.md#access_policies_boundaries-delegate). When the policy is used as a permissions boundary for a user, the statements define the following boundaries: + The `AllowServices` statement allows full access to the specified AWS services. This means that the user's actions in these services are limited only by the permissions policies that are attached to the user. + The `AllowIAMConsoleForCredentials` statement allows access to list all IAM users. This access is necessary to navigate the **Users** page in the AWS Management Console. It also allows viewing the password requirements for the account, which is necessary for the user to change their own password. + The `AllowManageOwnPasswordAndAccessKeys` statement allows the users manage only their own console password and programmatic access keys. This is important because if another policy gives a user full IAM access, that user could then change their own or other users' permissions. This statement prevents that from happening. + The `DenyS3Logs` statement explicitly denies access to the `logs` bucket. This policy enforces company restrictions on the user. + The `DenyEC2Production` statement explicitly denies access to the `i-1234567890abcdef0` instance. This policy does not allow access to other services or actions. When the policy is used as a permissions boundary on a user, even if other policies attached to the user allow those actions, AWS denies the request. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowServices", "Effect": "Allow", "Action": [ "s3:*", "cloudwatch:*", "ec2:*" ], "Resource": "*" }, { "Sid": "AllowIAMConsoleForCredentials", "Effect": "Allow", "Action": [ "iam:ListUsers", "iam:GetAccountPasswordPolicy" ], "Resource": "*" }, { "Sid": "AllowManageOwnPasswordAndAccessKeys", "Effect": "Allow", "Action": [ "iam:*AccessKey*", "iam:ChangePassword", "iam:GetUser", "iam:*LoginProfile*" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::logs", "arn:aws:s3:::logs/*" ] }, { "Sid": "DenyEC2Production", "Effect": "Deny", "Action": "ec2:*", "Resource": "arn:aws:ec2:*:*:instance/i-1234567890abcdef0" } ] } ``` ------ # IAM: Add a specific tag to a user with a specific tag IAM: Add specific tag to tagged user This example shows how you might create an identity-based policy that allows adding the tag key `Department` with the tag values `Marketing`, `Development`, or `QualityAssurance` to an IAM user. That user must already include the tag key–value pair `JobFunction = manager`. You can use this policy to require that a manager belong to only one of three departments. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). The `ListTagsForAllUsers` statement allows the viewing of tags for all users in your account. The first condition in the `TagManagerWithSpecificDepartment` statement uses the `StringEquals` condition operator. The condition returns true if both parts of the condition are true. The user to be tagged must already have the `JobFunction=Manager` tag. The request must include the `Department` tag key with one of the listed tag values. The second condition uses the `ForAllValues:StringEquals` condition operator. The condition returns true if all of the tag keys in the request match the key in the policy. This means that the only tag key in the request must be `Department`. For more information about using `ForAllValues`, see [Set operators for multivalued context keys](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ListTagsForAllUsers", "Effect": "Allow", "Action": [ "iam:ListUserTags", "iam:ListUsers" ], "Resource": "*" }, { "Sid": "TagManagerWithSpecificDepartment", "Effect": "Allow", "Action": "iam:TagUser", "Resource": "*", "Condition": {"StringEquals": { "iam:ResourceTag/JobFunction": "Manager", "aws:RequestTag/Department": [ "Marketing", "Development", "QualityAssurance" ] }, "ForAllValues:StringEquals": {"aws:TagKeys": "Department"} } } ] } ``` ------ # IAM: Add a specific tag with specific values IAM: Add a specific tag This example shows how you might create an identity-based policy that allows adding only the tag key `CostCenter` and either the tag value `A-123` or the tag value `B-456` to any IAM user or role. You can use this policy to limit tagging to a specific tag key and set of tag values. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). The `ConsoleDisplay` statement allows the viewing of tags for all users and roles in your account. The first condition in the `AddTag` statement uses the `StringEquals` condition operator. The condition returns true if the request includes the `CostCenter` tag key with one of the listed tag values. The second condition uses the `ForAllValues:StringEquals` condition operator. The condition returns true if all of the tag keys in the request match the key in the policy. This means that the only tag key in the request must be `CostCenter`. For more information about using `ForAllValues`, see [Set operators for multivalued context keys](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ConsoleDisplay", "Effect": "Allow", "Action": [ "iam:GetRole", "iam:GetUser", "iam:ListRoles", "iam:ListRoleTags", "iam:ListUsers", "iam:ListUserTags" ], "Resource": "*" }, { "Sid": "AddTag", "Effect": "Allow", "Action": [ "iam:TagUser", "iam:TagRole" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/CostCenter": [ "A-123", "B-456" ] }, "ForAllValues:StringEquals": {"aws:TagKeys": "CostCenter"} } } ] } ``` ------ # IAM: Create new users only with specific tags IAM: Create only tagged users This example shows how you might create an identity-based policy that allows the creation of IAM users but only with one or both of the `Department` and `JobFunction` tag keys. The `Department` tag key must have either the `Development` or `QualityAssurance` tag value. The `JobFunction` tag key must have the `Employee` tag value. You can use this policy to require that new users have a specific job function and department. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). The first condition in the statement uses the `StringEqualsIfExists` condition operator. If a tag with the `Department` or `JobFunction` key is present in the request, then the tag must have the specified value. If neither key is present, then this condition is evaluated as true. The only way that the condition evaluates as false is if one of the specified condition keys is present in the request, but has a different value than those allowed. For more information about using `IfExists`, see [...IfExists condition operators](reference_policies_elements_condition_operators.md#Conditions_IfExists). The second condition uses the `ForAllValues:StringEquals` condition operator. The condition returns true if there's a match between every one of the specified tag keys specified in the request, and at least one value in the policy. This means that all of the tags in the request must be in this list. However, the request can include only one of the tags in the list. For example, you can create an IAM user with only the `Department=QualityAssurance` tag. However, you cannot create an IAM user with the `JobFunction=employee` tag and the `Project=core` tag. For more information about using `ForAllValues`, see [Set operators for multivalued context keys](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TagUsersWithOnlyTheseTags", "Effect": "Allow", "Action": [ "iam:CreateUser", "iam:TagUser" ], "Resource": "*", "Condition": { "StringEqualsIfExists": { "aws:RequestTag/Department": [ "Development", "QualityAssurance" ], "aws:RequestTag/JobFunction": "Employee" }, "ForAllValues:StringEquals": { "aws:TagKeys": [ "Department", "JobFunction" ] } } } ] } ``` ------ # IAM: Generate and retrieve IAM credential reports IAM: Generate credential reports This example shows how you might create an identity-based policy that allows users to generate and download a report that lists all IAM users in their AWS account. The report includes the status of the users' credentials, including passwords, access keys, MFA devices, and signing certificates. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. For more information about credential reports, see [Generate credential reports for your AWS account](id_credentials_getting-report.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:GenerateCredentialReport", "iam:GetCredentialReport" ], "Resource": "*" } } ``` ------ # IAM: Allows managing a group's membership programmatically and in the console IAM: Manage group membership (includes console) This example shows how you might create an identity-based policy that allows updating the membership of the group called `MarketingTeam`. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). What does this policy do? + The `ViewGroups` statement allows the user to list all the users and groups in the AWS Management Console. It also allows the user to view basic information about the users in the account. These permissions must be in their own statement because they do not support or do not need to specify a resource ARN. Instead the permissions specify `"Resource" : "*"`. + The `ViewEditThisGroup` statement allows the user to view information about the `MarketingTeam` group, and to add and remove users from that group. This policy does not allow the user to view or edit the permissions of the users or the `MarketingTeam` group. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ViewGroups", "Effect": "Allow", "Action": [ "iam:ListGroups", "iam:ListUsers", "iam:GetUser", "iam:ListGroupsForUser" ], "Resource": "*" }, { "Sid": "ViewEditThisGroup", "Effect": "Allow", "Action": [ "iam:AddUserToGroup", "iam:RemoveUserFromGroup", "iam:GetGroup" ], "Resource": "arn:aws:iam::*:group/MarketingTeam" } ] } ``` ------ # IAM: Manage a specific tag IAM: Manage a tag This example shows how you might create an identity-based policy that allows adding and removing the IAM tag with the tag key `Department` from IAM entities (users and roles). This policy does not limit the value of the `Department` tag. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:TagUser", "iam:TagRole", "iam:UntagUser", "iam:UntagRole" ], "Resource": "*", "Condition": {"ForAllValues:StringEquals": {"aws:TagKeys": "Department"}} } } ``` ------ # IAM: Pass an IAM role to a specific AWS service IAM: Pass a role to a service This example shows how you might create an identity-based policy that allows passing any IAM service role to the Amazon CloudWatch service. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). A service role is an IAM role that specifies an AWS service as the principal that can assume the role. This allows the service to assume the role and access resources in other services on your behalf. To allow Amazon CloudWatch to assume the role that you pass, you must specify the `cloudwatch.amazonaws.com` service principal as the principal in the trust policy of your role. The service principal is defined by the service. To learn the service principal for a service, see the documentation for that service. For some services, see [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md) and look for the services that have **Yes **in the **Service-Linked Role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. Search for `amazonaws.com` to view the service principal. To learn more about passing a service role to a service, see [Grant a user permissions to pass a role to an AWS service](id_roles_use_passrole.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringEquals": {"iam:PassedToService": "cloudwatch.amazonaws.com"} } } ] } ``` ------ # IAM: Allows read-only access to the IAM console without reporting IAM: Read-only console access (no reporting) This example shows how you might create an identity-based policy that allows IAM users to perform any IAM action that begins with the string `Get` or `List`. As users work with the console, the console makes requests to IAM to list groups, users, roles, and policies, and to generate reports about those resources. The asterisk acts as a wildcard. When you use `iam:Get*` in a policy, the resulting permissions include all IAM actions that begin with `Get`, such as `GetUser` and `GetRole`. Wildcards are useful if new types of entities are added to IAM in the future. In that case, the permissions granted by the policy automatically allow the user to list and get the details about those new entities. This policy cannot be used to generate reports or service last accessed details. For a different policy that allows this, see [IAM: Allows read-only access to the IAM console](reference_policies_examples_iam_read-only-console.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*" ], "Resource": "*" } } ``` ------ # IAM: Allows read-only access to the IAM console IAM: Read-only console access This example shows how you might create an identity-based policy that allows IAM users to perform any IAM action that begins with the string `Get`, `List`, or `Generate`. As users work with the IAM console, the console makes requests to list groups, users, roles, and policies, and to generate reports about those resources. The asterisk acts as a wildcard. When you use `iam:Get*` in a policy, the resulting permissions include all IAM actions that begin with `Get`, such as `GetUser` and `GetRole`. Using a wildcard is beneficial, especially if new types of entities are added to IAM in the future. In that case, the permissions granted by the policy automatically allow the user to list and get the details about those new entities. Use this policy for console access that includes permissions to generate reports or service last accessed details. For a different policy that does not allow generating actions, see [IAM: Allows read-only access to the IAM console without reporting](reference_policies_examples_iam_read-only-console-no-reporting.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*", "iam:Generate*" ], "Resource": "*" } } ``` ------ # IAM: Allows specific IAM users to manage a group programmatically and in the console IAM: Specific users manage group (includes console) This example shows how you might create an identity-based policy that allows specific IAM users to manage the `AllUsers` group. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). What does this policy do? + The `AllowAllUsersToListAllGroups` statement allows listing all groups. This is necessary for console access. This permission must be in its own statement because it does not support a resource ARN. Instead the permissions specify `"Resource" : "*"`. + The `AllowAllUsersToViewAndManageThisGroup` statement allows all group actions that can be performed on the group resource type. It does not allow the `ListGroupsForUser` action, which can be performed on a user resource type and not a group resource type. For more information about the resource types that you can specify for an IAM action, see [Actions, Resources, and Condition Keys for AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_identityandaccessmanagement.html#identityandaccessmanagement-actions-as-permissions). + The `LimitGroupManagementAccessToSpecificUsers` statement denies users with the specified names access to write and permissions managment group actions. When a user specified in the policy attempts to make changes to the group, this statement does not deny the request. That request is allowed by the `AllowAllUsersToViewAndManageThisGroup` statement. If other users attempt to perform these operations, the request is denied. You can view the IAM actions that are defined with the **Write** or **Permissions management** access levels while creating this policy in the IAM console. To do this, switch from the **JSON** tab to the **Visual editor** tab. For more information about access levels. see [Actions, Resources, and Condition Keys for AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_identityandaccessmanagement.html#identityandaccessmanagement-actions-as-permissions). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAllUsersToListAllGroups", "Effect": "Allow", "Action": "iam:ListGroups", "Resource": "*" }, { "Sid": "AllowAllUsersToViewAndManageThisGroup", "Effect": "Allow", "Action": "iam:*Group*", "Resource": "arn:aws:iam::*:group/AllUsers" }, { "Sid": "LimitGroupManagementAccessToSpecificUsers", "Effect": "Deny", "Action": [ "iam:AddUserToGroup", "iam:CreateGroup", "iam:RemoveUserFromGroup", "iam:DeleteGroup", "iam:AttachGroupPolicy", "iam:UpdateGroup", "iam:DetachGroupPolicy", "iam:DeleteGroupPolicy", "iam:PutGroupPolicy" ], "Resource": "arn:aws:iam::*:group/AllUsers", "Condition": { "StringNotEquals": { "aws:username": [ "srodriguez", "mjackson", "adesai" ] } } } ] } ``` ------ # IAM: Allows setting the account password requirements programmatically and in the console IAM: Setting account password requirements (includes console) This example shows how you might create an identity-based policy that allows a user to view and update their account's password requirements. The password requirements specify the complexity requirements and mandatory rotation periods for the account members' passwords. This policy defines permissions for programmatic and console access. To learn how to set the account password requirements policy for your account, see [Set an account password policy for IAM users](id_credentials_passwords_account-policy.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:GetAccountPasswordPolicy", "iam:UpdateAccountPasswordPolicy" ], "Resource": "*" } } ``` ------ # IAM: Access the policy simulator API based on user path IAM: Access the policy simulator API based on user path This example shows how you might create an identity-based policy that allows using the policy simulator API only for those users that have the path `Department/Development`. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "iam:GetContextKeysForPrincipalPolicy", "iam:SimulatePrincipalPolicy" ], "Effect": "Allow", "Resource": "arn:aws:iam::*:user/Department/Development/*" } ] } ``` ------ **Note** To create a policy that allows using the policy simulator console for those users that have the path `Department/Development`, see [IAM: Access the policy simulator console based on user path](reference_policies_examples_iam_policy-sim-path-console.md). # IAM: Access the policy simulator console based on user path IAM: Access the policy simulator console based on user path (includes console) This example shows how you might create an identity-based policy that allows using the policy simulator console only for those users that have the path `Department/Development`. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). You can access the IAM Policy Simulator at: [https://policysim.aws.amazon.com/](https://policysim.aws.amazon.com/) ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "iam:GetPolicy", "iam:GetUserPolicy" ], "Effect": "Allow", "Resource": "*" }, { "Action": [ "iam:GetUser", "iam:ListAttachedUserPolicies", "iam:ListGroupsForUser", "iam:ListUserPolicies", "iam:ListUsers" ], "Effect": "Allow", "Resource": "arn:aws:iam::*:user/Department/Development/*" } ] } ``` ------ # IAM: Allows IAM users to self-manage an MFA device IAM: MFA self-management This example shows how you might create an identity-based policy that allows IAM users to self-manage their [multi-factor authentication (MFA)](id_credentials_mfa.md) device. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. **Note** If an IAM user with this policy is not MFA-authenticated, this policy denies access to all AWS actions except those necessary to authenticate using MFA. If you add these permissions for a user that is signed in to AWS, they might need to sign out and back in to see these changes. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowListActions", "Effect": "Allow", "Action": [ "iam:ListUsers", "iam:ListVirtualMFADevices" ], "Resource": "*" }, { "Sid": "AllowUserToCreateVirtualMFADevice", "Effect": "Allow", "Action": [ "iam:CreateVirtualMFADevice" ], "Resource": "arn:aws:iam::*:mfa/*" }, { "Sid": "AllowUserToManageTheirOwnMFA", "Effect": "Allow", "Action": [ "iam:EnableMFADevice", "iam:GetMFADevice", "iam:ListMFADevices", "iam:ResyncMFADevice" ], "Resource": "arn:aws:iam::*:user/${aws:username}" }, { "Sid": "AllowUserToDeactivateTheirOwnMFAOnlyWhenUsingMFA", "Effect": "Allow", "Action": [ "iam:DeactivateMFADevice" ], "Resource": [ "arn:aws:iam::*:user/${aws:username}" ], "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } } }, { "Sid": "BlockMostAccessUnlessSignedInWithMFA", "Effect": "Deny", "NotAction": [ "iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:ListMFADevices", "iam:ListUsers", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } } ] } ``` ------ # IAM: Allows IAM users to update their own credentials programmatically and in the console IAM: Update credentials (includes console) This example shows how you might create an identity-based policy that allows IAM users to update their own access keys, signing certificates, service specific credentials, and passwords. This policy defines permissions for programmatic and console access. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:ListUsers", "iam:GetAccountPasswordPolicy" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:*AccessKey*", "iam:ChangePassword", "iam:GetUser", "iam:*ServiceSpecificCredential*", "iam:*SigningCertificate*" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] } ] } ``` ------ To learn how a user can change their own password in the console, see [How an IAM user changes their own password](id_credentials_passwords_user-change-own.md). # IAM: View service last accessed information for an AWS Organizations policy IAM: View AWS Organizations service last accessed information for a policy This example shows how you might create an identity-based policy that allows viewing service last accessed information for a specific AWS Organizations policy. This policy allows retrieving data for the service control policy (SCP) with the `p-policy123` ID. The person who generates and views the report must be authenticated using AWS Organizations management account credentials. This policy allows the requester to retrieve the data for any AWS Organizations entity in their organization. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). For important information about last accessed information, including permissions required, troubleshooting, and supported Regions, see [Refine permissions in AWS using last accessed information](access_policies_last-accessed.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowOrgsReadOnlyAndIamGetReport", "Effect": "Allow", "Action": [ "iam:GetOrganizationsAccessReport", "organizations:Describe*", "organizations:List*" ], "Resource": "*" }, { "Sid": "AllowGenerateReportOnlyForThePolicy", "Effect": "Allow", "Action": "iam:GenerateOrganizationsAccessReport", "Resource": "*", "Condition": { "StringEquals": {"iam:OrganizationsPolicyId": "p-policy123"} } } ] } ``` ------ # IAM: Limits managed policies that can be applied to an IAM user, group, or role IAM: Apply limited managed policies This example shows how you might create an identity-based policy that limits customer managed and AWS managed policies that can be applied to an IAM user, group, or role. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachUserPolicy", "iam:DetachUserPolicy" ], "Resource": "*", "Condition": { "ArnEquals": { "iam:PolicyARN": [ "arn:aws:iam::*:policy/policy-name-1", "arn:aws:iam::*:policy/policy-name-2" ] } } } } ``` ------ # AWS: Deny access to resources outside your account except AWS managed IAM policies Using `aws:ResourceAccount` in your identity-based policies can impact the user or the role's ability to utilize some services that require interaction with resources in accounts owned by a service. You can create a policy with an exception to allow for AWS managed IAM policies. A service-managed account outside of your AWS Organizations owns Managed IAM Policies. There are four IAM actions that list and retrieve AWS-managed policies. Use these actions in the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notaction.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notaction.html) element of the statement. `AllowAccessToS3ResourcesInSpecificAccountsAndSpecificService1` in the policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAccessToResourcesInSpecificAccountsAndSpecificService1", "Effect": "Deny", "NotAction": [ "iam:GetPolicy", "iam:GetPolicyVersion", "iam:ListEntitiesForPolicy", "iam:ListPolicies" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:ResourceAccount": [ "111122223333" ] } } } ] } ``` ------ # AWS Lambda: Allows a Lambda function to access an Amazon DynamoDB table Lambda: Service access to DynamoDB This example shows how you might create an identity-based policy that allows read and write access to a specific Amazon DynamoDB table. The policy also allows writing log files to CloudWatch Logs. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). To use this policy, attach the policy to a Lambda [service role](id_roles_create_for-service.md). A service role is a role that you create in your account to allow a service to perform actions on your behalf. That service role must include AWS Lambda as the principal in the trust policy. For details about how to use this policy, see [How to Create an AWS IAM Policy to Grant AWS Lambda Access to an Amazon DynamoDB Table](https://aws.amazon.com/blogs/security/how-to-create-an-aws-iam-policy-to-grant-aws-lambda-access-to-an-amazon-dynamodb-table/) in the AWS Security Blog. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReadWriteTable", "Effect": "Allow", "Action": [ "dynamodb:BatchGetItem", "dynamodb:GetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:BatchWriteItem", "dynamodb:PutItem", "dynamodb:UpdateItem" ], "Resource": "arn:aws:dynamodb:*:*:table/SampleTable" }, { "Sid": "GetStreamRecords", "Effect": "Allow", "Action": "dynamodb:GetRecords", "Resource": "arn:aws:dynamodb:*:*:table/SampleTable/stream/* " }, { "Sid": "WriteLogStreamsAndGroups", "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" }, { "Sid": "CreateLogGroup", "Effect": "Allow", "Action": "logs:CreateLogGroup", "Resource": "*" } ] } ``` ------ # Amazon RDS: Allows full RDS database access within a specific Region RDS: Full access within a Region This example shows how you might create an identity-based policy that allows full RDS database access within a specific Region. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "rds:*", "Resource": ["arn:aws:rds:us-east-1:*:*"] }, { "Effect": "Allow", "Action": ["rds:Describe*"], "Resource": ["*"] } ] } ``` ------ # Amazon RDS: Allows restoring RDS databases, programmatically and in the console RDS: Restore databases (includes console) This example shows how you might create an identity-based policy that allows restoring RDS databases. This policy defines permissions for programmatic and console access. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:Describe*", "rds:CreateDBParameterGroup", "rds:CreateDBSnapshot", "rds:DeleteDBSnapshot", "rds:Describe*", "rds:DownloadDBLogFilePortion", "rds:List*", "rds:ModifyDBInstance", "rds:ModifyDBParameterGroup", "rds:ModifyOptionGroup", "rds:RebootDBInstance", "rds:RestoreDBInstanceFromDBSnapshot", "rds:RestoreDBInstanceToPointInTime" ], "Resource": "*" } ] } ``` ------ # Amazon RDS: Allows tag owners full access to RDS resources that they have tagged RDS: Full access for tag owners This example shows how you might create an identity-based policy that allows tag owners full access to RDS resources that they have tagged. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "rds:Describe*", "rds:List*" ], "Effect": "Allow", "Resource": "*" }, { "Action": [ "rds:DeleteDBInstance", "rds:RebootDBInstance", "rds:ModifyDBInstance" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEqualsIgnoreCase": {"rds:db-tag/Owner": "${aws:username}"} } }, { "Action": [ "rds:ModifyOptionGroup", "rds:DeleteOptionGroup" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEqualsIgnoreCase": {"rds:og-tag/Owner": "${aws:username}"} } }, { "Action": [ "rds:ModifyDBParameterGroup", "rds:ResetDBParameterGroup" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEqualsIgnoreCase": {"rds:pg-tag/Owner": "${aws:username}"} } }, { "Action": [ "rds:AuthorizeDBSecurityGroupIngress", "rds:RevokeDBSecurityGroupIngress", "rds:DeleteDBSecurityGroup" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEqualsIgnoreCase": {"rds:secgrp-tag/Owner": "${aws:username}"} } }, { "Action": [ "rds:DeleteDBSnapshot", "rds:RestoreDBInstanceFromDBSnapshot" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEqualsIgnoreCase": {"rds:snapshot-tag/Owner": "${aws:username}"} } }, { "Action": [ "rds:ModifyDBSubnetGroup", "rds:DeleteDBSubnetGroup" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEqualsIgnoreCase": {"rds:subgrp-tag/Owner": "${aws:username}"} } }, { "Action": [ "rds:ModifyEventSubscription", "rds:AddSourceIdentifierToSubscription", "rds:RemoveSourceIdentifierFromSubscription", "rds:DeleteEventSubscription" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEqualsIgnoreCase": {"rds:es-tag/Owner": "${aws:username}"} } } ] } ``` ------ # Amazon S3: Allows Amazon Cognito users to access objects in their bucket S3: Access bucket if cognito This example shows how you might create an identity-based policy that allows Amazon Cognito users to access objects in a specific Amazon S3 bucket. This policy allows access only to objects with a name that includes `cognito`, the name of the application, and the federated principal ID, represented by the \$1\$1cognito-identity.amazonaws.com:sub\$1 variable. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). **Note** The 'sub' value used in the object key is not the user's sub value in the User Pool, it is the identity id associated with the user in the Identity Pool. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ListYourObjects", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": [ "arn:aws:s3:::bucket-name" ], "Condition": { "StringLike": { "s3:prefix": [ "cognito/application-name/${cognito-identity.amazonaws.com:sub}/*" ] } } }, { "Sid": "ReadWriteDeleteYourObjects", "Effect": "Allow", "Action": [ "s3:DeleteObject", "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bucket-name/cognito/application-name/${cognito-identity.amazonaws.com:sub}/*" ] } ] } ``` ------ Amazon Cognito provides authentication, authorization, and user management for your web and mobile apps. Your users can sign in directly with a user name and password, or through a third party such as Facebook, Amazon, or Google. The two main components of Amazon Cognito are user pools and identity pools. User pools are user directories that provide sign-up and sign-in options for your app users. Identity pools enable you to grant your users access to other AWS services. You can use identity pools and user pools separately or together. For more information about Amazon Cognito, see [Amazon Cognito User Guide](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html). # Amazon S3: Allows federated users access to their Amazon S3 home directory, programmatically and in the console S3: Access federated principal home directory (includes console) This example shows how you might create an identity-based policy that allows federated principals to access their own home directory bucket object in S3. The home directory is a bucket that includes a `home` folder and folders for individual federated principals. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). The `${aws:userid}` variable in this policy resolves to `role-id:specified-name`. The `role-id` part of the federated principal ID is a unique identifier assigned to the federated principal's role during creation. For more information, see [Unique identifiers](reference_identifiers.md#identifiers-unique-ids). The `specified-name` is the [RoleSessionName parameter](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html#API_AssumeRoleWithWebIdentity_RequestParameters) passed to the `AssumeRoleWithWebIdentity` request when the federated principal assumed their role. You can view the role ID using the AWS CLI command `aws iam get-role --role-name specified-name`. For example, imagine that you specify the friendly name `John` and the CLI returns the role ID `AROAXXT2NJT7D3SIQN7Z6`. In this case, the federated principal's user ID is `AROAXXT2NJT7D3SIQN7Z6:John`. This policy then allows the federated principal John to access the Amazon S3 bucket with prefix `AROAXXT2NJT7D3SIQN7Z6:John`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "S3ConsoleAccess", "Effect": "Allow", "Action": [ "s3:GetAccountPublicAccessBlock", "s3:GetBucketAcl", "s3:GetBucketLocation", "s3:GetBucketPolicyStatus", "s3:GetBucketPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "*" }, { "Sid": "ListObjectsInBucket", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket", "Condition": { "StringLike": { "s3:prefix": [ "", "home/", "home/${aws:userid}/*" ] } } }, { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:userid}", "arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:userid}/*" ] } ] } ``` ------ # Amazon S3: S3 Bucket access, but production bucket denied without recent MFA S3: Full access with recent MFA This example shows how you might create an identity-based policy that allows an Amazon S3 administrator to access any bucket, including updating, adding, and deleting objects. However, it explicitly denies access to the `amzn-s3-demo-bucket-production` bucket if the user has not signed in using [multi-factor authentication (MFA)](id_credentials_mfa.md) within the last thirty minutes. This policy grants the permissions necessary to perform this action in the console or programmatically using the AWS CLI or AWS API. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). This policy never allows programmatic access to the `amzn-s3-demo-bucket` bucket using long-term user access keys. This is accomplished using the `aws:MultiFactorAuthAge` condition key with the `NumericGreaterThanIfExists` condition operator. This policy condition returns `true` if MFA is not present or if the age of the MFA is greater than 30 minutes. In those situations, access is denied. To access the `amzn-s3-demo-bucket-production` bucket programmatically, the S3 administrator must use temporary credentials that were generated in the last 30 minutes using the [GetSessionToken](id_credentials_temp_request.md#api_getsessiontoken) API operation. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ListAllS3Buckets", "Effect": "Allow", "Action": ["s3:ListAllMyBuckets"], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowBucketLevelActions", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowBucketObjectActions", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:PutObjectAcl", "s3:GetObject", "s3:GetObjectAcl", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::*/*" }, { "Sid": "RequireMFAForProductionBucket", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-production/*", "arn:aws:s3:::amzn-s3-demo-bucket-production" ], "Condition": { "NumericGreaterThanIfExists": {"aws:MultiFactorAuthAge": "1800"} } } ] } ``` ------ # Amazon S3: Allows IAM users access to their S3 home directory, programmatically and in the console S3: Access IAM user home directory (includes console) This example shows how you might create an identity-based policy that allows IAM users to access their own home directory bucket object in S3. The home directory is a bucket that includes a `home` folder and folders for individual users. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). This policy will not work when using IAM roles because the `aws:username` variable is not available when using IAM roles. For details about principal key values, see [Principal key values](reference_policies_variables.md#principaltable). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "S3ConsoleAccess", "Effect": "Allow", "Action": [ "s3:GetAccountPublicAccessBlock", "s3:GetBucketAcl", "s3:GetBucketLocation", "s3:GetBucketPolicyStatus", "s3:GetBucketPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "*" }, { "Sid": "ListObjectsInBucket", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket", "Condition": { "StringLike": { "s3:prefix": [ "", "home/", "home/${aws:username}/*" ] } } }, { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}", "arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}/*" ] } ] } ``` ------ # Amazon S3: Restrict management to a specific S3 bucket S3: Restrict management to a specific bucket This example shows how you might create an identity-based policy that restricts management of an Amazon S3 bucket to that specific bucket. This policy grants permission to perform all Amazon S3 actions, but deny access to every AWS service except Amazon S3. See the following example. According to this policy, you can only access Amazon S3 actions that you can perform on an S3 bucket or S3 object resource. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). If this policy is used in combination with other policies (such as the [AmazonS3FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonS3FullAccess) or [AmazonEC2FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEC2FullAccess) AWS managed policies) that allow actions denied by this policy, then access is denied. This is because an explicit deny statement takes precedence over allow statements. For more information, see [How AWS enforcement code logic evaluates requests to allow or deny access](reference_policies_evaluation-logic_policy-eval-denyallow.md). **Warning** [`NotAction`](reference_policies_elements_notaction.md) and [`NotResource`](reference_policies_elements_notresource.md) are advanced policy elements that must be used with care. This policy denies access to every AWS service except Amazon S3. If you attach this policy to a user, any other policies that grant permissions to other services are ignored and access is denied. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] }, { "Effect": "Deny", "NotAction": "s3:*", "NotResource": [ "arn:aws:s3:::bucket-name", "arn:aws:s3:::bucket-name/*" ] } ] } ``` ------ # Grant read and write access to Amazon S3 bucket objects S3: Read and write objects to a specific bucket This example shows how you might create an identity-based policy that allows `Read` and `Write` access to objects in a specific Amazon S3 bucket. This policy grants the permissions necessary to complete this action programmatically from the AWS API or AWS CLI. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). The `s3:*Object` action uses a wildcard as part of the action name. The `AllObjectActions` statement allows the `GetObject`, `DeleteObject`, `PutObject`, and any other Amazon S3 action that ends with the word "Object". ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ListObjectsInBucket", "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::bucket-name"] }, { "Sid": "AllObjectActions", "Effect": "Allow", "Action": "s3:*Object", "Resource": ["arn:aws:s3:::bucket-name/*"] } ] } ``` ------ **Note** To allow `Read` and `Write` access to an object in an Amazon S3 bucket and also include additional permissions for console access, see [Amazon S3: Allows read and write access to objects in an S3 Bucket, programmatically and in the console](reference_policies_examples_s3_rw-bucket-console.md). # Amazon S3: Allows read and write access to objects in an S3 Bucket, programmatically and in the console S3: Read and write to a specific bucket (includes console) This example shows how you might create an identity-based policy that allows `Read` and `Write` access to objects in a specific S3 bucket. This policy defines permissions for programmatic and console access. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. Then, follow the directions in [create a policy](access_policies_create.md) or [edit a policy](access_policies_manage-edit.md). The `s3:*Object` action uses a wildcard as part of the action name. The `AllObjectActions` statement allows the `GetObject`, `DeleteObject`, `PutObject`, and any other Amazon S3 action that ends with the word "Object". ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "S3ConsoleAccess", "Effect": "Allow", "Action": [ "s3:GetAccountPublicAccessBlock", "s3:GetBucketAcl", "s3:GetBucketLocation", "s3:GetBucketPolicyStatus", "s3:GetBucketPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "*" }, { "Sid": "ListObjectsInBucket", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"] }, { "Sid": "AllObjectActions", "Effect": "Allow", "Action": "s3:*Object", "Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/*"] } ] } ``` ------