IAM Access Analyzer policy generation

Generate a policy for an IAM role

1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.

2. In the navigation pane on the left, choose Roles.

   Note

   The steps to generate a policy based on activity for an IAM user are almost identical. To do this, choose Users instead of Roles.

3. In the list of roles in your account, choose the name of the role whose activity you want to use to generate a policy.

4. On the Permissions tab, in the Generate policy based on CloudTrail events section, choose Generate policy.

5. On the Generate policy page, specify the time period that you want IAM Access Analyzer to analyze your CloudTrail events for actions taken with the role. You can choose a range of up to 90 days. We recommend that you choose the shortest time period possible to reduce the policy generation time.

6. In the CloudTrail access section, choose a suitable existing role or create a new role if a suitable role does not exist. The role gives IAM Access Analyzer permissions to access your CloudTrail data on your behalf to review access activity to identify the services and actions that have been used. To learn more about the permissions required for this role, see Permissions required to generate a policy.

7. In the CloudTrail trail to be analyzed section, specify the CloudTrail trail that logs events for the account.

   If you choose a CloudTrail trail that stores logs in a different account, an information box about cross-account access is displayed. Cross-account access requires additional set up. To learn more, see Choose a role for cross-account access later in this topic.

8. Choose Generate policy.

9. While policy generation is in progress, you are returned to the Roles Summary page on the Permissions tab. Wait until the status in the Policy request details section displays Success, and then choose View generated policy. You can view the generated policy for up to seven days. If you generate another policy, the existing policy is replaced with the new one that you generate.

1. Review the following sections:

   • On the Review permissions page, review the list of Actions included in the generated policy. The list displays the services and actions that IAM Access Analyzer identified were used by the role in the specified date range.

   • The Services used section displays additional services that IAM Access Analyzer identified that were used by the role in the specified date range. Information about which actions were used might not be available for the services listed in this section. Use the menus for each service listed to manually choose the actions that you want to include in the policy.

2. When you are done adding actions, choose Next.

To customize the generated policy

1. Update the policy template. The policy template contains resource ARN placeholders for actions that support resource-level permissions, as shown in the following image. Resource-level permissions refers to the ability to specify which resources users are allowed to perform actions on. We recommend that you use ARNs to specify your individual resources in the policy for actions that support resource-level permissions. You can replace the placeholder resource ARNs with valid resource ARNs for your use case.

   If an action does not support resource-level permissions, you must use a wildcard (*) to specify that all resources can be affected by the action. To learn which AWS services support resource-level permissions, see AWS services that work with IAM. For a list of actions in each service, and to learn which actions support resource-level permissions, see Actions, Resources, and Condition Keys for AWS Services.

   

2. (Optional) Add, modify, or remove JSON policy statements in the template. To learn more about writing JSON policies, see Creating IAM policies (console).

3. When you are done customizing the policy template, you have the following options:

   • (Optional) You can copy the JSON in the template to use separately outside of the Generated policy page. For example, if you want to use the JSON to create a policy in a different account. If the policy in your template exceeds the 6,144 character limit for JSON policies, the policy is split into multiple policies.

   • Choose Next to review and create a managed policy in the same account.

To review and create a policy

1. On the Review and create managed policy page, enter a Name and Description (optional) for the policy that you are creating.

2. (Optional) In the Summary section, you can review the permissions that will be included in the policy.

3. (Optional) Add metadata to the policy by attaching tags as key-value pairs. For more information about using tags in IAM, see Tagging IAM resources.

4. When you are finished, do one of the following:

   • You can attach the new policy directly to the role that was used to generate the policy. To do this, near the bottom of the page, select the check box next to the Attach policy to YourRoleName. Then choose Create and attach policy.

   • Otherwise, choose Create policy. You can find the policy that you created in the list of policies in the Policies navigation pane of the IAM console.

5. You can attach the policy that you created to an entity in your account. After you attach the policy, you can remove any other overly broad policies that might be attached to the entity. To learn how to attach a managed policy, see Adding IAM identity permissions (console).

Step 1: Choose or create a role for cross-account access

• On the Generate policy screen, the option to Use an existing role is pre-selected for you if a role with the required permissions exists in your account. Otherwise, choose Create and use a new service role. The new role is used to grant IAM Access Analyzer access to your CloudTrail logs in account B.

Step 2: Verify or update your Amazon S3 bucket configuration in account B

1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.

2. In the Buckets list, choose the name of the bucket where your CloudTrail trail logs are stored.

3. Choose the Permissions tab and go to the Object Ownership section.

   Use Amazon S3 Object Ownership bucket settings to control ownership of objects that you upload to your buckets. By default, when other AWS accounts upload objects to your bucket, the uploading account owns the objects. To generate a policy, the bucket owner must own all of the objects in the bucket. Depending on your ACL use case, you might need to change the Object Ownership setting for your bucket. Set Object Ownership to one of the following options.

   • Bucket owner enforced (recommended)

   • Bucket owner preferred

   Important

   To successfully generate a policy, the objects in the bucket must be owned by the bucket owner. If you choose to use Bucket owner preferred, you can only generate a policy for the time period after the object ownership change was made.

   To learn more about object ownership in Amazon S3, see Controlling ownership of objects and disabling ACLs for your bucket in the Amazon S3 User Guide.

4. Add permissions to your Amazon S3 bucket policy in account B to allow access for the role in account A.

   The following example policy allows ListBucket and GetObject for the bucket named amzn-s3-demo-bucket. It allows access if the role accessing the bucket belongs to an account in your organization and has a name that starts with AccessAnalyzerMonitorServiceRole. Using aws:PrincipalArn as a Condition in the Resource element ensures that the role can only access activity for the account if it belongs to account A. You can replace amzn-s3-demo-bucket with your bucket name, optional-prefix with an optional prefix for the bucket, and organization-id with your organization ID.

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "PolicyGenerationBucketPolicy",
         "Effect": "Allow",
         "Principal": {
           "AWS": "*"
         },
         "Action": [
           "s3:GetObject",
           "s3:ListBucket"
         ],
         "Resource": [
           "arn:aws:s3:::amzn-s3-demo-bucket",
           "arn:aws:s3:::amzn-s3-demo-bucket/optional-prefix/AWSLogs/organization-id/${aws:PrincipalAccount}/*"
         ],
         "Condition": {
           "StringEquals": {
             "aws:PrincipalOrgID": "organization-id"
           },
           "StringLike": {
             "aws:PrincipalArn": "arn:aws:iam::${aws:PrincipalAccount}:role/service-role/AccessAnalyzerMonitorServiceRole*"
           }
         }
       }
     ]
   }

5. If you encrypt your logs using AWS KMS, update your AWS KMS key policy in the account where you store the CloudTrail logs to grant IAM Access Analyzer access to use your key, as shown in the following policy example. Replace CROSS_ACCOUNT_ORG_TRAIL_FULL_ARN with the ARN for your trail and organization-id with your organization ID.

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "*"
         },
         "Action": "kms:Decrypt",
         "Resource": "*",
         "Condition": {
           "StringEquals": {
             "kms:EncryptionContext:aws:cloudtrail:arn": "CROSS_ACCOUNT_ORG_TRAIL_FULL_ARN",
             "aws:PrincipalOrgID": "organization-id"
           },
           "StringLike": {
             "kms:ViaService": [
               "access-analyzer.*.amazonaws.com",
               "s3.*.amazonaws.com"
             ],
             "aws:PrincipalArn": "arn:aws:iam::${aws:PrincipalAccount}:role/service-role/AccessAnalyzerMonitorServiceRole*"
           }
         }
       }
     ]
   }