# Policies and permissions in AWS Identity and Access Management Policies and permissions Manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. A policy 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. AWS supports seven types of policies: identity-based policies, resource-based policies, permissions boundaries, AWS Organizations service control policies (SCPs), AWS Organizations resource control policies (RCPs), access control lists (ACLs), and session policies. IAM policies define permissions for an action regardless of the method that you use to perform the operation. For example, if a policy allows the [GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html) action, then a user with that policy can get user information from the AWS Management Console, the AWS CLI, or the AWS API. When you create an IAM user, you can choose to allow console or programmatic access. If console access is allowed, the IAM user can sign in to the console using their sign-in credentials. If programmatic access is allowed, the user can use access keys to work with the CLI or API. ## Policy types The following policy types, listed in order from most frequently used to less frequently used, are available for use in AWS. For more details, see the sections below for each policy type. + **[Identity-based policies](#policies_id-based)** – Attach [managed](#managedpolicy) and [inline](#inline) policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity. + **[Resource-based policies](#policies_resource-based)** – Attach inline policies to resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant permissions to the principal that is specified in the policy. Principals can be in the same account as the resource or in other accounts. + **[Permissions boundaries](#policies_bound)** – Use a managed policy as the permissions boundary for an IAM entity (user or role). That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions. Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity. + **[AWS Organizations SCPs](#policies_scp)** – Use an AWS Organizations service control policy (SCP) to define the maximum permissions for IAM users and IAM roles within accounts in your organization or organizational unit (OU). SCPs limit permissions that identity-based policies or resource-based policies grant to IAM users or IAM roles within the account. SCPs do not grant permissions. + **[AWS Organizations RCPs](#policies_rcp)** – Use an AWS Organizations resource control policy (RCP) to define the maximum permissions for resources within accounts in your organization or organizational unit (OU). RCPs limit permissions that identity-based and resource-based policies can grant to resources in accounts within your organization. RCPs do not grant permissions. + **[Access control lists (ACLs)](#policies_acl)** – Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document structure. ACLs are cross-account permissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to entities within the same account. + **[Session policies](#policies_session)** – Pass advanced session policies when you use the AWS CLI or AWS API to assume a role or a federated user. Session policies limit the permissions that the role or user's identity-based policies grant to the session. Session policies limit permissions for a created session, but do not grant permissions. For more information, see [Session Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session). ### Identity-based policies Identity-based policies are JSON permissions policy documents that control what actions an identity (users, groups of users, and roles) can perform, on which resources, and under what conditions. Identity-based policies can be further categorized: + **Managed policies** – Standalone identity-based policies that you can attach to multiple users, groups, and roles in your AWS account. There are two types of managed policies: + **AWS managed policies** – Managed policies that are created and managed by AWS. + **Customer managed policies** – Managed policies that you create and manage in your AWS account. Customer managed policies provide more precise control over your policies than AWS managed policies. + **Inline policies** – Policies that you add directly to a single user, group, or role. Inline policies maintain a strict one-to-one relationship between a policy and an identity. They are deleted when you delete the identity. To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](access_policies-choosing-managed-or-inline.md). ### Resource-based policies Resource-based policies are JSON policy documents that you attach to a resource such as an Amazon S3 bucket. These policies grant the specified principal permission to perform specific actions on that resource and defines under what conditions this applies. Resource-based policies are inline policies. There are no managed resource-based policies. To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. Adding a cross-account principal to a resource-based policy is only half of establishing the trust relationship. When the principal and the resource are in separate AWS accounts, you must also use an identity-based policy to grant the principal access to the resource. However, if a resource-based policy grants access to a principal in the same account, no additional identity-based policy is required. For step-by step instructions for granting cross-service access, see [IAM tutorial: Delegate access across AWS accounts using IAM roles](tutorial_cross-account-with-roles.md). The IAM service supports only one type of resource-based policy called a role *trust policy*, which is attached to an IAM role. An IAM role is both an identity and a resource that supports resource-based policies. For that reason, you must attach both a trust policy and an identity-based policy to an IAM role. Trust policies define which principal entities (accounts, users, roles, and federated users) can assume the role. To learn how IAM roles are different from other resource-based policies, see [Cross account resource access in IAM](access_policies-cross-account-resource-access.md). To see which other services support resource-based policies, see [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md). To learn more about resource-based policies, see [Identity-based policies and resource-based policies](access_policies_identity-vs-resource.md). To learn whether principals in accounts outside of your zone of trust (trusted organization or account) have access to assume your roles, see [What is IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). ### IAM permissions boundaries A permissions boundary is an advanced feature in which you set the maximum permissions that an identity-based policy can grant to an IAM entity. When you set a permissions boundary for an entity, the entity can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. If you specify a role session or user in the principal element of a resource-based policy, an explicit allow in the permission boundary is not required. However, if you specify a role ARN in the principal element of a resource-based policy, an explicit allow in the permission boundary is required. In both cases, an explicit deny in the permission boundary is effective. An explicit deny in any of these policies overrides the allow. For more information about permissions boundaries, see [Permissions boundaries for IAM entities](access_policies_boundaries.md). ### AWS Organizations service control policies (SCPs) If you enable all features in an organization, then you can apply service control policies (SCPs) to any or all of your accounts. SCPs are JSON policies that specify the maximum permissions for IAM users and IAM roles within accounts of an organization or organizational unit (OU). The SCP limits permissions for principals in member accounts, including each AWS account root user. An explicit deny in any of these policies overrides an allow in other policies. For more information about AWS Organizations and SCPs, see [Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*. ### AWS Organizations resource control policies (RCPs) If you enable all features in an organization, then you can use resource control policies (RCPs) to centrally apply access controls on resources across multiple AWS accounts. RCPs are JSON policies that you can use to set the maximum available permissions for resources in your accounts without updating the IAM policies attached to each resource that you own. The RCP limits permissions for resources in member accounts and can impact the effective permissions for identities, including the AWS account root user, regardless of whether they belong to your organization. An explicit deny in any applicable RCP overrides an allow in other policies that might be attached to individual identities or resources. For more information about AWS Organizations and RCPs including a list of AWS services that support RCPs, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*. ### Access control lists (ACLs) Access control lists (ACLs) are service policies that allow you to control which principals in another account can access a resource. ACLs cannot be used to control access for a principal within the same account. ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document format. Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access Control List (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) in the *Amazon Simple Storage Service Developer Guide*. ### Session policies Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or an AWS STS federated user principal. The permissions for a session are the intersection of the identity-based policies for the IAM entity (user or role) used to create the session and the session policies. Permissions can also come from a resource-based policy. An explicit deny in any of these policies overrides the allow. You can create role session and pass session policies programmatically using the `AssumeRole`, `AssumeRoleWithSAML`, or `AssumeRoleWithWebIdentity` API operations. You can pass a single JSON inline session policy document using the `Policy` parameter. You can use the `PolicyArns` parameter to specify up to 10 managed session policies. For more information about creating a role session, see [Permissions for temporary security credentials](id_credentials_temp_control-access.md). When you create an AWS STS federated user principal session, you use the access keys of the IAM user to programmatically call the `GetFederationToken` API operation. You must also pass session policies. The resulting session's permissions are the intersection of the identity-based policy and the session policy. For more information about creating a federated user session, see [Requesting credentials through a custom identity broker](id_credentials_temp_request.md#api_getfederationtoken). A resource-based policy can specify the ARN of the user or role as a principal. In that case, the permissions from the resource-based policy are added to the role or user's identity-based policy before the session is created. The session policy limits the total permissions granted by the resource-based policy and the identity-based policy. The resulting session's permissions are the intersection of the session policies and the resource-based policies plus the intersection of the session policies and identity-based policies. ![\[Evaluation of the session policy with a resource-based policy specifying the entity ARN\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/EffectivePermissions-session-rbp-id.png) A resource-based policy can specify the ARN of the session as a principal. In that case, the permissions from the resource-based policy are added after the session is created. The resource-based policy permissions are not limited by the session policy. The resulting session has all the permissions of the resource-based policy *plus* the intersection of the identity-based policy and the session policy. ![\[Evaluation of the session policy with a resource-based policy specifying the session ARN\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/EffectivePermissions-session-rbpsession-id.png) A permissions boundary can set the maximum permissions for a user or role that is used to create a session. In that case, the resulting session's permissions are the intersection of the session policy, the permissions boundary, and the identity-based policy. However, a permissions boundary does not limit permissions granted by a resource-based policy that specifies the ARN of the resulting session. ![\[Evaluation of the session policy with a permissions boundary\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/EffectivePermissions-session-boundary-id.png) ## Policies and the root user The AWS account root user is affected by some policy types but not others. You cannot attach identity-based policies to the root user, and you cannot set the permissions boundary for the root user. However, you can specify the root user as the principal in a resource-based policy or an ACL. A root user is still the member of an account. If that account is a member of an organization in AWS Organizations, the root user is affected by SCPs and RCPs for the account. ## Overview of JSON policies Most policies are stored in AWS as JSON documents. Identity-based policies and policies used to set permissions boundaries are JSON policy documents that you attach to a user or role. Resource-based policies are JSON policy documents that you attach to a resource. SCPs and RCPs are JSON policy documents with restricted syntax that you attach to the AWS Organizations' organization root, organizational unit (OU), or an account. ACLs are also attached to a resource, but you must use a different syntax. Session policies are JSON policies that you provide when you assume a role or federated user session. It is not necessary for you to understand the JSON syntax. You can use the visual editor in the AWS Management Console to create and edit customer managed policies without ever using JSON. However, if you use inline policies for groups or complex policies, you must still create and edit those policies in the JSON editor using the console. For more information about using the visual editor, see [Define custom IAM permissions with customer managed policies](access_policies_create.md) and [Edit IAM policies](access_policies_manage-edit.md). When you create or edit a JSON policy, IAM can perform policy validation to help you create an effective policy. IAM identifies JSON syntax errors, while IAM Access Analyzer provides additional policy checks with recommendations to help you further refine your policies. To learn more about policy validation, see [IAM policy validation](access_policies_policy-validator.md). To learn more about IAM Access Analyzer policy checks and actionable recommendations, see [ IAM Access Analyzer policy validation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html). ### JSON policy document structure As illustrated in the following figure, a JSON policy document includes these elements: + Optional policy-wide information at the top of the document + One or more individual statements** Each statement includes information about a single permission. If a policy includes multiple statements, AWS applies a logical `OR` across the statements when evaluating them. If multiple policies apply to a request, AWS applies a logical `OR` across all of those policies when evaluating them. ![\[JSON policy document structure\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/AccessPolicyLanguage_General_Policy_Structure.diagram.png) The information in a statement is contained within a series of elements. + **Version** – Specify the version of the policy language that you want to use. We recommend that you use the latest `2012-10-17 ` version. For more information, see [IAM JSON policy elements: Version](reference_policies_elements_version.md) + **Statement** – Use this main policy element as a container for the following elements. You can include more than one statement in a policy. + **Sid** (Optional) – Include an optional statement ID to differentiate between your statements. + **Effect** – Use `Allow` or `Deny` to indicate whether the policy allows or denies access. + **Principal** (Required in some circumstances) – If you create a resource-based policy, you must indicate the account, user, role, or AWS STS federated user principal to which you would like to allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element. The principal is implied as that user or role. + **Action** – Include a list of actions that the policy allows or denies. + **Resource** (Required in some circumstances) – If you create an IAM permissions policy, you must specify a list of resources to which the actions apply. If you create a resource-based policy, it depends on the resource you're using as to whether this element is required or not. + **Condition** (Optional) – Specify the circumstances under which the policy grants permission. To learn about these and other more advanced policy elements, see [IAM JSON policy element reference](reference_policies_elements.md). ### Multiple statements and multiple policies If you want to define more than one permission for an entity (user or role), you can use multiple statements in a single policy. You can also attach multiple policies. If you try to define multiple permissions in a single statement, your policy might not grant the access that you expect. We recommend that you break up policies by resource type. Because of the [limited size of policies](reference_iam-quotas.md), it might be necessary to use multiple policies for more complex permissions. It's also a good idea to create functional groupings of permissions in a separate customer managed policy. For example, Create one policy for IAM user management, one for self-management, and another policy for S3 bucket management. Regardless of the combination of multiple statements and multiple policies, AWS [evaluates](reference_policies_evaluation-logic.md) your policies the same way. For example, the following policy has three statements, each of which defines a separate set of permissions within a single account. The statements define the following: + The first statement, with an `Sid` (Statement ID) of `FirstStatement`, lets the user with the attached policy change their own password. The `Resource` element in this statement is "`*`" (which means "all resources"). But in practice, the `ChangePassword` API operation (or equivalent `change-password` CLI command) affects only the password for the user who makes the request. + The second statement lets the user list all the Amazon S3 buckets in their AWS account. The `Resource` element in this statement is `"*"` (which means "all resources"). But because policies don't grant access to resources in other accounts, the user can list only the buckets in their own AWS account. + The third statement lets the user list and retrieve any object that is in a bucket named `amzn-s3-demo-bucket-confidential-data`, but only when the user is authenticated with multi-factor authentication (MFA). The `Condition` element in the policy enforces the MFA authentication. When a policy statement contains a `Condition` element, the statement is only in effect when the `Condition` element evaluates to true. In this case, the `Condition` evaluates to true when the user is MFA-authenticated. If the user is not MFA-authenticated, this `Condition` evaluates to false. In that case, the third statement in this policy does not apply and the user does not have access to the `amzn-s3-demo-bucket-confidential-data` bucket. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "FirstStatement", "Effect": "Allow", "Action": ["iam:ChangePassword"], "Resource": "*" }, { "Sid": "SecondStatement", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "ThirdStatement", "Effect": "Allow", "Action": [ "s3:List*", "s3:Get*" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data", "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*" ], "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} } ] } ``` ------ ### Examples of JSON policy syntax The following identity-based policy allows the implied principal to list a single Amazon S3 bucket named `amzn-s3-demo-bucket`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket" } } ``` ------ The following resource-based policy can be attached to an Amazon S3 bucket. The policy allows members of a specific AWS account to perform any Amazon S3 actions in the bucket named `amzn-s3-demo-bucket`. It allows any action that can be performed on a bucket or the objects within it. (Because the policy grants trust only to the account, individual users in the account must still be granted permissions for the specified Amazon S3 actions.) ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "1", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:root" ] }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] } ] } ``` ------ To view example policies for common scenarios, see [Example IAM identity-based policies](access_policies_examples.md). ## Grant least privilege When you create IAM policies, follow the standard security advice of granting *least privilege*, or granting only the permissions required to perform a task. Determine what users and roles need to do and then craft policies that allow them to perform *only* those tasks. Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later. As an alternative to least privilege, you can use [AWS managed policies](access_policies_managed-vs-inline.md#aws-managed-policies) or policies with wildcard `*` permissions to get started with policies. Consider the security risk of granting your principals more permissions than they need to do their job. Monitor those principals to learn which permissions they are using. Then write least privilege policies. IAM provides several options to help you refine the permissions that you grant. + **Understand access level groupings** – You can use access level groupings to understand the level of access that a policy grants. [Policy actions](reference_policies_elements_action.md) are classified as `List`, `Read`, `Write`, `Permissions management`, or `Tagging`. For example, you can choose actions from the `List` and `Read` access levels to grant read-only access to your users. To learn how to use policy summaries to understand access level permissions, see [Access levels in policy summaries](access_policies_understand-policy-summary-access-level-summaries.md). + **Validate your policies** – You can perform policy validation using IAM Access Analyzer when you create and edit JSON policies. We recommend that you review and validate all of your existing policies. IAM Access Analyzer provides over 100 policy checks to validate your policies. It generates security warnings when a statement in your policy allows access we consider overly permissive. You can use the actionable recommendations that are provided through the security warnings as you work toward granting least privilege. To learn more about policy checks provided by IAM Access Analyzer, see [IAM Access Analyzer policy validation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html). + **Generate a policy based on access activity** – To help you refine the permissions that you grant, you can generate an IAM policy that is based on the access activity for an IAM entity (user or role). IAM Access Analyzer reviews your AWS CloudTrail logs and generates a policy template that contains the permissions that have been used by the entity in your specified time frame. You can use the template to create a managed policy with fine-grained permissions and then attach it to the IAM entity. That way, you grant only the permissions that the user or role needs to interact with AWS resources for your specific use case. To learn more, see [IAM Access Analyzer policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html). + **Use last accessed information** – Another feature that can help with least privilege is *last accessed information*. View this information on the **Access Advisor** tab on the IAM console details page for an IAM user, group, role, or policy. Last accessed information also includes information about the actions that were last accessed for some services, such as Amazon EC2, IAM, Lambda, and Amazon S3. If you sign in using AWS Organizations management account credentials, you can view service last accessed information in the **AWS Organizations** section of the IAM console. You can also use the AWS CLI or AWS API to retrieve a report for last accessed information for entities or policies in IAM or AWS Organizations. You can use this information to identify unnecessary permissions so that you can refine your IAM or AWS Organizations policies to better adhere to the principle of least privilege. For more information, see [Refine permissions in AWS using last accessed information](access_policies_last-accessed.md). + **Review account events in AWS CloudTrail** – To further reduce permissions, you can view your account's events in AWS CloudTrail **Event history**. CloudTrail event logs include detailed event information that you can use to reduce the policy's permissions. The logs include only the actions and resources that your IAM entities need. For more information, see [Viewing CloudTrail Events in the CloudTrail Console](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html) in the *AWS CloudTrail User Guide*. For more information, see the following policy topics for individual services, which provide examples of how to write policies for service-specific resources. + [Using resource-based policies for DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-resource-based.html) in the *Amazon DynamoDB Developer Guide* + [Bucket policies for Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) in the *Amazon Simple Storage Service User Guide* + [Access Control List (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) in the *Amazon Simple Storage Service User Guide* # Managed policies and inline policies When you set the permissions for an identity in IAM, you must decide whether to use an AWS managed policy, a customer managed policy, or an inline policy. The following topics provide more information about each of the types of identity-based policies and when to use them. The following table outlines these policies: | Policy Type | Description | Who manages the policy? | Modify permissions? | Number of principals applied to policy? | | --- | --- | --- | --- | --- | | [AWS managed policies](#aws-managed-policies) | Standalone policy created and administered by AWS. | AWS | No | Many | | [Customer managed policies](#customer-managed-policies) | Policy you create for specific use cases, and you can change or update them as often as you like. | You | Yes | Many | | [Inline policies](#inline-policies) | Policy created for a single IAM identity (user, group, or role) that maintains a strict one-to-one relationship between a policy and an identity. | You | Yes | One | **Topics** + [ ## AWS managed policies ](#aws-managed-policies) + [ ## Customer managed policies ](#customer-managed-policies) + [ ## Inline policies ](#inline-policies) + [ # Choose between managed policies and inline policies ](access_policies-choosing-managed-or-inline.md) + [ # Convert an inline policy to a managed policy ](access_policies-convert-inline-to-managed.md) + [ # Deprecated AWS managed policies ](access_policies_managed-deprecated.md) ## AWS managed policies An *AWS managed policy* is a standalone policy that is created and administered by AWS. A *standalone policy* means that the policy has its own Amazon Resource Name (ARN) that includes the policy name. For example, `arn:aws:iam::aws:policy/IAMReadOnlyAccess` is an AWS managed policy. For more information about ARNs, see [IAM ARNs](reference_identifiers.md#identifiers-arns). For a list of AWS managed policies for AWS services, see [AWS managed policies](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/policy-list.html). AWS managed policies make it convenient for you to assign appropriate permissions to users, IAM groups, and roles. It is faster than writing the policies yourself, and includes permissions for many common use cases. You cannot change the permissions defined in AWS managed policies. AWS occasionally updates the permissions defined in an AWS managed policy. When AWS does this, the update affects all principal entities (IAM users, IAM groups, and IAM roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API calls become available for existing services. For example, the AWS managed policy called **ReadOnlyAccess** provides read-only access to all AWS services and resources. When AWS launches a new service, AWS updates the **ReadOnlyAccess** policy to add read-only permissions for the new service. The updated permissions are applied to all principal entities that the policy is attached to. *Full access AWS managed policies*: These define permissions for service administrators by granting full access to a service. Examples include: + [AmazonDynamoDBFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html) + [IAMFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/IAMFullAccess.html) *Power-user AWS managed policies*: These provide full access to AWS services and resources, but do not allow managing users and IAM groups. Examples include: + [AWSCodeCommitPowerUser](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodeCommitPowerUser.html) + [AWSKeyManagementServicePowerUser](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSKeyManagementServicePowerUser.html) *Partial-access AWS managed policies*: These provide specific levels of access to AWS services without allowing [permissions management](access_policies_understand-policy-summary-access-level-summaries.md#access_policies_access-level) access level permissions. Examples include: + [AmazonMobileAnalyticsWriteOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonMobileAnalyticsWriteOnlyAccess.html) + [AmazonEC2ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html) *Job function AWS managed policies*: These policies align closely with commonly used job functions in the IT industry and facilitate granting permissions for these job functions. One key advantage of using job function policies is that they are maintained and updated by AWS as new services and API operations are introduced. For example, the [AdministratorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html) job function provides full access and permissions delegation to every service and resource in AWS. We recommend that you use this policy only for the account administrator. For power users that require full access to every service except limited access to IAM and AWS Organizations, use the [PowerUserAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/PowerUserAccess.html) job function. For a list and descriptions of the job function policies, see [AWS managed policies for job functions](access_policies_job-functions.md). The following diagram illustrates AWS managed policies. The diagram shows three AWS managed policies: **AdministratorAccess**, **PowerUserAccess**, and **AWSCloudTrail\$1ReadOnlyAccess**. Notice that a single AWS managed policy can be attached to principal entities in different AWS accounts, and to different principal entities in a single AWS account. ![\[Diagram of AWS managed policies\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policies-aws-managed-policies.diagram.png) ## Customer managed policies You can create standalone policies in your own AWS account that you can attach to principal entities (IAM users, IAM groups, and IAM roles). You create these *customer managed policies* for your specific use cases, and you can change and update them as often as you like. Like AWS managed policies, when you attach a policy to a principal entity, you give the entity the permissions that are defined in the policy. When you update permissions in the policy, the changes are applied to all principal entities that the policy is attached to. A great way to create a customer managed policy is to start by copying an existing AWS managed policy. That way you know that the policy is correct at the beginning and all you need to do is customize it to your environment. The following diagram illustrates customer managed policies. Each policy is an entity in IAM with its own [Amazon Resource Name (ARN)](reference_identifiers.md#identifiers-arns) that includes the policy name. Notice that the same policy can be attached to multiple principal entities—for example, the same **DynamoDB-books-app** policy is attached to two different IAM roles. For more information, see [Define custom IAM permissions with customer managed policies](access_policies_create.md) ![\[Diagram of customer managed policies\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policies-customer-managed-policies.diagram.png) ## Inline policies An inline policy is a policy created for a single IAM identity (a user, user group, or role). Inline policies maintain a strict one-to-one relationship between a policy and an identity. They are deleted when you delete the identity. You can create a policy and embed it in an identity, either when you create the identity or later. If a policy could apply to more than one entity, it’s better to use a managed policy. The following diagram illustrates inline policies. Each policy is an inherent part of the user, group, or role. Notice that two roles include the same policy (the **DynamoDB-books-app** policy), but they are not sharing a single policy. Each role has its own copy of the policy. ![\[Diagram of inline policies\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policies-inline-policies.diagram.png) # Choose between managed policies and inline policies Choose between managed or inline policies Consider your use cases when deciding between managed and inline policies. In most cases, we recommend that you use managed policies instead of inline policies. **Note** You can use both managed and inline policies together to define common and unique permissions for a principal entity. Managed policies provide the following features: **Reusability** A single managed policy can be attached to multiple principal entities (users, groups, and roles). You can create a library of policies that define useful permissions for your AWS account, and then attach these policies to principal entities as needed. **Central change management** When you change a managed policy, the change is applied to all principal entities that the policy is attached to. For example, if you want to add permission for a new AWS API, you can update a customer managed policy or associate an AWS managed policy to add the permission. If you're using an AWS managed policy, AWS updates the policy. When a managed policy is updated, the changes are applied to all principal entities that the managed policy is attached to. In contrast, to change an inline policy, you must individually edit each identity that contains the inline policy. For example, if a group and a role both contain the same inline policy, you must individually edit both principal entities to change that policy. **Versioning and rolling back** When you change a customer managed policy, the changed policy doesn't overwrite the existing policy. Instead, IAM creates a new version of the managed policy. IAM stores up to five versions of your customer managed policies. You can use policy versions to revert a policy to an earlier version as needed. A policy version is different from a `Version` policy element. The `Version` policy element is used within a policy and defines the version of the policy language. To learn more about policy versions, see [Versioning IAM policies](access_policies_managed-versioning.md). To learn more about the `Version` policy element see [IAM JSON policy elements: Version](reference_policies_elements_version.md). **Delegating permissions management** You can allow users in your AWS account to attach and detach policies while maintaining control over the permissions defined in those policies. To do this, designate some users as full administrators—that is, administrators that can create, update, and delete policies. You can then designate other users as limited administrators. Those limited administrators can attach policies to other principal entities, but only the policies that you have allowed them to attach. For more information about delegating permissions management, see [Controlling access to policies](access_controlling.md#access_controlling-policies). **Larger policy character limits** The maximum character size limit for managed policies is greater than the character limit for group inline policies. If you reach the inline policy's character size limit, you can create more IAM groups and attach the managed policy to the group. For more information on quotas and limits, see [IAM and AWS STS quotas](reference_iam-quotas.md). **Automatic updates for AWS managed policies** AWS maintains AWS managed policies and updates them when necessary, for example, to add permissions for new AWS services, without you having to make changes. The updates are automatically applied to the principal entities that you have attached the AWS managed policy to. ## Get started with managed policies We recommend using policies that [grant least privilege](access_policies.md#grant-least-priv), or granting only the permissions required to perform a task. The most secure way to grant least privilege is to write a customer managed policy with only the permissions needed by your team. You must create a process to allow your team to request more permissions when necessary. It takes time and expertise to [create IAM customer managed policies](access_policies_create-console.md) that provide your team with only the permissions they need. To get started adding permissions to your IAM identities (users, groups of users, and roles), you can use [AWS managed policies](access_policies_managed-vs-inline.md#aws-managed-policies). AWS managed policies don't grant least privilege permissions. You must consider the security risk of granting your principals more permissions than they need to do their job. You can attach AWS managed policies, including job functions, to any IAM identity. For more information, see [Adding and removing IAM identity permissions](access_policies_manage-attach-detach.md). To switch to least privilege permissions, you can run AWS Identity and Access Management and Access Analyzer to monitor the principals with AWS managed policies. After learning which permissions they are using, then you can write or generate a customer managed policy with only the required permissions for your team. This is less secure, but provides more flexibility as you learn how your team is using AWS. For more information, see [IAM Access Analyzer policy generation](access-analyzer-policy-generation.md). AWS managed policies are designed to provide permissions for many common use cases. For more information about AWS managed policies that are designed for specific job functions, see [AWS managed policies for job functions](access_policies_job-functions.md). For a list of AWS managed policies, see [AWS Managed Policy Reference Guide](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/about-managed-policy-reference.html). ## Using inline policies Inline policies are useful if you want to maintain a strict one-to-one relationship between a policy and the identity to which it is applied. For example, if you want to be sure that the permissions in a policy are not inadvertently assigned to an identity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong identity. In addition, when you use the AWS Management Console to delete that identity, the policies embedded in the identity are deleted as well because they are part of the principal entity. # Convert an inline policy to a managed policy Convert inline policy to managed If you have inline policies in your account, you can convert them to managed policies. To do this, copy the policy to a new managed policy. Next, attach the new policy to the identity that has the inline policy. Then delete the inline policy. ## Converting an inline policy to a managed policy **To convert an inline policy to a managed policy** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane, choose **User groups**, **Users**, or **Roles**. 1. In the list, choose the name of the user group, user, or role that has the policy you want to remove. 1. Choose the **Permissions** tab. 1. For IAM groups, select the name of the inline policy that you want to remove. For users and roles, choose **Show *n* more**, if necessary, and then expand the inline policy that you want to remove. 1. Choose **Copy** to copy the JSON policy document for the policy. 1. In the navigation pane, choose **Policies**. 1. Choose **Create policy** and then choose the **JSON** option. 1. Replace the existing text with your JSON policy text, and then choose **Next**. 1. Enter a name and optional description for your policy and choose **Create policy**. 1. In the navigation pane, choose **User groups**, **Users**, or **Roles**, and again choose the name of the user group, user, or role that has the policy you want to remove. 1. Choose the **Permissions** tab and then choose **Add permissions**. 1. For IAM groups, select the checkbox next to the name of your new policy, choose **Add permissions**, and then choose **Attach policy**. For users or roles, choose **Add permissions**. On the next page, choose **Attach existing policies directly**, select the checkbox next to the name of your new policy, choose **Next**, and then choose **Add permissions**. You are returned to the **Summary** page for your user group, user, or role. 1. Select the checkbox next to the inline policy that you want to remove and choose **Remove**. # Deprecated AWS managed policies To simplify the assignment of permissions, AWS provides [managed policies](access_policies_managed-vs-inline.md)—predefined policies that are ready to be attached to your IAM users, groups, and roles. Sometimes AWS needs to add a new permission to an existing policy, such as when a new service is introduced. Adding a new permission to an existing policy does not disrupt or remove any feature or ability. However, AWS might choose to create a *new* policy when the needed changes could impact customers if they were applied to an existing policy. For example, removing permissions from an existing policy could break the permissions of any IAM entity or application that depended upon it, potentially disrupting a critical operation. Therefore, when such a change is required, AWS creates a completely new policy with the required changes and makes it available to customers. The old policy is then marked *deprecated*. For more information, see [Deprecated AWS managed policies](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/about-managed-policy-reference.html#deprecated-managed-policies) in *AWS Managed Policy Reference Guide*. # Establish permissions guardrails using data perimeters Data perimeters Data perimeter guardrails are meant to serve as always-on boundaries to help protect your data across a broad set of AWS accounts and resources. Data perimeters follow IAM security best practices to [establish permissions guardrails across multiple accounts](best-practices.md#bp-permissions-guardrails). These organization-wide permissions guardrails do not replace your existing fine-grained access controls. Instead, they work as **coarse-grained access controls** that help improve your security strategy by ensuring users, roles, and resources adhere to a set of defined security standards. A data perimeter is set of permission guardrails in your AWS environment which help ensure that only your trusted identities are accessing trusted resources from expected networks. + Trusted identities: Principals (IAM roles or users) in your AWS accounts and AWS services acting on your behalf. + Trusted resources: Resources owned by your AWS accounts or by AWS services acting on your behalf. + Expected networks: Your on-premises data centers and virtual private clouds (VPCs), or networks of AWS services acting on your behalf. **Note** In some cases, you may need to extend your data perimeter to also include access by your trusted business partners. You should consider all intended data access patterns when you create a definition of trusted identities, trusted resources, and expected networks specific to your company and your use of AWS services. Data perimeter controls should be treated as any other security control within the information security and risk management program. This means that you should perform a threat analysis to identify potential risks within your cloud environment, and then, based on your own risk acceptance criteria, select and implement appropriated data perimeter controls. To better inform the iterative risk-based approach to data perimeter implementation, you need to understand what security risks and threat vectors are addressed by data perimeter controls as well as your security priorities. ## Data perimeter controls Data perimeter coarse-grained controls help you achieve six distinct security objectives across three data perimeters through the implementation of different combinations of [Policy types](access_policies.md#access_policy-types) and [condition keys](reference_policies_condition-keys.md). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html) You can think of data perimeters as creating a firm boundary around your data to prevent unintended access patterns. Although data perimeters can prevent broad unintended access, you still need to make fine-grained access control decisions. Establishing a data perimeter does not diminish the need to continuously fine-tune permissions by using tools such as [IAM Access Analyzer](what-is-access-analyzer.md) as part of your journey to [least privilege](best-practices.md#grant-least-privilege). To enforce data perimeter controls on resources that are currently not supported by RCPs, you can use resource-based policies that are attached to resources directly. For a list of services that support RCPs and resource-based policies, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) and [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md). To enforce network perimeter controls, we recommend that you use `aws:VpceOrgID`, `aws:VpceOrgPaths`, and `aws:VpceAccount` only if all services you want to restrict access to are currently supported. Using these condition keys with unsupported services can lead to unintended authorization results. For a list of services that support the keys, see the [AWS global condition context keys](reference_policies_condition-keys.md). If you need to enforce the controls on a wider range of services, consider using `aws:SourceVpc` and `aws:SourceVpce` instead. ## Identity perimeter An identity perimeter is a set of coarse-grained preventative access controls that help ensure only trusted identities can access your resources and only trusted identities are allowed from your network. Trusted identities usually include principals (roles or users) in your AWS accounts and AWS services acting on your behalf. All other identities are considered untrusted and are prevented by the identity perimeter unless an explicit exception is granted. The following global condition keys help enforce identity perimeter controls based on your definition of trusted identities. Use these keys in resource control policies to restrict access to resources, or in [VPC endpoint policies](https://docs.aws.amazon.com//vpc/latest/privatelink/vpc-endpoints-access.html) to restrict access to your networks. ### Identities owned by you You can use the following condition keys to define IAM principals that you create and manage in your AWS accounts. + [aws:PrincipalOrgID](reference_policies_condition-keys.md#condition-keys-principalorgid) – You can use this condition key to ensure that IAM principals making the request belong to the specified organization in AWS Organizations. + [aws:PrincipalOrgPaths](reference_policies_condition-keys.md#condition-keys-principalorgpaths) – You can use this condition key to ensure that the IAM user , IAM role, AWS STS federated user principal, SAML federated principal, OIDC federated principal, or AWS account root user making the request belong to the specified organizational unit (OU) in AWS Organizations. + [aws:PrincipalAccount](reference_policies_condition-keys.md#condition-keys-principalaccount) – You can use this condition key to ensure resources can only be accessed by the principal account that you specify in the policy. ### Identities of AWS services acting on your behalf You can use the following condition keys to allow AWS services to use their own identities to access your resources when they act on your behalf. + [aws:PrincipalIsAWSService](reference_policies_condition-keys.md#condition-keys-principalisawsservice) and [aws:SourceOrgID](reference_policies_condition-keys.md#condition-keys-sourceorgid) (or [aws:SourceOrgPaths](reference_policies_condition-keys.md#condition-keys-sourceorgpaths) and [aws:SourceAccount](reference_policies_condition-keys.md#condition-keys-sourceaccount)) – You can use these condition keys to ensure that when [AWS service principals](reference_policies_elements_principal.md#principal-services) access your resources, they do it only on behalf of a resource in the specified organization, organizational unit, or an account in AWS Organizations. For more information, see [ Establishing a data perimeter on AWS: Allow only trusted identities to access company data](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/). ## Resource perimeter A resource perimeter is a set of coarse-grained preventative access controls that help ensure your identities can access only trusted resources and only trusted resources can be accessed from your network. Trusted resources usually include resources owned by your AWS accounts or by AWS services acting on your behalf. The following global condition keys help enforce resource perimeter controls based on your definition of trusted resources. Use these keys in [Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) to restrict which resources can be accessed by your identities, or in [ VPC endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) to restrict which resources can be accessed from your networks. ### Resources owned by you You can use the following condition keys to define AWS resources that you create and manage in your AWS accounts. + [aws:ResourceOrgID](reference_policies_condition-keys.md#condition-keys-resourceorgid) – You can use this condition key to ensure the resource that is being accessed belongs to the specified organization in AWS Organizations. + [aws:ResourceOrgPaths](reference_policies_condition-keys.md#condition-keys-resourceorgpaths) – You can use this condition key to ensure the resource that is being accessed belongs to the specified organizational unit(OU) in AWS Organizations. + [aws:ResourceAccount](reference_policies_condition-keys.md#condition-keys-resourceaccount) – You can use this condition key to ensure the resource that is being accessed belongs to the specified AWS account. ### Resources of AWS services acting on your behalf In some cases, you may need to permit access to AWS owned resources, resources that do not belong to your organization and that are accessed by your principals or by AWS services acting on your behalf. For more information about these scenarios, see [ Establishing a data perimeter on AWS: Allow only trusted resources from my organization](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-resources-from-my-organization/). ## Network perimeter A network perimeter is a set of coarse-grained preventative access controls that help ensure your identities can access resources only from expected networks and your resources can only be accessed from expected networks. Expected networks usually include your on-premises data centers and virtual private clouds (VPCs) and networks of AWS services acting on your behalf. The following global condition keys help enforce network perimeter controls based on your definition of expected networks. Use these keys in [service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) to restrict networks your identities can communicate from, or in [resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) to constrain resource access to expected networks. ### Networks owned by you You can use the following condition keys to define networks your employees and applications are expected to use to access your resources, such as your corporate IP CIDR range and your VPCs. + [aws:SourceIp](reference_policies_condition-keys.md#condition-keys-sourceip) – You can use this condition key to ensure the requester's IP address is within a specified IP range. + [aws:SourceVpc](reference_policies_condition-keys.md#condition-keys-sourcevpc) – You can use this condition key to ensure the VPC endpoint the request travels through belongs to the specified VPC. + [aws:SourceVpce](reference_policies_condition-keys.md#condition-keys-sourcevpce) – You can use this condition key to ensure the request travels through the specified VPC endpoint. + [aws:VpceAccount](reference_policies_condition-keys.md#condition-keys-vpceaccount) – You can use this condition key to ensure requests come through VPC endpoints owned by the specified AWS account. + [aws:VpceOrgPaths](reference_policies_condition-keys.md#condition-keys-vpceorgpaths) – You can use this condition key to ensure that IAM principals making the request belong to the specified organizational unit (OU) in AWS Organizations. + [aws:VpceOrgID](reference_policies_condition-keys.md#condition-keys-vpceorgid) – You can use this condition key to ensure requests come through VPC endpoints owned by accounts in the specified organization in AWS Organizations. `aws:VpceAccount`, `aws:VpceOrgPaths`, and `aws:VpceOrgID` are particularly useful for implementing network perimeter controls that scale automatically with your VPC endpoint usage, without requiring updates to policies when you create new endpoints. See the [AWS global condition context keys](reference_policies_condition-keys.md) for the list of AWS services that support these keys. ### Networks of AWS services acting on your behalf You can use the following condition keys to allow AWS services to access your resources from their networks when they act on your behalf. + [aws:ViaAWSService](reference_policies_condition-keys.md#condition-keys-viaawsservice) – You can use this condition key to ensure that AWS services can make requests on behalf of your principal using [Forward access sessions](access_forward_access_sessions.md) (FAS). + [aws:PrincipalIsAWSService](reference_policies_condition-keys.md#condition-keys-principalisawsservice) – You can use this condition key to ensure that AWS services can access your resources using [AWS service principals](reference_policies_elements_principal.md#principal-services). There are additional scenarios where you need to permit access to AWS services that access your resources from outside your network. For more information, see [Establishing a data perimeter on AWS: Allow access to company data only from expected networks](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-access-to-company-data-only-from-expected-networks/). ## Resources to learn more about data perimeters The following resources can help you learn more about data perimeters across AWS. + [Data perimeters on AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/) – Learn about data perimeters and their benefits and use cases. + [Blog Post Series: Establishing a Data Perimeter on AWS](https://aws.amazon.com/identity/data-perimeters-blog-post-series/) – These blog posts cover prescriptive guidance about establishing your data perimeter at scale, including key security and implementation considerations. + [Data perimeter policy examples](https://github.com/aws-samples/data-perimeter-policy-examples/tree/ce06665ca8b2f07debee7bed5153c3be0f31c73c) – This GitHub repository contains example policies that cover some common patterns to help you implement a data perimeter on AWS. + [Data perimeter helper](https://github.com/aws-samples/data-perimeter-helper/tree/main?tab=readme-ov-file) – This tool helps you design and anticipate the impact of your data perimeter controls by analyzing access activity in your [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) logs. # Permissions boundaries for IAM entities Permissions boundaries AWS supports *permissions boundaries* for IAM entities (users or roles). A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. For more information about policy types, see [Policy types](access_policies.md#access_policy-types). **Important** Don't use resource-based policy statements that include a `NotPrincipal` policy element with a `Deny` effect for IAM users or roles that have a permissions boundary policy attached. The `NotPrincipal` element with a `Deny` effect will always deny any IAM principal that has a permissions boundary policy attached, regardless of the values specified in the `NotPrincipal` element. This causes some IAM users or roles that would otherwise have access to the resource to lose access. We recommend changing your resource-based policy statements to use the condition operator [`ArnNotEquals`](reference_policies_elements_condition_operators.md#Conditions_ARN) with the [`aws:PrincipalArn`](reference_policies_condition-keys.md#condition-keys-principalarn) context key to limit access instead of the `NotPrincipal` element. For information about the `NotPrincipal` element, see [AWS JSON policy elements: NotPrincipal](reference_policies_elements_notprincipal.md). You can use an AWS managed policy or a customer managed policy to set the boundary for an IAM entity (user or role). That policy limits the maximum permissions for the user or role. For example, assume that the IAM user named `Shirley` should be allowed to manage only Amazon S3, Amazon CloudWatch, and Amazon EC2. To enforce this rule, you can use the following policy to set the permissions boundary for the `Shirley` user: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*", "cloudwatch:*", "ec2:*" ], "Resource": "*" } ] } ``` ------ When you use a policy to set the permissions boundary for a user, it limits the user's permissions but does not provide permissions on its own. In this example, the policy sets the maximum permissions of `Shirley` as all operations in Amazon S3, CloudWatch, and Amazon EC2. Shirley can never perform operations in any other service, including IAM, even if she has a permissions policy that allows it. For example, you can add the following policy to the `Shirley` user: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "iam:CreateUser", "Resource": "*" } } ``` ------ This policy allows creating a user in IAM. If you attach this permissions policy to the `Shirley` user, and Shirley tries to create a user, the operation fails. It fails because the permissions boundary does not allow the `iam:CreateUser` operation. Given these two policies, Shirley does not have permission to perform any operations in AWS. You must add a different permissions policy to allow actions in other services, such as Amazon S3. Alternatively, you could update the permissions boundary to allow her to create a user in IAM. ## Evaluating effective permissions with boundaries The permissions boundary for an IAM entity (user or role) sets the maximum permissions that the entity can have. This can change the effective permissions for that user or role. The effective permissions for an entity are the permissions that are granted by all the policies that affect the user or role. Within an account, the permissions for an entity can be affected by identity-based policies, resource-based policies, permissions boundaries, AWS Organizations SCPs, or session policies. For more information about the different types of policies, see [Policies and permissions in AWS Identity and Access Management](access_policies.md). If any one of these policy types explicitly denies access for an operation, then the request is denied. The permissions granted to an entity by multiple permissions types are more complex. For more details about how AWS evaluates policies, see [Policy evaluation logic](reference_policies_evaluation-logic.md). **Identity-based policies with boundaries** – Identity-based policies are inline or managed policies that are attached to a user, group of users, or role. Identity-based policies grant permission to the entity, and permissions boundaries limit those permissions. The effective permissions are the intersection of both policy types. An explicit deny in either of these policies overrides the allow. ![\[Evaluation of identity-based policies and permissions boundaries\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/permissions_boundary.png) **Resource-based policies** – Resource-based policies control how the specified principal can access the resource to which the policy is attached. *Resource-based policies for IAM users* Within the same account, resource-based policies that grant permissions to an IAM user ARN (that is not an AWS STS federated user principal session) are not limited by an implicit deny in an identity-based policy or permissions boundary. ![\[Evaluation of a resource-based policy, permissions boundary, and identity-based policy\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/EffectivePermissions-rbp-boundary-id.png) *Resource-based policies for IAM roles * **IAM role** – Resource-based policies that grant permissions to an IAM role ARN are limited by an implicit deny in a permissions boundary or session policy. **IAM role session** – Within the same account, resource-based policies that grant permissions to an IAM role session ARN grant permissions directly to the assumed role session. Permissions granted directly to a session are not limited by an implicit deny in an identity-based policy, a permissions boundary, or session policy. When you assume a role and make a request, the principal making the request is the IAM role session ARN and not the ARN of the role itself. *Resource-based policies for AWS STS federated user principal sessions* **AWS STS federated user principal sessions** – An AWS STS federated user principal session is a session created by calling [`GetFederationToken`](id_credentials_temp_request.md#api_getfederationtoken). When a federated user makes a request, the principal making the request is the federated user ARN and not the ARN of the IAM user who federated. Within the same account, resource-based policies that grant permissions to a federated user ARN grant permissions directly to the session. Permissions granted directly to a session are not limited by an implicit deny in an identity-based policy, a permissions boundary, or session policy. However, if a resource-based policy grants permission to the ARN of the IAM user who federated, then requests made by the AWS STS federated user principal during the session are limited by an implicit deny in a permission boundary or session policy. **AWS Organizations SCPs** – SCPs are applied to an entire AWS account. They limit permissions for every request made by a principal within the account. An IAM entity (user or role) can make a request that is affected by an SCP, a permissions boundary, and an identity-based policy. In this case, the request is allowed only if all three policy types allow it. The effective permissions are the intersection of all three policy types. An explicit deny in any of these policies overrides the allow. ![\[Evaluation of an SCP, permissions boundary, and identity-based policy\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/EffectivePermissions-scp-boundary-id.png) You can learn [whether your account is a member of an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html#orgs_view_account) in AWS Organizations. Organization members might be affected by an SCP. To view this data using the AWS CLI command or AWS API operation, you must have permissions for the `organizations:DescribeOrganization` action for your AWS Organizations entity. You must have additional permissions to perform the operation in the AWS Organizations console. To learn whether an SCP is denying access to a specific request, or to change your effective permissions, contact your AWS Organizations administrator. **Session policies** – Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The permissions for a session come from the IAM entity (user or role) used to create the session and from the session policy. The entity's identity-based policy permissions are limited by the session policy and the permissions boundary. The effective permissions for this set of policy types are the intersection of all three policy types. An explicit deny in any of these policies overrides the allow. For more information about session policies, see [Session Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session). ![\[Evaluation of a session policy, permissions boundary, and identity-based policy\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/EffectivePermissions-session-boundary-id.png) ## Delegating responsibility to others using permissions boundaries You can use permissions boundaries to delegate permissions management tasks, such as user creation, to IAM users in your account. This permits others to perform tasks on your behalf within a specific boundary of permissions. For example, assume that María is the administrator of the X-Company AWS account. She wants to delegate user creation duties to Zhang. However, she must ensure that Zhang creates users that adhere to the following company rules: + Users cannot use IAM to create or manage users, groups, roles, or policies. + Users are denied access to the Amazon S3 `logs` bucket and cannot access the `i-1234567890abcdef0` Amazon EC2 instance. + Users cannot remove their own boundary policies. To enforce these rules, María completes the following tasks, for which details are included below: 1. María creates the `XCompanyBoundaries` managed policy to use as a permissions boundary for all new users in the account. 1. María creates the `DelegatedUserBoundary` managed policy and assigns it as the permissions boundary for Zhang. Maria makes a note of her admin user's ARN and uses it in the policy to prevent Zhang from accessing it. 1. María creates the `DelegatedUserPermissions` managed policy and attaches it as a permissions policy for Zhang. 1. María tells Zhang about his new responsibilities and limitations. **Task 1:** María must first create a managed policy to define the boundary for the new users. María will allow Zhang to give users the permissions policies they need, but she wants those users to be restricted. To do this, she creates the following customer managed policy with the name `XCompanyBoundaries`. This policy does the following: + Allows users full access to several services + Allows limited self-managing access in the IAM console. This means they can change their password after signing into the console. They can't set their initial password. To allow this, add the `"*LoginProfile"` action to the `AllowManageOwnPasswordAndAccessKeys` statement. + Denies users access to the Amazon S3 logs bucket or the `i-1234567890abcdef0` Amazon EC2 instance ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ServiceBoundaries", "Effect": "Allow", "Action": [ "s3:*", "cloudwatch:*", "ec2:*", "dynamodb:*" ], "Resource": "*" }, { "Sid": "AllowIAMConsoleForCredentials", "Effect": "Allow", "Action": [ "iam:ListUsers", "iam:GetAccountPasswordPolicy" ], "Resource": "*" }, { "Sid": "AllowManageOwnPasswordAndAccessKeys", "Effect": "Allow", "Action": [ "iam:*AccessKey*", "iam:ChangePassword", "iam:GetUser", "iam:*ServiceSpecificCredential*", "iam:*SigningCertificate*" ], "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" } ] } ``` ------ Each statement serves a different purpose: 1. The `ServiceBoundaries` statement of this policy allows full access to the specified AWS services. This means that a new user's actions in these services are limited only by the permissions policies that are attached to the user. 1. 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 when changing your own password. 1. The `AllowManageOwnPasswordAndAccessKeys` statement allows users to manage only their own console password and programmatic access keys. This is important if Zhang or another administrator assigns a new user a permissions policy with full IAM access. In that case, that user could then change their own or other users' permissions. This statement prevents that from happening. 1. The `DenyS3Logs` statement explicitly denies access to the `logs` bucket. 1. The `DenyEC2Production` statement explicitly denies access to the `i-1234567890abcdef0` instance. **Task 2:** María wants to allow Zhang to create all X-Company users, but only with the `XCompanyBoundaries` permissions boundary. She creates the following customer managed policy named `DelegatedUserBoundary`. This policy defines the maximum permissions that Zhang can have. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "CreateOrChangeOnlyWithBoundary", "Effect": "Allow", "Action": [ "iam:AttachUserPolicy", "iam:CreateUser", "iam:DeleteUserPolicy", "iam:DetachUserPolicy", "iam:PutUserPermissionsBoundary", "iam:PutUserPolicy" ], "Resource": "*", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/XCompanyBoundaries" } } }, { "Sid": "CloudWatchAndOtherIAMTasks", "Effect": "Allow", "Action": [ "cloudwatch:*", "iam:CreateAccessKey", "iam:CreateGroup", "iam:CreateLoginProfile", "iam:CreatePolicy", "iam:DeleteGroup", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:DeleteUser", "iam:GetAccountPasswordPolicy", "iam:GetGroup", "iam:GetLoginProfile", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:GetRolePolicy", "iam:GetUser", "iam:GetUserPolicy", "iam:ListAccessKeys", "iam:ListAttachedRolePolicies", "iam:ListAttachedUserPolicies", "iam:ListEntitiesForPolicy", "iam:ListGroups", "iam:ListGroupsForUser", "iam:ListMFADevices", "iam:ListPolicies", "iam:ListPolicyVersions", "iam:ListRolePolicies", "iam:ListSSHPublicKeys", "iam:ListServiceSpecificCredentials", "iam:ListSigningCertificates", "iam:ListUserPolicies", "iam:ListUsers", "iam:SetDefaultPolicyVersion", "iam:SimulateCustomPolicy", "iam:SimulatePrincipalPolicy", "iam:UpdateGroup", "iam:UpdateLoginProfile", "iam:UpdateUser" ], "NotResource": "arn:aws:iam::123456789012:user/Maria" }, { "Sid": "NoBoundaryPolicyEdit", "Effect": "Deny", "Action": [ "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:SetDefaultPolicyVersion" ], "Resource": [ "arn:aws:iam::123456789012:policy/XCompanyBoundaries", "arn:aws:iam::123456789012:policy/DelegatedUserBoundary" ] }, { "Sid": "NoBoundaryUserDelete", "Effect": "Deny", "Action": "iam:DeleteUserPermissionsBoundary", "Resource": "*" } ] } ``` ------ Each statement serves a different purpose: 1. The `CreateOrChangeOnlyWithBoundary` statement allows Zhang to create IAM users but only if he uses the `XCompanyBoundaries` policy to set the permissions boundary. This statement also allows him to set the permissions boundary for existing users but only using that same policy. Finally, this statement allows Zhang to manage permissions policies for users with this permissions boundary set. 1. The `CloudWatchAndOtherIAMTasks` statement allows Zhang to complete other user, group, and policy management tasks. He has permissions to reset passwords and create access keys for any IAM user not listed in the `NotResource` policy element. This allows him to help users with sign-in issues. 1. The `NoBoundaryPolicyEdit` statement denies Zhang access to update the `XCompanyBoundaries` policy. He is not allowed to change any policy that is used to set the permissions boundary for himself or other users. 1. The `NoBoundaryUserDelete` statement denies Zhang access to delete the permissions boundary for himself or other users. María then assigns the `DelegatedUserBoundary` policy [as the permissions boundary](id_users_change-permissions.md#users_change_permissions-set-boundary-console) for the `Zhang` user. **Task 3:** Because the permissions boundary limits the maximum permissions, but does not grant access on its own, Maria must create a permissions policy for Zhang. She creates the following policy named `DelegatedUserPermissions`. This policy defines the operations that Zhang can perform, within the defined boundary. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "IAM", "Effect": "Allow", "Action": "iam:*", "Resource": "*" }, { "Sid": "CloudWatchLimited", "Effect": "Allow", "Action": [ "cloudwatch:GetDashboard", "cloudwatch:GetMetricData", "cloudwatch:ListDashboards", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics" ], "Resource": "*" }, { "Sid": "S3BucketContents", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::ZhangBucket" } ] } ``` ------ Each statement serves a different purpose: 1. The `IAM` statement of the policy allows Zhang full access to IAM. However, because his permissions boundary allows only some IAM operations, his effective IAM permissions are limited only by his permissions boundary. 1. The `CloudWatchLimited` statement allows Zhang to perform five actions in CloudWatch. His permissions boundary allows all actions in CloudWatch, so his effective CloudWatch permissions are limited only by his permissions policy. 1. The `S3BucketContents` statement allows Zhang to list the `ZhangBucket` Amazon S3 bucket. However, his permissions boundary does not allow any Amazon S3 action, so he cannot perform any S3 operations, regardless of his permissions policy. **Note** Zhang's policies allow him to create a user that can then access Amazon S3 resources that he can't access. By delegating these administrative actions, Maria effectively trusts Zhang with access to Amazon S3. María then attaches the `DelegatedUserPermissions` policy as the permissions policy for the `Zhang` user. **Task 4:** She gives Zhang instructions to create a new user. She tells him that he can create new users with any permissions that they need, but he must assign them the `XCompanyBoundaries` policy as a permissions boundary. Zhang completes the following tasks: 1. Zhang creates a user with the AWS Management Console. He types the user name `Nikhil` and enables console access for the user. He clears the checkbox next to **Requires password reset**, because the policies above allow users to change their passwords only after they are signed in to the IAM console. 1. On the **Set permissions** page, Zhang chooses the **IAMFullAccess** and ** AmazonS3ReadOnlyAccess** permissions policies that allow Nikhil to do his work. 1. Zhang skips the **Set permissions boundary** section, forgetting María's instructions. 1. Zhang reviews the user details and chooses **Create user**. The operation fails and access is denied. Zhang's `DelegatedUserBoundary` permissions boundary requires that any user he creates have the `XCompanyBoundaries` policy used as a permissions boundary. 1. Zhang returns to the previous page. In the **Set permissions boundary** section, he chooses the `XCompanyBoundaries` policy. 1. Zhang reviews the user details and chooses **Create user**. The user is created. When Nikhil signs in, he has access to IAM and Amazon S3, except those operations that are denied by the permissions boundary. For example, he can change his own password in IAM but can't create another user or edit his policies. Nikhil has read-only access to Amazon S3. If someone adds a resource-based policy to the `logs` bucket that allows Nikhil to put an object in the bucket, he still cannot access the bucket. The reason is that any actions on the `logs` bucket are explicitly denied by his permissions boundary. An explicit deny in any policy type results in a request being denied. However, if a resource-based policy attached to a Secrets Manager secret allows Nikhil to perform the `secretsmanager:GetSecretValue` action, then Nikhil can retrieve and decrypt the secret. The reason is that Secrets Manager operations are not explicitly denied by his permissions boundary, and implicit denies in permissions boundaries do not limit resource-based policies. # Identity-based policies and resource-based policies Identity vs resource A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. When you create a permissions policy to restrict access to a resource, you can choose an *identity-based policy* or a *resource-based policy*. **Identity-based policies** are attached to an IAM user, group, or role. These policies let you specify what that identity can do (its permissions). For example, you can attach the policy to the IAM user named John, stating that he is allowed to perform the Amazon EC2 `RunInstances` action. The policy could further state that John is allowed to get items from an Amazon DynamoDB table named `MyCompany`. You can also allow John to manage his own IAM security credentials. Identity-based policies can be [managed or inline](access_policies_managed-vs-inline.md). **Resource-based policies** are attached to a resource. For example, you can attach resource-based policies to Amazon S3 buckets, Amazon SQS queues, VPC endpoints, AWS Key Management Service encryption keys, and Amazon DynamoDB tables and streams. For a list of services that support resource-based policies, see [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md). With resource-based policies, you can specify who has access to the resource and what actions they can perform on it. To learn whether principals in accounts outside of your zone of trust (trusted organization or account) have access to assume your roles, see [What is IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). Resource-based policies are inline only, not managed. **Note** *Resource-based* policies differ from *resource-level* permissions. You can attach resource-based policies directly to a resource, as described in this topic. Resource-level permissions refer to the ability to use [ARNs](reference_identifiers.md#identifiers-arns) to specify individual resources in a policy. Resource-based policies are supported only by some AWS services. For a list of which services support resource-based policies and resource-level permissions, see [AWS services that work with IAM](reference_aws-services-that-work-with-iam.md). To learn how identity-based policies and resource-based policies interact within the same account, see [Policy evaluation for requests within a single account](reference_policies_evaluation-logic_policy-eval-basics.md). To learn how the policies interact across accounts, see [Cross-account policy evaluation logic](reference_policies_evaluation-logic-cross-account.md). To better understand these concepts, view the following figure. The administrator of the `123456789012` account attached *identity-based policies* to the `John`, `Carlos`, and `Mary` users. Some of the actions in these policies can be performed on specific resources. For example, the user `John` can perform some actions on `Resource X`. This is a *resource-level permission* in an identity-based policy. The administrator also added *resource-based policies* to `Resource X`, `Resource Y`, and `Resource Z`. Resource-based policies allow you to specify who can access that resource. For example, the resource-based policy on `Resource X` allows the `John` and `Mary` users list and read access to the resource. ![\[Identity-based vs resource-based policies\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/Types_of_Permissions.diagram.png) The `123456789012` account example allows the following users to perform the listed actions: + **John** – John can perform list and read actions on `Resource X`. He is granted this permission by the identity-based policy on his user and the resource-based policy on `Resource X`. + **Carlos** – Carlos can perform list, read, and write actions on `Resource Y`, but is denied access to `Resource Z`. The identity-based policy on Carlos allows him to perform list and read actions on `Resource Y`. The `Resource Y` resource-based policy also allows him write permissions. However, although his identity-based policy allows him access to `Resource Z`, the `Resource Z` resource-based policy denies that access. An explicit `Deny` overrides an `Allow` and his access to `Resource Z` is denied. For more information, see [Policy evaluation logic](reference_policies_evaluation-logic.md). + **Mary** – Mary can perform list, read, and write operations on `Resource X`, `Resource Y`, and `Resource Z`. Her identity-based policy allows her more actions on more resources than the resource-based policies, but none of them deny access. + **Zhang** – Zhang has full access to `Resource Z`. Zhang has no identity-based policies, but the `Resource Z` resource-based policy allows him full access to the resource. Zhang can also perform list and read actions on `Resource Y`. Identity-based policies and resource-based policies are both permissions policies and are evaluated together. For a request to which only permissions policies apply, AWS first checks all policies for a `Deny`. If one exists, then the request is denied. Then AWS checks for each `Allow`. If at least one policy statement allows the action in the request, the request is allowed. It doesn't matter whether the `Allow` is in the identity-based policy or the resource-based policy. **Important** This logic applies only when the request is made within a single AWS account. For requests made from one account to another, the requester in `Account A` must have an identity-based policy that allows them to make a request to the resource in `Account B`. Also, the resource-based policy in `Account B` must allow the requester in `Account A` to access the resource. There must be policies in both accounts that allow the operation, otherwise the request fails. For more information about using resource-based policies for cross-account access, see [Cross account resource access in IAM](access_policies-cross-account-resource-access.md). A user who has specific permissions might request a resource that also has a permissions policy attached to it. In that case, AWS evaluates both sets of permissions when determining whether to grant access to the resource. For information about how policies are evaluated, see [Policy evaluation logic](reference_policies_evaluation-logic.md). **Note** Amazon S3 supports identity-based policies and resource-based policies (referred to as *bucket policies*). In addition, Amazon S3 supports a permission mechanism known as an *access control list (ACL)* that is independent of IAM policies and permissions. You can use IAM policies in combination with Amazon S3 ACLs. For more information, see [Access Control](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html) in the *Amazon Simple Storage Service User Guide*. # Control access to AWS resources using policies Control access using policies You can use a policy to control access to resources within IAM or all of AWS. To use a [policy](access_policies.md) to control access in AWS, you must understand how AWS grants access. AWS is composed of collections of *resources*. An IAM user is a resource. An Amazon S3 bucket is a resource. When you use the AWS API, the AWS CLI, or the AWS Management Console to perform an operation (such as creating a user), you send a *request* for that operation. Your request specifies an action, a resource, a *principal entity* (user or role), a *principal account*, and any necessary request information. All of this information provides *context*. AWS then checks that you (the principal) are authenticated (signed in) and authorized (have permission) to perform the specified action on the specified resource. During authorization, AWS checks all the policies that apply to the context of your request. Most policies are stored in AWS as [JSON documents](access_policies.md#access_policies-json) and specify the permissions for principal entities. For more information about policy types and uses, see [Policies and permissions in AWS Identity and Access Management](access_policies.md). AWS authorizes the request only if each part of your request is allowed by the policies. To view a diagram of this process, see [How IAM works](intro-structure.md). For details about how AWS determines whether a request is allowed, see [Policy evaluation logic](reference_policies_evaluation-logic.md). When you create an IAM policy, you can control access to the following: + **[Principals](#access_controlling-principals)** – Control what the person making the request (the [principal](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#principal)) is allowed to do. + **[IAM Identities](#access_controlling-identities)** – Control which IAM identities (IAM groups, users, and roles) can be accessed and how. + **[IAM Policies](#access_controlling-policies)** – Control who can create, edit, and delete customer managed policies, and who can attach and detach all managed policies. + **[AWS Resources](#access_controlling-resources)** – Control who has access to resources using an identity-based policy or a resource-based policy. + **[AWS Accounts](#access_controlling-principal-accounts)** – Control whether a request is allowed only for members of a specific account. Policies let you specify who has access to AWS resources, and what actions they can perform on those resources. Every IAM user starts with no permissions. In other words, by default, users can do nothing, not even view their own access keys. To give a user permission to do something, you can add the permission to the user (that is, attach a policy to the user). Or you can add the user to a user group that has the intended permission. For example, you might grant a user permission to list his or her own access keys. You might also expand that permission and also let each user create, update, and delete their own keys. When you give permissions to a user group, all users in that user group get those permissions. For example, you can give the Administrators user group permission to perform any of the IAM actions on any of the AWS account resources. Another example: You can give the Managers user group permission to describe the Amazon EC2 instances of the AWS account. For information about how to delegate basic permissions to your users, IAM groups, and roles, see [Permissions required to access IAM resources](access_permissions-required.md). For additional examples of policies that illustrate basic permissions, see [Example policies for administering IAM resources](id_credentials_delegate-permissions_examples.md). ## Controlling access for principals You can use policies to control what the person making the request (the principal) is allowed to do. To do this, you must attach an identity-based policy to that person's identity (user, user group, or role). You can also use a [permissions boundary](access_policies_boundaries.md) to set the maximum permissions that an entity (user or role) can have. For example, assume that you want the user Zhang Wei to have full access to CloudWatch, Amazon DynamoDB, Amazon EC2, and Amazon S3. You can create two different policies so that you can later break them up if you need one set of permissions for a different user. Or you can put both the permissions together in a single policy, and then attach that policy to the IAM user that is named Zhang Wei. You could also attach a policy to a user group to which Zhang belongs, or a role that Zhang can assume. As a result, when Zhang views the contents of an S3 bucket, his requests are allowed. If he tries to create a new IAM user, his request is denied because he doesn't have permission. You can use a permissions boundary on Zhang to make sure that he is never given access to the `amzn-s3-demo-bucket1` S3 bucket. To do this, determine the *maximum* permissions that you want Zhang to have. In this case, you control what he does using his permissions policies. Here, you only care that he doesn't access the confidential bucket. So you use the following policy to define Zhang's boundary to allow all AWS actions for Amazon S3 and a few other services but deny access to the `amzn-s3-demo-bucket1` S3 bucket. Because the permissions boundary does not allow any IAM actions, it prevents Zhang from deleting his (or anyone's) boundary. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "PermissionsBoundarySomeServices", "Effect": "Allow", "Action": [ "cloudwatch:*", "dynamodb:*", "ec2:*", "s3:*" ], "Resource": "*" }, { "Sid": "PermissionsBoundaryNoConfidentialBucket", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket1", "arn:aws:s3:::amzn-s3-demo-bucket1/*" ] } ] } ``` ------ When you assign a policy like this as a permissions boundary for a user, remember that it does not grant any permissions. It sets the maximum permissions that an identity-based policy can grant to an IAM entity. For more information about permissions boundaries, see [Permissions boundaries for IAM entities](access_policies_boundaries.md). For detailed information about the procedures mentioned previously, refer to these resources: + To learn more about creating an IAM policy that you can attach to a principal, see [Define custom IAM permissions with customer managed policies](access_policies_create.md). + To learn how to attach an IAM policy to a principal, see [Adding and removing IAM identity permissions](access_policies_manage-attach-detach.md). + To see an example policy for granting full access to EC2, see [Amazon EC2: Allows full EC2 access within a specific Region, programmatically and in the console](reference_policies_examples_ec2_region.md). + To allow read-only access to an S3 bucket, use the first two statements of the following example policy: [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). + To see an example policy for allowing users to set their credentials, such as their console password, their programmatic access keys, and their MFA devices, 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). ## Controlling access to identities You can use IAM policies to control what your users can do to an identity by creating a policy that you attach to all users through a user group. To do this, create a policy that limits what can be done to an identity, or who can access it. For example, you can create a user group named **AllUsers**, and then attach that user group to all users. When you create the user group, you might give all your users access to set their credentials as described in the previous section. You can then create a policy that denies access to change the user group unless the user name is included in the condition of the policy. But that part of the policy only denies access to anyone except those users listed. You also have to include permissions to allow all the user group management actions for everyone in the user group. Finally, you attach this policy to the user group so that it is applied to all users. As a result, when a user not specified in the policy tries to make changes to the user group, the request is denied. **To create this policy with the visual editor** 1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. In the navigation pane on the left, choose **Policies**. If this is your first time choosing **Policies**, the **Welcome to Managed Policies** page appears. Choose **Get Started**. 1. Choose **Create policy**. 1. On the **Policy editor** section, choose the **Visual** option. 1. In **Select a service** choose **IAM**. 1. In **Actions allowed**, type **group** in the search box. The visual editor shows all the IAM actions that contain the word `group`. Select all of the checkboxes. 1. Choose **Resources** to specify resources for your policy. Based on the actions you chose, you should see **group** and **user** resource types. + **group** – Choose **Add ARNs**. For **Resource in**, select the **Any account** option. Select the **Any group name with path** checkbox and then type the user group name **AllUsers**. Then choose **Add ARNs**. + **user** – Select the checkbox next to **Any in this account**. One of the actions that you chose, `ListGroups`, does not support using specific resources. You do not have to choose **All resources** for that action. When you save your policy or view the policy in the **JSON** editor, you can see that IAM automatically creates a new permission block granting this action permission on all resources. 1. To add another permission block, choose **Add more permissions**. 1. Choose **Select a service** and then choose **IAM**. 1. Choose **Actions allowed** and then choose **Switch to deny permissions**. When you do that, the entire block is used to deny permissions. 1. Type **group** in the search box. The visual editor shows you all the IAM actions that contain the word `group`. Select the check boxes next to the following actions: + **CreateGroup** + **DeleteGroup** + **RemoveUserFromGroup** + **AttachGroupPolicy** + **DeleteGroupPolicy** + **DetachGroupPolicy** + **PutGroupPolicy** + **UpdateGroup** 1. Choose **Resources** to specify the resources for your policy. Based on the actions that you chose, you should see the **group** resource type. Choose **Add ARNs**. For **Resource in**, select the **Any account** option. For **Any group name with path**, type the user group name **AllUsers**. Then choose **Add ARNs**. 1. Choose **Request conditions - *optional*** and then choose **Add another condition**. Complete the form with the following values: + **Condition key** – Choose **aws:username** + **Qualifier** – Choose **Default** + **Operator** – Choose **StringNotEquals** + **Value** – Type **srodriguez** and then choose **Add** to add another value. Type **mjackson** and then choose **Add** to add another value. Type **adesai** and then choose **Add condition**. This condition ensures that access will be denied to the specified user group management actions when the user making the call is not included in the list. Because this explicitly denies permission, it overrides the previous block that allowed those users to call the actions. Users on the list are not denied access, and they are granted permission in the first permission block, so they can fully manage the user group. 1. When you are finished, choose **Next**. **Note** You can switch between the **Visual** and **JSON** editor options any time. However, if you make changes or choose **Next** in the **Visual** editor option, IAM might restructure your policy to optimize it for the visual editor. For more information, see [Policy restructuring](troubleshoot_policies.md#troubleshoot_viseditor-restructure). 1. On the **Review and create** page, for the **Policy Name**, type **LimitAllUserGroupManagement**. For the **Description**, type **Allows all users read-only access to a specific user group, and allows only specific users access to make changes to the user group**. Review **Permissions defined in this policy** to make sure that you have granted the intended permissions. Then choose **Create policy** to save your new policy. 1. Attach the policy to your user group. For more information, see [Adding and removing IAM identity permissions](access_policies_manage-attach-detach.md). Alternatively, you can create the same policy using this example JSON policy document. To view this JSON policy, see [IAM: Allows specific IAM users to manage a group programmatically and in the console](reference_policies_examples_iam_users-manage-group.md). For detailed instructions for creating a policy using a JSON document, see [Creating policies using the JSON editor](access_policies_create-console.md#access_policies_create-json-editor). ## Controlling access to policies You can control how your users can apply AWS managed policies. To do this, attach this policy to all your users. Ideally, you can do this using a user group. For example, you might create a policy that allows users to attach only the [IAMUserChangePassword](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/IAMUserChangePassword) and [PowerUserAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/PowerUserAccess) AWS managed policies to a new IAM user, user group, or role. For customer managed policies, you can control who can create, update, and delete these policies. You can control who can attach and detach policies to and from principal entities (IAM groups, users, and roles). You can also control which policies a user can attach or detach, and to and from which entities. For example, you can give permissions to an account administrator to create, update, and delete policies. Then you give permissions to a team leader or other limited administrator to attach and detach these policies to and from principal entities that the limited administrator manages. For more information, refer to these resources: + To learn more about creating an IAM policy that you can attach to a principal, see [Define custom IAM permissions with customer managed policies](access_policies_create.md). + To learn how to attach an IAM policy to a principal, see [Adding and removing IAM identity permissions](access_policies_manage-attach-detach.md). + To see an example policy for limiting the use of managed policies, see [IAM: Limits managed policies that can be applied to an IAM user, group, or role](reference_policies_examples_iam_limit-managed.md). ### Controlling permissions for creating, updating, and deleting customer managed policies You can use [IAM policies](access_policies.md) to control who is allowed to create, update, and delete customer managed policies in your AWS account. The following list contains API operations that pertain directly to creating, updating, and deleting policies or policy versions: + [CreatePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicy.html) + [CreatePolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicyVersion.html) + [DeletePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeletePolicy.html) + [DeletePolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeletePolicyVersion.html) + [SetDefaultPolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetDefaultPolicyVersion.html) The API operations in the preceding list correspond to actions that you can allow or deny—that is, permissions that you can grant—using an IAM policy. Consider the following example policy. It allows a user to create, update (that is, create a new policy version), delete, and set a default version for all customer managed policies in the AWS account. The example policy also allows the user to list policies and get policies. To learn how to create a policy using this example JSON policy document, see [Creating policies using the JSON editor](access_policies_create-console.md#access_policies_create-json-editor). **Example policy that allows creating, updating, deleting, listing, getting, and setting the default version for all policies** **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:CreatePolicy", "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:ListPolicies", "iam:ListPolicyVersions", "iam:SetDefaultPolicyVersion" ], "Resource": "*" } } ``` You can create policies that limit the use of these API operations to affect only the managed policies that you specify. For example, you might want to allow a user to set the default version and delete policy versions, but only for specific customer managed policies. You do this by specifying the policy ARN in the `Resource` element of the policy that grants these permissions. The following example shows a policy that allows a user to delete policy versions and set the default version. But these actions are only allowed for the customer managed policies that include the path /TEAM-A/. The customer managed policy ARN is specified in the `Resource` element of the policy. (In this example the ARN includes a path and a wildcard and thus matches all customer managed policies that include the path /TEAM-A/). To learn how to create a policy using this example JSON policy document, see [Creating policies using the JSON editor](access_policies_create-console.md#access_policies_create-json-editor). For more information about using paths in the names of customer managed policies, see [Friendly names and paths](reference_identifiers.md#identifiers-friendly-names). **Example policy that allows deleting policy versions and setting the default version for only specific policies** **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:DeletePolicyVersion", "iam:SetDefaultPolicyVersion" ], "Resource": "arn:aws:iam::111122223333:policy/TEAM-A/*" } } ``` ### Controlling permissions for attaching and detaching managed policies You can also use IAM policies to allow users to work with only specific managed policies. In effect, you can control which permissions a user is allowed to grant to other principal entities. The following list shows API operations that pertain directly to attaching and detaching managed policies to and from principal entities: + [AttachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html) + [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) + [AttachUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html) + [DetachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachGroupPolicy.html) + [DetachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachRolePolicy.html) + [DetachUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachUserPolicy.html) You can create policies that limit the use of these API operations to affect only the specific managed policies and/or principal entities that you specify. For example, you might want to allow a user to attach managed policies, but only the managed policies that you specify. Or, you might want to allow a user to attach managed policies, but only to the principal entities that you specify. The following example policy allows a user to attach managed policies to only the IAM groups and roles that include the path /TEAM-A/. The user group and role ARNs are specified in the `Resource` element of the policy. (In this example the ARNs include a path and a wildcard character and thus match all IAM groups and roles that include the path /TEAM-A/). To learn how to create a policy using this example JSON policy document, see [Creating policies using the JSON editor](access_policies_create-console.md#access_policies_create-json-editor). **Example policy that allows attaching managed policies to only specific user groups or roles** **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachGroupPolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::111122223333:group/TEAM-A/*", "arn:aws:iam::111122223333:role/TEAM-A/*" ] } } ``` You can further limit the actions in the preceding example to affect only specific policies. That is, you can control which permissions a user is allowed to attach to other principal entities—by adding a condition to the policy. In the following example, the condition ensures that the `AttachGroupPolicy` and `AttachRolePolicy` permissions are allowed only when the policy being attached matches one of the specified policies. The condition uses the `iam:PolicyARN` [condition key](reference_policies_elements_condition.md) to determine which policy or policies are allowed to be attached. The following example policy expands on the previous example. It allows a user to attach only the managed policies that include the path /TEAM-A/ to only the IAM groups and roles that include the path /TEAM-A/. To learn how to create a policy using this example JSON policy document, see [Creating policies using the JSON editor](access_policies_create-console.md#access_policies_create-json-editor). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachGroupPolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::111122223333:group/TEAM-A/*", "arn:aws:iam::111122223333:role/TEAM-A/*" ], "Condition": { "ArnLike": { "iam:PolicyARN": "arn:aws:iam::111122223333:policy/TEAM-A/*" } } } } ``` ------ This policy uses the `ArnLike` condition operator, but you can also use the `ArnEquals` condition operator because these two condition operators behave identically. For more information about `ArnLike` and `ArnEquals`, see [Amazon Resource Name (ARN) condition operators](reference_policies_elements_condition_operators.md#Conditions_ARN) in the *Condition Types* section of the *Policy Element Reference*. For example, you can limit the use of actions to involve only the managed policies that you specify. You do this by specifying the policy ARN in the `Condition` element of the policy that grants these permissions. For example, to specify the ARN of a customer managed policy: ``` "Condition": {"ArnEquals": {"iam:PolicyARN": "arn:aws:iam::123456789012:policy/POLICY-NAME"} } ``` You can also specify the ARN of an AWS managed policy in a policy's `Condition` element. The ARN of an AWS managed policy uses the special alias `aws` in the policy ARN instead of an account ID, as in this example: ``` "Condition": {"ArnEquals": {"iam:PolicyARN": "arn:aws:iam::aws:policy/AmazonEC2FullAccess"} } ``` ## Controlling access to resources You can control access to resources using an identity-based policy or a resource-based policy. In an identity-based policy, you attach the policy to an identity and specify what resources that identity can access. In a resource-based policy, you attach a policy to the resource that you want to control. In the policy, you specify which principals can access that resource. For more information about both types of policies, see [Identity-based policies and resource-based policies](access_policies_identity-vs-resource.md). For more information, refer to these resources: + To learn more about creating an IAM policy that you can attach to a principal, see [Define custom IAM permissions with customer managed policies](access_policies_create.md). + To learn how to attach an IAM policy to a principal, see [Adding and removing IAM identity permissions](access_policies_manage-attach-detach.md). + Amazon S3 supports using resource-based policies on their buckets. For more information, see [Bucket Policy Examples](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html). **Resource Creators Do Not Automatically Have Permissions** If you sign in using the AWS account root user credentials, you have permission to perform any action on resources that belong to the account. However, this isn't true for IAM users. An IAM user might be granted access to create a resource, but the user's permissions, even for that resource, are limited to what's been explicitly granted. This means that just because you create a resource, such as an IAM role, you do not automatically have permission to edit or delete that role. Additionally, your permission can be revoked at any time by the account owner or by another user who has been granted access to manage your permissions. ## Controlling access to principals in a specific account You can directly grant IAM users in your own account access to your resources. If users from another account need access to your resources, you can create an IAM role. A role is an entity that includes permissions but isn't associated with a specific user. Users from other accounts can then assume the role and access resources according to the permissions you've assigned to the role. For more information, see [Access for an IAM user in another AWS account that you own](id_roles_common-scenarios_aws-accounts.md). **Note** Some services support resource-based policies as described in [Identity-based policies and resource-based policies](access_policies_identity-vs-resource.md) (such as Amazon S3, Amazon SNS, and Amazon SQS). For those services, an alternative to using roles is to attach a policy to the resource (bucket, topic, or queue) that you want to share. The resource-based policy can specify the AWS account that has permissions to access the resource. # Controlling access to and for IAM users and roles using tags Control access to IAM users and roles using tags Use the information in the following section to control who can access your IAM users and roles and what resources your users and roles can access. For more general information and examples of controlling access to other AWS resources, including other IAM resources, see [Tags for AWS Identity and Access Management resources](id_tags.md). **Note** For details about case sensitivity for tag keys and tag key values, see [Case sensitivity](id_tags.md#case-sensitivity). Tags can be attached to the IAM *resource*, passed in the *request*, or attached to the *principal* that is making the request. An IAM user or role can be both a resource and principal. For example, you can write a policy that allows a user to list the groups for a user. This operation is allowed only if the user making the request (the principal) has the same `project=blue` tag as the user they're trying to view. In this example, the user can view the group membership for any user, including themselves, as long as they are working on the same project. To control access based on tags, you provide tag information in the [condition element](reference_policies_elements_condition.md) of a policy. When you create an IAM policy, you can use IAM tags and the associated tag condition key to control access to any of the following: + **[Resource](access_tags.md#access_tags_control-resources)** – Control access to user or role resources based on their tags. To do this, use the **aws:ResourceTag/*key-name*** condition key to specify which tag key-value pair must be attached to the resource. For more information, see [Controlling access to AWS resources](access_tags.md#access_tags_control-resources). + **[Request](access_tags.md#access_tags_control-requests)** – Control what tags can be passed in an IAM request. To do this, use the **aws:RequestTag/*key-name*** condition key to specify what tags can be added, changed, or removed from an IAM user or role. This key is used the same way for IAM resources and other AWS resources. For more information, see [Controlling access during AWS requests](access_tags.md#access_tags_control-requests). + **[Principal](#access_iam-tags_control-principals)** – Control what the person making the request (the principal) is allowed to do based on the tags that are attached to that person's IAM user or role. To do this, use the **aws:PrincipalTag/*key-name*** condition key to specify what tags must be attached to the IAM user or role before the request is allowed. + **[Any part of the authorization process](#access_iam-tags_control-tag-keys)** – Use the **aws:TagKeys** condition key to control whether specific tag keys can be used in a request or by a principal. In this case, the key value does not matter. This key behaves similarly for IAM and other AWS services. However, when you tag a user in IAM, this also controls whether the principal can make the request to any service. For more information, see [Controlling access based on tag keys](access_tags.md#access_tags_control-tag-keys). You can create an IAM policy using the visual editor, using JSON, or by importing an existing managed policy. For details, see [Define custom IAM permissions with customer managed policies](access_policies_create.md). **Note** You can also pass [session tags](id_session-tags.md) when you assume an IAM role or federate a user. These are valid only for the length of the session. ## Controlling access for IAM principals You can control what the principal is allowed to do based on the tags attached to that person's identity. This example shows how you might create an identity-based policy that allows any user in this account to view the group membership for any user, including themselves, as long as they are working on the same project. This operation is allowed only when the user's resource tag and the principal's tag have the same value for the tag key `project`. 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": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "iam:ListGroupsForUser", "Resource": "arn:aws:iam::111222333444:user/*", "Condition": { "StringEquals": {"aws:ResourceTag/project": "${aws:PrincipalTag/project}"} } }] } ``` ------ ## Controlling access based on tag keys You can use tags in your IAM policies to control whether specific tag keys can be used in a request or by a principal. This example shows how you might create an identity-based policy that allows removing only the tag with the `temporary` key from users. 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:UntagUser", "Resource": "*", "Condition": {"ForAllValues:StringEquals": {"aws:TagKeys": ["temporary"]}} }] } ``` ------ # Controlling access to AWS resources using tags Control access to AWS resources using tags You can use tags to control access to your AWS resources that support tagging, including IAM resources. You can tag IAM users and roles to control what they can access. To learn how to tag IAM users and roles, see [Tags for AWS Identity and Access Management resources](id_tags.md). Additionally, you can control access to the following IAM resources: customer managed policies, IAM identity providers, instance profiles, server certificates, and virtual MFA devices. To view a tutorial for creating and testing a policy that allows IAM roles with principal tags to access resources with matching tags, see [IAM tutorial: Define permissions to access AWS resources based on tags](tutorial_attribute-based-access-control.md). Use the information in the following section to control access to other AWS resources, including IAM resources, without tagging IAM users or roles. Before you use tags to control access to your AWS resources, you must understand how AWS grants access. AWS is composed of collections of *resources*. An Amazon EC2 instance is a resource. An Amazon S3 bucket is a resource. You can use the AWS API, the AWS CLI, or the AWS Management Console to perform an operation, such as creating a bucket in Amazon S3. When you do, you send a *request* for that operation. Your request specifies an action, a resource, a *principal entity* (user or role), a *principal account*, and any necessary request information. All of this information provides *context*. AWS then checks that you (the principal entity) are authenticated (signed in) and authorized (have permission) to perform the specified action on the specified resource. During authorization, AWS checks all the policies that apply to the context of your request. Most policies are stored in AWS as [JSON documents](access_policies.md#access_policies-json) and specify the permissions for principal entities. For more information about policy types and uses, see [Policies and permissions in AWS Identity and Access Management](access_policies.md). AWS authorizes the request only if each part of your request is allowed by the policies. To view a diagram and learn more about the IAM infrastructure, see [How IAM works](intro-structure.md). For details about how IAM determines whether a request is allowed, see [Policy evaluation logic](reference_policies_evaluation-logic.md). Tags are another consideration in this process because tags can be attached to the *resource* or passed in the *request* to services that support tagging. To control access based on tags, you provide tag information in the [condition element](reference_policies_elements_condition.md) of a policy. To learn whether an AWS service supports controlling access using tags, 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 **ABAC** column. Choose the name of the service to view the authorization and access control documentation for that service. You can then create an IAM policy that allows or denies access to a resource based on that resource's tag. In that policy, you can use tag condition keys to control access to any of the following: + **[Resource](#access_tags_control-resources)** – Control access to AWS service resources based on the tags on those resources. To do this, use the **aws:ResourceTag/*key-name*** condition key to determine whether to allow access to the resource based on the tags that are attached to the resource. + **[Request](#access_tags_control-requests)** – Control what tags can be passed in a request. To do this, use the **aws:RequestTag/*key-name*** condition key to specify what tag key-value pairs can be passed in a request to tag an AWS resource. + **[Any part of the authorization process](#access_tags_control-tag-keys)** – Use the **aws:TagKeys** condition key to control whether specific tag keys can be in a request. You can create an IAM policy visually, using JSON, or by importing an existing managed policy. For details, see [Define custom IAM permissions with customer managed policies](access_policies_create.md). **Note** Some services allow users to specify tags when they create the resource if they have permissions to use the action that creates the resource. ## Controlling access to AWS resources You can use conditions in your IAM policies to control access to AWS resources based on the tags on that resource. You can do this using the global `aws:ResourceTag/tag-key` condition key, or a service-specific key. Some services support only the service-specific version of this key and not the global version. **Warning** Do not try to control who can pass a role by tagging the role and then using the `ResourceTag` condition key in a policy with the `iam:PassRole` action. This approach does not have reliable results. For more information about permissions required to pass a role to a service, see [Grant a user permissions to pass a role to an AWS service](id_roles_use_passrole.md). This example shows how you might create an identity-based policy that allows starting or stopping Amazon EC2 instances. These operations are allowed only if the instance tag `Owner` has the value of the 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": "*" } ] } ``` ------ You can attach this policy to the IAM users in your account. If a user named `richard` attempts to start an Amazon EC2 instance, the instance must be tagged `Owner=richard` or `owner=richard`. Otherwise he will be denied access. The tag key `Owner` matches both `Owner` and `owner` because condition key names are not case-sensitive. For more information, see [IAM JSON policy elements: Condition](reference_policies_elements_condition.md). This example shows how you might create an identity-based policy that uses the `team` principal tag in the resource ARN. The policy grants permission to delete Amazon Simple Queue Service queues, but only if the queue name starts with the team name followed by `-queue`. For example, `qa-queue` if `qa` is the team name for the `team` principal tag. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Sid": "AllQueueActions", "Effect": "Allow", "Action": "sqs:DeleteQueue", "Resource": "arn:aws:sqs:us-east-2:111122223333:${aws:PrincipalTag/team}-queue" } } ``` ------ ## Controlling access during AWS requests You can use conditions in your IAM policies to control what tag key-value pairs can be passed in a request that applies tags to an AWS resource. This example shows how you might create an identity-based policy that allows using the Amazon EC2 `CreateTags` action to attach tags to an instance. You can attach tags only if the tag contains the `environment` key and the `preprod` or `production` values. If you want, you can use the `ForAllValues` modifier with the `aws:TagKeys` condition key to indicate that only the key `environment` is allowed in the request. This stops users from including other keys, such as accidentally using `Environment` instead of `environment`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "ec2:CreateTags", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringEquals": { "aws:RequestTag/environment": [ "preprod", "production" ] }, "ForAllValues:StringEquals": {"aws:TagKeys": "environment"} } } } ``` ------ ## Controlling access based on tag keys You can use a condition in your IAM policies to control whether specific tag keys can be used in a request. We recommend that when you use policies to control access using tags, you use the [`aws:TagKeys` condition key](reference_policies_condition-keys.md#condition-keys-tagkeys). AWS services that support tags might allow you to create multiple tag key names that differ only by case, such as tagging an Amazon EC2 instance with `stack=production` and `Stack=test`. Key names are not case sensitive in policy conditions. This means that if you specify `"aws:ResourceTag/TagKey1": "Value1"` in the condition element of your policy, then the condition matches a resource tag key named either `TagKey1` or `tagkey1`, but not both. To prevent duplicate tags with a key that varies only by case, use the `aws:TagKeys` condition to define the tag keys that your users can apply, or use tag policies, available with AWS Organizations. For more information see [Tag Policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) in the *AWS Organizations User Guide*. This example shows how you might create an identity-based policy that allows creating and tagging a Secrets Manager secret, but only with the tag keys `environment` or `cost-center`. The `Null` condition ensures that the condition evaluates to `false` if there are no tags in the request. ``` { "Effect": "Allow", "Action": [ "secretsmanager:CreateSecret", "secretsmanager:TagResource" ], "Resource": "*", "Condition": { "Null": { "aws:TagKeys": "false" }, "ForAllValues:StringEquals": { "aws:TagKeys": [ "environment", "cost-center" ] } } } ``` # Cross account resource access in IAM Cross account resource access For some AWS services, you can grant cross-account access to your resources using IAM. To do this, you can attach a resource policy directly to the resource that you want to share, or use a role as a proxy. To share the resource directly, the resource that you want to share must support [resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-resource-based-policies). Unlike an identity-based policy for a role, a resource-based policy specifies who (which principal) can access that resource. Use a role as a proxy when you want to access resources in another account that do not support resource-based policies. For details about the differences between these policy types, see [Identity-based policies and resource-based policies](access_policies_identity-vs-resource.md). **Note** IAM roles and resource-based policies delegate access across accounts only within a single partition. For example, you have an account in US West (N. California) in the standard `aws` partition. You also have an account in China in the `aws-cn` partition. You can't use a resource-based policy in your account in China to allow access for users in your standard AWS account. ## Cross-account access using roles Not all AWS services support resource-based policies. For these services, you can use cross-account IAM roles to centralize permission management when providing cross-account access to multiple services. A cross-account IAM role is an IAM role that includes a [trust policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#term_trust-policy) that allows IAM principals in another AWS account to assume the role. Put simply, you can create a role in one AWS account that delegates specific permissions to another AWS account. For information about attaching a policy to an IAM identity, see [Manage IAM policies](access_policies_manage.md). **Note** When a principal switches to a role to temporarily use the permissions of the role, they give up their original permissions and take on the permissions assigned to the role they’ve assumed. Let’s take a look at the overall process as it applies to APN Partner software that needs to access a customer account. 1. The customer creates an IAM role in their own account with a policy that allows access the Amazon S3 resources that the APN partner requires. In this example, the role name is `APNPartner`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::bucket-name" ] } ] } ``` ------ 1. Then, the customer specifies that the role can be assumed by the partner’s AWS account by providing the APN Partner’s AWS account ID in the [trust policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) for the `APNPartner` role. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/APN-user-name" }, "Action": "sts:AssumeRole" } ] } ``` ------ 1. The customer gives the Amazon Resource Name (ARN) of the role to the APN partner. The ARN is the fully qualified name of the role. ``` arn:aws:iam::Customer-Account-ID:role/APNPartner ``` **Note** We recommend using an external ID in multi-tenant situations. For details, see [Access to AWS accounts owned by third parties](id_roles_common-scenarios_third-party.md). 1. When the APN Partner’s software needs to access the customer’s account, the software calls the [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API in the AWS Security Token Service with the ARN of the role in the customer’s account. STS returns a temporary AWS credential that allows the software to do its work. For another example of granting cross-account access using roles, see [Access for an IAM user in another AWS account that you own](id_roles_common-scenarios_aws-accounts.md). You can also follow the [IAM tutorial: Delegate access across AWS accounts using IAM roles](tutorial_cross-account-with-roles.md). ## Cross-account access using resource-based policies When an account accesses a resource through another account using a resource-based policy, the principal still works in the trusted account and does not have to give up their permissions to receive the role permissions. In other words, the principal continues to have access to resources in the trusted account while having access to the resource in the trusting account. This is useful for tasks such as copying information to or from the shared resource in the other account. The principals that you can specify in a resource based policy include accounts, IAM users, AWS STS federated user principals, SAML federated principals, OIDC federated principals, IAM roles, assumed-role sessions, or AWS services. For more information, see [Specifying a principal](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_principal.html#Principal_specifying). To learn whether principals in accounts outside of your zone of trust (trusted organization or account) have access to assume your roles, see [Identifying resources shared with an external entity](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html#what-is-access-analyzer-resource-identification). The following list includes some of the AWS services that support resource-based policies. For a complete list of the growing number of AWS services that support attaching permission policies to resources instead of principals, 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 **Resource Based** column. + **Amazon S3 buckets** — The policy is attached to the bucket, but the policy controls access to both the bucket and the objects in it. For more information, see [Bucket policies for Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) in the *Amazon Simple Storage Service User Guide*. In some cases, it may be best to use roles for cross-account access to Amazon S3. For more information, see the [example walkthroughs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access.html) in the *Amazon Simple Storage Service User Guide*. + **Amazon Simple Notification Service (Amazon SNS) topics** — For more information, go to [Example cases for Amazon SNS access control](https://docs.aws.amazon.com//sns/latest/dg/sns-access-policy-use-cases.html) in the *Amazon Simple Notification Service Developer Guide*. + **Amazon Simple Queue Service (Amazon SQS) queues** – For more information, go to [Appendix: The Access Policy Language](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-creating-custom-policies.html) in the *Amazon Simple Queue Service Developer Guide*. ## Resource-based policies to delegate AWS permissions If a resource grants permissions to principals in your account, you can then delegate those permissions to specific IAM identities. Identities are users, groups of users, or roles in your account. You delegate permissions by attaching a policy to the identity. You can grant up to the maximum permissions that are allowed by the resource-owning account. **Important** In cross account access, a principal needs an `Allow` in the identity policy **and** the resource-based policy. Assume that a resource-based policy allows all principals in your account full administrative access to a resource. Then you can delegate full access, read-only access, or any other partial access to principals in your AWS account. Alternatively, if the resource-based policy allows only list permissions, then you can delegate only list access. If you try to delegate more permissions than your account has, your principals will still have only list access. For more information about how these decisions are made, see [Determining whether a request is allowed or denied within an account](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html). **Note** IAM roles and resource-based policies delegate access across accounts only within a single partition. For example, you can't add cross-account access between an account in the standard `aws` partition and an account in the `aws-cn` partition. For example, assume that you manage `AccountA` and `AccountB`. In AccountA, you have an Amazon S3 bucket named `BucketA`. ![\[A resource-based policy created for Amazon S3 bucket provides AccountB permissions to AccountA.\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/access_policies-cross-account.png) 1. You attach a resource-based policy to `BucketA` that allows all principals in AccountB full access to objects in your bucket. They can create, read, or delete any objects in that bucket. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "PrincipalAccess", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "s3:*", "Resource": "arn:aws:s3:::BucketA/*" } ] } ``` ------ AccountA gives AccountB full access to BucketA by naming AccountB as a principal in the resource-based policy. As a result, AccountB is authorized to perform any action on BucketA, and the AccountB administrator can delegate access to its users in AccountB. The AccountB root user has all of the permissions that are granted to the account. Therefore, the root user has full access to BucketA. 1. In AccountB, attach a policy to the IAM user named User2. That policy allows the user read-only access to the objects in BucketA. That means that User2 can view the objects, but not create, edit, or delete them. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect" : "Allow", "Action" : [ "s3:Get*", "s3:List*" ], "Resource" : "arn:aws:s3:::BucketA/*" } ] } ``` ------ The maximum level of access that AccountB can delegate is the access level that is granted to the account. In this case, the resource-based policy granted full access to AccountB, but User2 is granted only read-only access. The AccountB administrator does not give access to User1. By default, users do not have any permissions except those that are explicitly granted, so User1 does not have access to BucketA. IAM evaluates a principal's permissions at the time the principal makes a request. If you use wildcards (\$1) to give users full access to your resources, principals can access any resources that your AWS account has access to. This is true even for resources you add or gain access to after creating the user's policy. In the preceding example, if AccountB had attached a policy to User2 that allowed full access to all resources in all accounts, User2 would automatically have access to any resources that AccountB has access to. This includes the BucketA access and access to any other resources granted by resource-based policies in AccountA. For more information about complex uses of roles, such as granting access to applications and services, see [Common scenarios for IAM roles](id_roles_common-scenarios.md). **Important** Give access only to entities you trust, and give the minimum level of access necessary. Whenever the trusted entity is another AWS account, any IAM principal can be granted access to your resource. The trusted AWS account can delegate access only to the extent that it has been granted access; it cannot delegate more access than the account itself has been granted. For information about permissions, policies, and the permission policy language that you use to write policies, see [Access management for AWS resources](access.md). # Forward access sessions Forward access sessions (FAS) is an IAM technology used by AWS services to pass your identity, permissions, and session attributes when an AWS service makes a request on your behalf. FAS uses the permissions of the identity calling an AWS service, combined with an AWS service’s identity to make requests to downstream services. FAS requests are only made to AWS services on behalf of an IAM principal after a service has received a request that requires interactions with other AWS services or resources to complete. When a FAS request is made: + The service that receives the initial request from an IAM principal checks the permissions of the IAM principal. + The service that receives a subsequent FAS request also checks the permissions of the same IAM principal. For example, FAS is used by Amazon S3 to make calls to AWS Key Management Service to decrypt an object when [SSE-KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) was used to encrypt it. When downloading an SSE-KMS encrypted object, a role named **data-reader** calls GetObject on the object against Amazon S3, and does not call AWS KMS directly. After receiving the GetObject request and authorizing data-reader, Amazon S3 then makes a FAS request to AWS KMS in order to decrypt the Amazon S3 object. When KMS receives the FAS request it checks the permissions of the role and only authorizes the decryption request if data-reader has the correct permissions on the KMS key. The requests to both Amazon S3 and AWS KMS are authorized using the role’s permissions and is only successful if data-reader has permissions to both the Amazon S3 object and the AWS KMS key. ![\[A flow diagram of an IAM role being passed as the principal to Amazon S3 and then to AWS KMS.\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/access-fas-example.png) **Note** Additional FAS requests can be made by services who have received a FAS request. In such cases, the requesting principal must have permissions for all services called by FAS. ## FAS Requests and IAM policy conditions When FAS requests are made, [aws:CalledVia](reference_policies_condition-keys.md#condition-keys-calledvia), [aws:CalledViaFirst](reference_policies_condition-keys.md#condition-keys-calledviafirst), and [aws:CalledViaLast](reference_policies_condition-keys.md#condition-keys-calledvialast) condition keys are populated with the service principal of the service that initiated the FAS call. The [aws:ViaAWSService](reference_policies_condition-keys.md#condition-keys-viaawsservice) condition key value is set to `true` whenever a FAS request is made. In the following diagram, the request to CloudFormation directly does not have any `aws:CalledVia` or `aws:ViaAWSService` condition keys set. When CloudFormation and DynamoDB make downstream FAS requests on the behalf of the role, the values for these condition keys are populated. ![\[A flow diagram of an IAM role being passed as the principal to CloudFormation and then passing the condition key values to DynamoDB and AWS KMS.\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/access-fas-example2.png) To allow a FAS request to be made when it would otherwise be denied by a Deny policy statement with a condition key testing Source IP addresses or Source VPCs, you must use condition keys to provide an exception for FAS requests in your Deny policy. This can be done for all FAS requests by using the `aws:ViaAWSService` condition key. To allow only specific AWS services to make FAS requests, use `aws:CalledVia`. **Important** When a FAS request is made after an initial request is made through a VPC endpoint, the condition key values for `aws:SourceVpce`, `aws:SourceVpc`, and `aws:VpcSourceIp` from the initial request are not used in FAS requests. When writing policies using `aws:VPCSourceIP` or `aws:SourceVPCE` to conditionally grant access, you must also use `aws:ViaAWSService` or `aws:CalledVia` to allow FAS requests. When a FAS request is made after an initial request is received by a public AWS service endpoint, subsequent FAS requests will be made with the same `aws:SourceIP` condition key value. ## Example: Allow Amazon S3 access from a VPC or with FAS In the following IAM policy example, Amazon S3 GetObject and Athena requests are only allowed if they originate from VPC endpoints attached to *example\$1vpc*, or if the request is a FAS request made by Athena. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "OnlyAllowMyIPs", "Effect": "Allow", "Action": [ "s3:GetObject*", "athena:StartQueryExecution", "athena:GetQueryResults", "athena:GetWorkGroup", "athena:StopQueryExecution", "athena:GetQueryExecution" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceVPC": [ "vpc-111bbb22" ] } } }, { "Sid": "OnlyAllowFAS", "Effect": "Allow", "Action": [ "s3:GetObject*" ], "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": "athena.amazonaws.com" } } } ] } ``` ------ For additional examples of using condition keys to allow FAS access, see the [ data perimeter example policy repo](https://github.com/aws-samples/data-perimeter-policy-examples). # 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/*"] } ] } ``` ------