Updates AWS managed policies #878
Conversation
WalkthroughThe recent updates to various AWS IAM policies involve the addition and modification of permissions across multiple services. Notable changes include the introduction of new permission statements for the AWS Backup Full Access policy, modifications to the AWS Backup Service Role Policy, and the creation of new policies aimed at managing compromised keys. The updates also enhance permissions for AWS services like Lambda, IVS, and others, refining access controls to improve security and operational capabilities. Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
udondan
force-pushed
the
update-aws-managed-policies
branch
4 times, most recently
from
e5dd68b
to
ecc2f69
Compare
udondan
force-pushed
the
update-aws-managed-policies
branch
3 times, most recently
from
1f93f67
to
55588a4
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range, codebase verification and nitpick comments (4)
docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (1)
24-37: Conditions for Tagging Correctly Implemented in Notebook Policy, Inconsistencies Found ElsewhereThe conditions for tagging in
AwsGlueSessionUserRestrictedNotebookPolicy.jsonare correctly implemented using "aws:PrincipalTag/owner". However, other policy files such asAwsGlueSessionUserRestrictedPolicy.jsonandAwsGlueSessionUserRestrictedServiceRole.jsonuse "${aws:userid}" instead, which may not align with the intended policy structure.
- Ensure consistent use of "aws:PrincipalTag/owner" across all policies if that's the intended condition.
- Review and update other policy files for consistency if required.
Analysis chain
Ensure conditions for tagging are correctly implemented.
The new "AllowGlueTaggingAction" statement allows tagging resources with strict conditions based on the
ownertag. This change enhances security by ensuring only authorized users can tag resources. Verify that the conditions are correctly implemented and that the necessary tags are applied to all relevant resources and principals.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the conditions for tagging are correctly implemented. # Test: Search for the usage of `AllowGlueTaggingAction`. Expect: Correct implementation of conditions. rg --type json $'AllowGlueTaggingAction'Length of output: 529
Script:
#!/bin/bash # Extract and display the condition sections for "AllowGlueTaggingAction" across relevant policy files rg --type json -A 10 '"Sid": "AllowGlueTaggingAction"' docs/source/_static/managed-policies/Length of output: 5125
docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1)
43-56: Inconsistent Tagging Conditions in "AllowGlueTaggingAction"The conditions for "AllowGlueTaggingAction" vary across different policy files. Ensure consistent implementation of conditions using
${aws:PrincipalTag/owner}if that is the intended approach:
AwsGlueSessionUserRestrictedServiceRole.jsonandAwsGlueSessionUserRestrictedPolicy.jsonuse${aws:userid}.AwsGlueSessionUserRestrictedNotebookServiceRole.jsonandAwsGlueSessionUserRestrictedNotebookPolicy.jsonuse${aws:PrincipalTag/owner}.Verify and standardize the conditions to align with the intended security model.
Analysis chain
Verify tagging conditions in "AllowGlueTaggingAction".
The new "AllowGlueTaggingAction" statement introduces tagging permissions with conditions based on the
ownertag. This ensures that only authorized users can tag resources. Verify that the conditions are correctly implemented and enforced across all relevant resources and principals.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify tagging conditions in "AllowGlueTaggingAction". # Test: Search for the usage of `AllowGlueTaggingAction`. Expect: Correct implementation of conditions. rg --type json $'AllowGlueTaggingAction'Length of output: 529
Script:
#!/bin/bash # Description: Extract and review the conditions associated with "AllowGlueTaggingAction" in relevant JSON files. # Extract the relevant sections from each JSON file where "AllowGlueTaggingAction" is defined. for file in $(rg --files-with-matches --type json "AllowGlueTaggingAction"); do echo "File: $file" rg -A 10 '"Sid": "AllowGlueTaggingAction"' "$file" echo "-------------------------" doneLength of output: 3223
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (2)
Restrict KMS Permissions to Necessary Resources
The AWSDataExchangeProviderFullAccess.json policy file contains multiple instances of broad permissions with "Resource": "". Specifically, the "KMSActions" SID allows key management operations on all KMS keys. To enhance security, consider scoping these permissions to specific resources rather than using "". This will help prevent unauthorized access to KMS keys.
- File:
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json- Lines with broad permissions: Multiple instances of
"Resource": "*"Analysis chain
Line range hint
124-131:
Review KMSActions SID.The permissions under "KMSActions" allow for key management operations. Ensure that these permissions are limited to necessary resources to prevent unauthorized key access.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the scope of KMS permissions. # Test: Search for kms permissions usage. Expect: Limited to necessary resources. rg --type json $'kms:DescribeKey'Length of output: 8338
Script:
#!/bin/bash # Description: Check for broad resource permissions in AWSDataExchangeProviderFullAccess.json. # Search for instances of "Resource": "*" in the specified policy file. rg --type json '"Resource": "*"' docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.jsonLength of output: 419
Review the scope of APIGatewayActions SID in AWSDataExchangeProviderFullAccess.json
The "APIGatewayActions" SID currently allows the "apigateway:GET" action on all resources ("Resource": "*"). This broad permission could lead to unintended exposure. Consider scoping this permission to specific resources to enhance security.
- File:
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json, Lines: 153-159Analysis chain
Line range hint
156-161:
Review APIGatewayActions SID.The "APIGatewayActions" SID allows GET requests on API Gateway. Ensure that this permission is scoped correctly to prevent unintentional exposure.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the scope of API Gateway permissions. # Test: Search for apigateway permissions usage. Expect: Scoped correctly to prevent exposure. rg --type json $'apigateway:GET'Length of output: 3461
Script:
#!/bin/bash # Extract the full context of the "apigateway:GET" permission in AWSDataExchangeProviderFullAccess.json rg -A 5 -B 5 '"apigateway:GET"' docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.jsonLength of output: 267
udondan
force-pushed
the
update-aws-managed-policies
branch
4 times, most recently
from
0894070
to
23c7398
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range, codebase verification and nitpick comments (1)
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (1)
Security Concern: Unrestricted Role Passing in
TasksPassRolePolicyThe
TasksPassRolePolicyallows theiam:PassRoleaction on all resources ("Resource": ["*"]). This can pose a security risk as it enables passing any role to ECS tasks. It is recommended to restrict this policy to specific roles necessary for the tasks to enhance security.
- File:
docs/source/_static/managed-policies/AmazonECS_FullAccess.json- Lines: 153-159
Analysis chain
Line range hint
156-164: Verify restriction and security of role passing.The
TasksPassRolePolicyallows passing roles to ECS tasks. Ensure that this is restricted to necessary roles only to maintain security.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the restriction and security of role passing in `TasksPassRolePolicy`. # Test: Check for any unintended role passing permissions. rg --type json '"TasksPassRolePolicy"'Length of output: 139
Script:
#!/bin/bash # Description: Extract detailed information about the conditions and resources in `TasksPassRolePolicy`. # Extract the full policy statement for `TasksPassRolePolicy` to verify conditions and resources. rg --type json -A 5 '"Sid": "TasksPassRolePolicy"' docs/source/_static/managed-policies/AmazonECS_FullAccess.jsonLength of output: 249
udondan
force-pushed
the
update-aws-managed-policies
branch
6 times, most recently
from
0690482
to
c42a503
Compare
| "Sid": "PermissionsToManagePCSLaunchTemplates", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ec2:DeleteLaunchTemplate", | ||
| "ec2:DeleteLaunchTemplateVersions", | ||
| "ec2:CreateLaunchTemplateVersion" | ||
| ], | ||
| "Resource": "arn:aws:ec2:*:*:launch-template/*", | ||
| "Condition": { | ||
| "Null": { | ||
| "aws:ResourceTag/AWSPCSManaged": "false" | ||
| } | ||
| } | ||
| }, |
There was a problem hiding this comment.
Refine condition to ensure explicit tag value.
The condition should ensure that the AWSPCSManaged tag is explicitly set to true to avoid unintended actions.
- "Null": {
- "aws:ResourceTag/AWSPCSManaged": "false"
- }
+ "StringEquals": {
+ "aws:ResourceTag/AWSPCSManaged": "true"
+ }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "Sid": "PermissionsToManagePCSLaunchTemplates", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:DeleteLaunchTemplate", | |
| "ec2:DeleteLaunchTemplateVersions", | |
| "ec2:CreateLaunchTemplateVersion" | |
| ], | |
| "Resource": "arn:aws:ec2:*:*:launch-template/*", | |
| "Condition": { | |
| "Null": { | |
| "aws:ResourceTag/AWSPCSManaged": "false" | |
| } | |
| } | |
| }, | |
| "Sid": "PermissionsToManagePCSLaunchTemplates", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:DeleteLaunchTemplate", | |
| "ec2:DeleteLaunchTemplateVersions", | |
| "ec2:CreateLaunchTemplateVersion" | |
| ], | |
| "Resource": "arn:aws:ec2:*:*:launch-template/*", | |
| "Condition": { | |
| "StringEquals": { | |
| "aws:ResourceTag/AWSPCSManaged": "true" | |
| } | |
| } |
| "Sid": "PermissionsToCreatePCSNetworkInterfaces", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ec2:CreateNetworkInterface" | ||
| ], | ||
| "Resource": "arn:aws:ec2:*:*:network-interface/*", | ||
| "Condition": { | ||
| "Null": { | ||
| "aws:RequestTag/AWSPCSManaged": "false" | ||
| } | ||
| } |
There was a problem hiding this comment.
Refine condition to ensure explicit tag value.
The condition should ensure that the AWSPCSManaged tag is explicitly set to true to avoid unintended actions.
- "Null": {
- "aws:RequestTag/AWSPCSManaged": "false"
- }
+ "StringEquals": {
+ "aws:RequestTag/AWSPCSManaged": "true"
+ }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "Sid": "PermissionsToCreatePCSNetworkInterfaces", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:CreateNetworkInterface" | |
| ], | |
| "Resource": "arn:aws:ec2:*:*:network-interface/*", | |
| "Condition": { | |
| "Null": { | |
| "aws:RequestTag/AWSPCSManaged": "false" | |
| } | |
| } | |
| "Sid": "PermissionsToCreatePCSNetworkInterfaces", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:CreateNetworkInterface" | |
| ], | |
| "Resource": "arn:aws:ec2:*:*:network-interface/*", | |
| "Condition": { | |
| "StringEquals": { | |
| "aws:RequestTag/AWSPCSManaged": "true" | |
| } | |
| } |
| "Sid": "PermissionsToProvisionClusterInstances", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ec2:RunInstances", | ||
| "ec2:CreateFleet" | ||
| ], | ||
| "Resource": [ | ||
| "arn:aws:ec2:*:*:instance/*" | ||
| ], | ||
| "Condition": { | ||
| "Null": { | ||
| "aws:RequestTag/AWSPCSManaged": "false" | ||
| } | ||
| } | ||
| }, |
There was a problem hiding this comment.
Refine condition to ensure explicit tag value.
The condition should ensure that the AWSPCSManaged tag is explicitly set to true to avoid unintended actions.
- "Null": {
- "aws:RequestTag/AWSPCSManaged": "false"
- }
+ "StringEquals": {
+ "aws:RequestTag/AWSPCSManaged": "true"
+ }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "Sid": "PermissionsToProvisionClusterInstances", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:RunInstances", | |
| "ec2:CreateFleet" | |
| ], | |
| "Resource": [ | |
| "arn:aws:ec2:*:*:instance/*" | |
| ], | |
| "Condition": { | |
| "Null": { | |
| "aws:RequestTag/AWSPCSManaged": "false" | |
| } | |
| } | |
| }, | |
| "Sid": "PermissionsToProvisionClusterInstances", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:RunInstances", | |
| "ec2:CreateFleet" | |
| ], | |
| "Resource": [ | |
| "arn:aws:ec2:*:*:instance/*" | |
| ], | |
| "Condition": { | |
| "StringEquals": { | |
| "aws:RequestTag/AWSPCSManaged": "true" | |
| } | |
| } |
| "Sid": "PermissionsToCreatePCSLaunchTemplates", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ec2:CreateLaunchTemplate" | ||
| ], | ||
| "Resource": "arn:aws:ec2:*:*:launch-template/*", | ||
| "Condition": { | ||
| "Null": { | ||
| "aws:RequestTag/AWSPCSManaged": "false" | ||
| } | ||
| } |
There was a problem hiding this comment.
Refine condition to ensure explicit tag value.
The condition should ensure that the AWSPCSManaged tag is explicitly set to true to avoid unintended actions.
- "Null": {
- "aws:RequestTag/AWSPCSManaged": "false"
- }
+ "StringEquals": {
+ "aws:RequestTag/AWSPCSManaged": "true"
+ }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "Sid": "PermissionsToCreatePCSLaunchTemplates", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:CreateLaunchTemplate" | |
| ], | |
| "Resource": "arn:aws:ec2:*:*:launch-template/*", | |
| "Condition": { | |
| "Null": { | |
| "aws:RequestTag/AWSPCSManaged": "false" | |
| } | |
| } | |
| "Sid": "PermissionsToCreatePCSLaunchTemplates", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:CreateLaunchTemplate" | |
| ], | |
| "Resource": "arn:aws:ec2:*:*:launch-template/*", | |
| "Condition": { | |
| "StringEquals": { | |
| "aws:RequestTag/AWSPCSManaged": "true" | |
| } | |
| } |
| "Sid": "PermissionsToManagePCSNetworkInterfaces", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ec2:DeleteNetworkInterface", | ||
| "ec2:CreateNetworkInterfacePermission" | ||
| ], | ||
| "Resource": "arn:aws:ec2:*:*:network-interface/*", | ||
| "Condition": { | ||
| "Null": { | ||
| "aws:ResourceTag/AWSPCSManaged": "false" | ||
| } | ||
| } | ||
| }, |
There was a problem hiding this comment.
Refine condition to ensure explicit tag value.
The condition should ensure that the AWSPCSManaged tag is explicitly set to true to avoid unintended actions.
- "Null": {
- "aws:ResourceTag/AWSPCSManaged": "false"
- }
+ "StringEquals": {
+ "aws:ResourceTag/AWSPCSManaged": "true"
+ }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "Sid": "PermissionsToManagePCSNetworkInterfaces", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:DeleteNetworkInterface", | |
| "ec2:CreateNetworkInterfacePermission" | |
| ], | |
| "Resource": "arn:aws:ec2:*:*:network-interface/*", | |
| "Condition": { | |
| "Null": { | |
| "aws:ResourceTag/AWSPCSManaged": "false" | |
| } | |
| } | |
| }, | |
| "Sid": "PermissionsToManagePCSNetworkInterfaces", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:DeleteNetworkInterface", | |
| "ec2:CreateNetworkInterfacePermission" | |
| ], | |
| "Resource": "arn:aws:ec2:*:*:network-interface/*", | |
| "Condition": { | |
| "StringEquals": { | |
| "aws:ResourceTag/AWSPCSManaged": "true" | |
| } | |
| } | |
| }, |
| "Sid": "PermissionsToTerminatePCSManagedInstances", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ec2:TerminateInstances" | ||
| ], | ||
| "Resource": "arn:aws:ec2:*:*:instance/*", | ||
| "Condition": { | ||
| "Null": { | ||
| "aws:ResourceTag/AWSPCSManaged": "false" | ||
| } | ||
| } | ||
| }, |
There was a problem hiding this comment.
Refine condition to ensure explicit tag value.
The condition should ensure that the AWSPCSManaged tag is explicitly set to true to avoid unintended actions.
- "Null": {
- "aws:ResourceTag/AWSPCSManaged": "false"
- }
+ "StringEquals": {
+ "aws:ResourceTag/AWSPCSManaged": "true"
+ }Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "Sid": "PermissionsToTerminatePCSManagedInstances", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:TerminateInstances" | |
| ], | |
| "Resource": "arn:aws:ec2:*:*:instance/*", | |
| "Condition": { | |
| "Null": { | |
| "aws:ResourceTag/AWSPCSManaged": "false" | |
| } | |
| } | |
| }, | |
| "Sid": "PermissionsToTerminatePCSManagedInstances", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ec2:TerminateInstances" | |
| ], | |
| "Resource": "arn:aws:ec2:*:*:instance/*", | |
| "Condition": { | |
| "StringEquals": { | |
| "aws:ResourceTag/AWSPCSManaged": "true" | |
| } | |
| } | |
| }, |
udondan
force-pushed
the
update-aws-managed-policies
branch
3 times, most recently
from
a427e98
to
0734cc4
Compare
| /** Denies access to certain actions, applied by AWS in the event that an IAM user's credentials have been compromised or exposed publicly. The policy aims to limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources. Do NOT remove this policy. Instead, please follow the instructions specified in the support case created for you regarding this event. */ | ||
| public static AWSCompromisedKeyQuarantineV3 = 'AWSCompromisedKeyQuarantineV3'; |
There was a problem hiding this comment.
Security Concern: AWSCompromisedKeyQuarantineV3
The addition of the AWSCompromisedKeyQuarantineV3 policy is correctly implemented. However, the static analysis tool flagged this line as containing a potential security issue related to a generic API key. This is likely a false positive since the policy is designed to deny access to certain actions when an IAM user's credentials are compromised, which is a security feature.
It's important to verify that no sensitive keys or credentials are hardcoded in this policy or elsewhere in the codebase.
Please ensure that no sensitive information or credentials are exposed in the policy definitions or elsewhere. If this is a false positive, you may disregard the security warning from the static analysis tool.
Tools
Gitleaks
1224-1224: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
udondan
force-pushed
the
update-aws-managed-policies
branch
2 times, most recently
from
2aa1aa3
to
4459e7c
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range, codebase verification and nitpick comments (2)
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (2)
Line range hint
94-102: Avoid using broad permissions for S3 read actions.The new statement with SID "S3ReadActions" allows read actions like s3:ListAllMyBuckets on any S3 resource (
"Resource": "*"), which seems too permissive. Consider scoping down the Resource to specific buckets or using conditions to restrict the permissions for better security.
Line range hint
156-161: Avoid using broad permissions for API Gateway actions.The new statement with SID "APIGatewayActions" allows the apigateway:GET action on any resource (
"Resource": "*"), which seems too permissive. Consider scoping down the Resource to specific API Gateway resources or using conditions to restrict the permissions for better security.
udondan
force-pushed
the
update-aws-managed-policies
branch
from
4459e7c
to
432e443
Compare
udondan
force-pushed
the
update-aws-managed-policies
branch
from
43c6b76
to
cc533e4
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
docs/source/_static/managed-policies/AmazonSNSFullAccess.json (1)
28-32: Strong security control with aws:CalledViaLast conditionThe condition block using
aws:CalledViaLastis a robust security measure. It ensures that SNS must be the final service in the call chain, preventing potential security risks from service-to-service delegation.Consider documenting this security design decision in your architecture documentation to help other teams understand the importance of using
aws:CalledViaLastoveraws:CalledViafor strict service boundary enforcement.docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (1)
66-78: LGTM: Well-implemented tag-based access controlGood use of attribute-based access control (ABAC) using the
AmazonConnectCampaignsEnabledtag.Consider documenting the tag requirement in the repository's README or documentation to ensure resources are properly tagged for Wisdom integration.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (1)
Line range hint
156-168: Security concern: Constrain IAM role patterns for ECS tasks.The current policy allows passing any IAM role to ECS tasks. This violates the principle of least privilege.
Consider constraining the roles that can be passed using a resource pattern:
"Resource": [ - "*" + "arn:aws:iam::*:role/ecs-task-*" ],
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
lib/generated/aws-managed-policies/cdk-iam-floyd.tsis excluded by!**/generated/**lib/generated/aws-managed-policies/iam-floyd.tsis excluded by!**/generated/**
📒 Files selected for processing (82)
docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSBackupFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json(2 hunks)docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json(1 hunks)docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json(11 hunks)docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json(2 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json(2 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json(2 hunks)docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json(25 hunks)docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWS_ConfigRole.json(14 hunks)docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonBedrockReadOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json(2 hunks)docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json(1 hunks)docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json(1 hunks)docs/source/_static/managed-policies/AmazonECS_FullAccess.json(8 hunks)docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSServicePolicy.json(3 hunks)docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonQDeveloperAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonQFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json(1 hunks)
⛔ Files not processed due to max files limit (17)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json
- docs/source/_static/managed-policies/CloudWatchInternetMonitorFullAccess.json
- docs/source/_static/managed-policies/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.json
- docs/source/_static/managed-policies/CloudWatchSyntheticsFullAccess.json
- docs/source/_static/managed-policies/ElasticLoadBalancingFullAccess.json
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/ReadOnlyAccess.json
- docs/source/_static/managed-policies/ResourceGroupsTaggingAPITagUntagSupportedResources.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/SecurityAudit.json
- docs/source/_static/managed-policies/ViewOnlyAccess.json
- docs/source/_static/managed-policies/index.json
💤 Files with no reviewable changes (3)
- docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json
🚧 Files skipped from review as they are similar to previous changes (69)
- docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSBackupFullAccess.json
- docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json
- docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json
- docs/source/_static/managed-policies/AWSDataSyncFullAccess.json
- docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json
- docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json
- docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json
- docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json
- docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json
- docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSServicePolicy.json
- docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonQDeveloperAccess.json
- docs/source/_static/managed-policies/AmazonQFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
🔇 Additional comments (71)
docs/source/_static/managed-policies/AmazonSNSFullAccess.json (2)
5-9: LGTM: Simplified action format
The change from array to string format for single action is a valid simplification that maintains the same permissions.
23-23: Verify spend limit override permission consistency
The SetTextMessageSpendLimitOverride permission is a sensitive operation that affects billing controls.
✅ Verification successful
Spend limit override permission follows least privilege principle
The verification shows that SetTextMessageSpendLimitOverride is consistently implemented across policies following the principle of least privilege:
- Only present in
AmazonSNSFullAccess.jsonas expected for full access - Read-only policies (
ReadOnlyAccess.json,AmazonSNSReadOnlyAccess.json) only includeDescribeSpendLimitspermission - No other policies contain spend limit override capabilities
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for spend limit override permissions across policies
# Expected: This permission should be consistently controlled across SMS-related policies
echo "Checking for spend limit override permissions:"
rg -g '*.json' 'SetTextMessageSpendLimitOverride' -B 5 -A 5
echo -e "\nChecking for other spend limit related permissions:"
rg -g '*.json' 'SpendLimit' -B 5 -A 5
Length of output: 4878
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (3)
5-11: LGTM: Appropriate permissions for list operation
The new statement follows AWS best practices by allowing the read-only ListCampaigns action with a wildcard resource, which is standard for list operations.
24-65: Well-structured EventBridge permissions with proper security controls
Excellent implementation of security best practices:
- Account-level isolation using
aws:ResourceAccountcondition - Specific resource pattern
ConnectCampaignsRule* - Additional
ManagedBycondition ensuring only Connect Campaigns service can manage these rules
13-22: Verify the new Connect permissions are required
The additional permissions look appropriate but should be verified:
DescribeContactFlow: Required for reading contact flow configurationsSendOutboundEmail: Required for outbound campaign communications
✅ Verification successful
Let me generate additional verification scripts to check the broader context and usage patterns.
Based on the search results, I can now generate the final response:
New Connect permissions are properly scoped and required
The additional permissions are verified to be appropriate for Amazon Connect Campaigns:
DescribeContactFlowis needed alongside other Connect permissions in the same policySendOutboundEmailis specifically required for campaign communications and is the only email-related Connect permission in the policy- Both permissions are properly scoped to Connect instance ARN pattern
arn:aws:connect:*:*:instance/*
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify if these permissions are consistently used in other Connect campaign policies
rg -A 5 "connect:DescribeContactFlow|connect:SendOutboundEmail" --type json
Length of output: 1668
Script:
#!/bin/bash
# Search for any Connect campaign related configurations or documentation
rg -i "campaign|outbound" --type json -A 5 docs/source/_static/managed-policies/
# Look for any other Connect email related permissions
rg "connect:.*(Email|Mail)" --type json
Length of output: 58994
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (9)
67-70: LGTM for ECS actions
The ECS actions (CreateService, CreateCluster, RegisterTaskDefinition) are appropriate additions as they prevent the creation of new container resources that could be used for malicious purposes.
Note: A previous review comment about ecr:GetAuthorizationToken is still valid. This read-only action might be useful during incident investigation.
71-75: LGTM for Bedrock actions
The addition of Bedrock actions is appropriate as they prevent:
- Creation of potentially costly model invocation jobs
- Unauthorized model access and inference
- Creation of new model agreements and entitlements
76-79: LGTM for S3 create/modify actions, reconsider read actions
The previous review comment about S3 read actions remains valid. While denying CreateBucket and PutBucketCors is appropriate, denying GetObject and ListBucket might hinder incident investigation.
80-81: LGTM for SageMaker actions
The SageMaker actions appropriately prevent:
- Creation of new endpoint configurations that could be used for unauthorized model deployment
- Initiation of processing jobs that could be used for data exfiltration or resource abuse
82-85: LGTM for STS actions, reconsider SES actions
The previous review comment about SES read-only actions remains valid. While the STS actions appropriately prevent credential generation, denying SES read actions might hinder incident investigation.
86-89: LGTM for application service actions
The additions appropriately prevent resource creation across multiple services:
- Amplify deployments and environments
- CodeBuild projects
- Glue jobs
These restrictions help prevent resource abuse and potential privilege escalation.
90-92: LGTM for IAM destructive actions, reconsider ListUsers
The previous review comment about iam:ListUsers remains valid. While denying destructive actions (DeleteRole, DeleteAccessKey) is appropriate, denying the read-only ListUsers action might hinder incident response.
93-95: LGTM for MediaPackage action, reconsider Lambda and SNS actions
Previous review comments about Lambda and SNS read-only actions remain valid. While denying mediapackagev2:CreateChannel is appropriate, denying read-only actions might hinder incident investigation.
66-95: 🛠️ Refactor suggestion
Consider additional commonly abused actions
The previous suggestion about adding commonly abused actions remains valid. Consider adding actions that could be used for account takeover or resource destruction:
cloudformation:CreateStackiam:CreateServiceLinkedRoleorganizations:LeaveOrganizationorganizations:DeleteOrganizationkms:ScheduleKeyDeletionroute53:DeleteHostedZone
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (8)
Line range hint 128-137: LGTM! Well-scoped SSM permissions.
The statement properly constrains access to only ECS-related parameters and provides read-only access.
Line range hint 138-155: LGTM! Well-constrained cleanup permissions.
The statement properly restricts deletions to resources tagged with ECS-specific CloudFormation stacks.
169-180: LGTM! Well-defined infrastructure role permissions.
The statement properly constrains the role and service principal.
Line range hint 181-197: LGTM! Properly scoped instance role permissions.
The statement correctly constrains role patterns and service principals.
Line range hint 198-213: LGTM! Well-defined autoscaling role permissions.
The statement properly constrains the roles and service principals.
Line range hint 231-247: LGTM! Well-constrained tagging permissions.
The statement properly restricts tagging to resource creation operations.
Line range hint 214-230: LGTM! Verify the completeness of service principals.
The statement properly constrains service-linked role creation. However, let's verify if any ECS-related services are missing.
#!/bin/bash
# Search for other ECS-related service-linked roles in AWS documentation
rg -l "ecs.*\.amazonaws\.com"Line range hint 5-127: Consider adding resource constraints for critical services.
While the broad permissions are necessary for ECS management, consider adding resource constraints for critical services where possible, especially for destructive actions like cloudformation:DeleteStack and ec2:DeleteVpc.
Let's check if other AWS managed policies implement similar resource constraints:
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (5)
Line range hint 120-125: LGTM: Improved security through explicit role ARN
The change improves security by explicitly specifying the service-linked role ARN instead of using a wildcard pattern, following the principle of least privilege.
276-297: LGTM: Well-structured resource group permissions
The statement implements proper access controls with:
- Resource prefix restriction to
SystemsManagerForSAP-* - Multi-layered tag validation
- Explicit tag key restrictions
299-316: LGTM: Secure EC2 instance tagging permissions
The statement implements proper access controls:
- Only allows tagging SSM-managed instances
- Restricts tag keys to service-specific prefix
318-332: Skip: Issue already identified in previous review
The concerns about over-permissive EBS volume tagging were already raised in the previous review and remain valid.
334-350: Skip: Issue already identified in previous review
The concerns about broad application tagging permissions on EBS volumes were already raised in the previous review and remain valid.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (6)
96-97: LGTM: Read-only Profile Object Types permissions
The added permissions are read-only and properly scoped to Connect domain object types.
149-163: LGTM: Comprehensive Wisdom message template permissions
The new Wisdom message template permissions provide complete CRUD operations and are properly restricted to resources tagged with "AmazonConnectEnabled".
195-208: LGTM: Well-scoped Customer Profiles segmentation permissions
The new segmentation permissions are properly scoped to Connect domain segment definitions and follow a logical grouping of related operations.
259-284: LGTM: Secure Chime SDK Voice Connector permissions
The Voice Connector permissions are well-structured with:
- Proper resource tagging for Get operations
- Account-level restrictions
- Minimal required permissions
286-338: Verify the SES configuration set naming convention
The SES permissions are well-structured with proper account-level restrictions. However, the hardcoded configuration set name configuration-set-for-connect-DO-NOT-DELETE warrants verification.
#!/bin/bash
# Check for consistent naming convention of SES configuration sets
rg -l "configuration-set-for-connect" --type json
# Check for any documentation about this naming convention
rg -l "DO-NOT-DELETE" --type md80-87: LGTM: Customer Profiles permissions are properly scoped
The new Customer Profiles permissions are appropriately scoped to Connect domains and follow the principle of least privilege.
✅ Verification successful
LGTM: Customer Profiles permissions are properly scoped and consistent with other policies
The new Customer Profiles permissions in the service-linked role policy are:
- Properly scoped to
arn:aws:profile:*:*:domains/amazon-connect-* - Consistent with permissions found in other AWS managed policies (AmazonConnect_FullAccess, SecurityAudit)
- Follow least privilege by only granting read and estimation operations needed for Connect integration
- Organized into logical permission groups with clear Sid statements
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that these Customer Profiles permissions are used in Connect integration
rg -l "profile:(List|Get|Create|Batch).*Profile" --type json
Length of output: 160
Script:
#!/bin/bash
# Search for any references to Customer Profiles in json files
rg "profile[\":]" --type json -A 5 -B 5
# Search for Customer Profiles related documentation or references
rg -i "customer profiles?" --type md --type txt -A 2 -B 2
Length of output: 21894
docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json (4)
8-11: LGTM: CloudTrail permissions are properly scoped
The addition of GetServiceLinkedChannel permission complements the existing CreateServiceLinkedChannel and maintains proper resource-level restrictions to the specific Resource Explorer channel.
16-16: LGTM: Simplified API Gateway permission syntax
The change from an array to a single string is a valid simplification since there's only one action.
441-441: Duplicate comment: Broad resource access concern
Referring to the previous review comment about the broad resource access with "Resource": "*". The concern about violating the principle of least privilege remains valid.
Line range hint 28-439: Verify the necessity of new list permissions
The policy has been significantly expanded to include list operations across many AWS services. While this aligns with Resource Explorer's purpose of discovering and exploring resources, some newly added permissions might not be necessary.
Consider verifying if all these new permissions are actually required for Resource Explorer's functionality:
- New service permissions (e.g.,
airflow,appflow,appmesh) - New resource types within existing services (e.g., additional
guarddutyandsagemakerresources)
Let's analyze the usage of these permissions:
✅ Verification successful
Based on the search results, I can now generate the final response:
The new list permissions are justified for Resource Explorer's functionality
The added list permissions are necessary and appropriate for AWS Resource Explorer's core functionality of discovering and exploring resources across AWS services. This is evidenced by:
-
These permissions are consistently present in other AWS service role policies that need broad resource discovery capabilities:
- AWS Config Service Role Policy
- Security Audit policy
- Read Only Access policy
-
The permissions follow AWS's principle of least privilege by:
- Only including read-only "List" and "Describe" operations
- Being limited to resource discovery operations
- Matching Resource Explorer's documented purpose of discovering and exploring resources across services
-
The permissions are actively used in production AWS managed policies for similar resource discovery use cases, as shown in multiple policy files like
SecurityAudit.json,ReadOnlyAccess.json, andAWS_ConfigRole.json
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if these permissions are documented in Resource Explorer's documentation
echo "Searching for documentation of required permissions..."
rg -i "required.*(permission|policy)" README.md docs/
# Check for actual resource types being listed
echo "Checking for actual usage of new resource types..."
rg -A 5 "ListEnvironments|ListFlows|ListMeshes" # Sample of new permissions
Length of output: 51075
docs/source/_static/managed-policies/AWS_ConfigRole.json (13)
32-43: AOSS permissions align with AWS Config requirements
The added Amazon OpenSearch Service (AOSS) permissions are appropriate for AWS Config to discover and evaluate AOSS resources. The permissions are read-only and follow the principle of least privilege.
89-89: AppStream permission follows AWS Config patterns
The DescribeAppBlockBuilders permission is consistent with other AppStream descriptive permissions in the policy and is required for AWS Config to evaluate AppStream resources.
185-189: CloudTrail permissions maintain consistency
The added CloudTrail permissions for channels follow the existing pattern of read-only access and are necessary for AWS Config to evaluate CloudTrail channel configurations.
568-574: Glue permissions follow least privilege principle
The added Glue permissions (GetTrigger, ListTriggers) are appropriately scoped for AWS Config to evaluate Glue trigger configurations.
Line range hint 659-669: ImageBuilder lifecycle policy permissions are appropriate
The added ImageBuilder permissions for lifecycle policies maintain the read-only access pattern and are required for AWS Config to evaluate ImageBuilder lifecycle configurations.
Line range hint 676-693: IoT permissions maintain security posture
The added IoT permissions for billing groups and related resources follow the existing pattern of read-only access and are necessary for AWS Config's resource evaluation capabilities.
769-784: IVS permissions follow AWS Config patterns
The added IVS (Interactive Video Service) permissions are appropriately scoped to read-only operations and are required for AWS Config to evaluate IVS resources like encoder configurations and playback restriction policies.
905-911: MediaConnect permissions maintain least privilege
The added MediaConnect permissions for bridges and gateways are consistent with AWS Config's need to discover and evaluate MediaConnect resources.
917-926: MediaTailor permissions follow service patterns
The added MediaTailor permissions for channels, sources, and related resources maintain the read-only access pattern required for AWS Config evaluation.
970-971: Omics workflow permissions are appropriate
The added Omics permissions for workflows (GetWorkflow, ListWorkflows) follow the least privilege principle and are necessary for AWS Config resource evaluation.
1256-1257: Scheduler permissions maintain consistency
The added Scheduler permissions (GetSchedule, ListSchedules) are appropriately scoped for AWS Config to evaluate Scheduler resources.
1308-1308: SSM SAP tagging permission follows patterns
The added SSM SAP permission for listing tags is consistent with other services' tag listing permissions in the policy.
Line range hint 1-1394: Overall policy changes maintain security best practices
The updates to the AWS Config Role policy:
- Maintain the principle of least privilege by only adding read-only permissions
- Follow consistent patterns for resource discovery and evaluation
- Support AWS Config's ability to assess configurations across new AWS services and features
The changes are well-structured and appropriate for AWS Config's service role.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (10)
32-43: LGTM: AOSS permissions follow least privilege principle
The added Amazon OpenSearch Serverless permissions are appropriately scoped to read-only operations necessary for AWS Config to monitor AOSS resources.
88-88: LGTM: AppStream permission is properly scoped
The added DescribeAppBlockBuilders permission aligns with existing AppStream read-only permissions.
135-136: LGTM: Backup permissions are appropriately scoped
The added AWS Backup permissions for restore testing features maintain read-only access pattern.
Also applies to: 143-144
566-566: LGTM: Glue permissions follow established patterns
The added trigger-related permissions maintain read-only access consistent with existing Glue permissions.
Also applies to: 572-572
767-769: LGTM: IVS permissions maintain least privilege
The added IVS permissions are properly scoped to read-only operations for new IVS features.
Also applies to: 771-772, 775-777, 779-780
903-903: LGTM: MediaConnect permissions are properly scoped
The added bridge and gateway permissions maintain read-only access pattern.
Also applies to: 905-906, 908-908
915-918: LGTM: MediaTailor permissions follow least privilege
The added MediaTailor permissions maintain read-only access for new MediaTailor features.
Also applies to: 920-921, 923-924
968-969: LGTM: Omics permissions are appropriately scoped
The added workflow permissions maintain read-only access pattern.
1254-1255: LGTM: Scheduler permissions follow least privilege
The added schedule permissions maintain read-only access pattern.
184-184: Fix case inconsistency in CloudTrail service name
The service name has inconsistent casing: cloudTrail vs cloudtrail.
Also applies to: 188-188
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (11)
87-88: LGTM: Account service permissions are appropriate for support role
The added permissions account:getRegionOptStatus and account:listRegions are read-only and necessary for AWS Support to help troubleshoot region-related issues.
365-386: Review extensive Bedrock permissions
The policy adds 22 new read-only permissions for AWS Bedrock service. While these are read-only operations, they provide broad access to AI/ML models, agents, and knowledge bases.
Consider:
- Limiting access to only essential Bedrock operations needed for support
- Evaluating if all these permissions are necessary for support scenarios
- Potential data privacy implications when accessing AI model configurations
1061-1061: Review expanded EC2 permissions
New EC2 permissions focus on snapshot management and IPAM functionality. While read-only, they provide broad access to network and IP management configurations.
Consider:
- Evaluating if all IPAM-related permissions are necessary
- Potential network security implications of broad IPAM access
- Whether snapshot tier status access is required for support scenarios
Also applies to: 1107-1107, 1136-1148
1199-1200: LGTM: EKS pod identity permissions are appropriate
The added EKS permissions for pod identity operations are read-only and necessary for supporting EKS pod identity features.
2357-2362: LGTM: OSIS permissions are appropriate
The added OpenSearch Ingestion Service (OSIS) permissions are read-only and necessary for pipeline management support.
2672-2678: LGTM: Route53 Profiles permissions are appropriate
The added Route53 Profiles permissions are read-only and necessary for DNS profile management support.
2929-2936: Review SecurityHub configuration access
New SecurityHub permissions provide access to organization-wide security configurations and policies.
Consider:
- Evaluating if organization-level security configuration access is necessary
- Potential security implications of broad policy access
- Whether finding aggregator access is required for support scenarios
3432-3435: LGTM: WorkSpaces permissions are appropriate
The added WorkSpaces permissions for application associations and pools are read-only and necessary for workspace management support.
3447-3453: LGTM: X-Ray permissions are appropriate
The added X-Ray permissions are read-only and necessary for distributed tracing support.
828-844: Verify necessity of Deadline service permissions
The policy adds multiple list operations for AWS Deadline service. These permissions seem excessive for a support role.
✅ Verification successful
Deadline list permissions are appropriate for AWS Support role
The list permissions in AWSSupportServiceRolePolicy are consistent with AWS's read-only access patterns, as evidenced by:
- These same list operations are present in the ReadOnlyAccess policy, indicating they are standard read-only permissions
- The permissions are limited to read-only list operations, without any modify/create/delete actions
- Support roles typically need broad read access to effectively troubleshoot and assist customers
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if Deadline permissions are commonly used in support
echo "Searching for Deadline support documentation references:"
rg -i "deadline.*support.*troubleshoot" --type md
Length of output: 174
Script:
#!/bin/bash
# Let's try a broader search to understand the context of Deadline permissions
# Check for any Deadline-related documentation
echo "Searching for Deadline documentation:"
rg -i "deadline" --type md
# Check for any AWS Support role policy documentation
echo -e "\nSearching for AWS Support role policy documentation:"
rg -i "support.*role.*policy|support.*policy" --type md
# Look for any IAM policy files that might reference Deadline
echo -e "\nSearching for Deadline in IAM policies:"
fd -e json -x grep -l "deadline:" {}
Length of output: 1042
Script:
#!/bin/bash
# Let's analyze the Deadline-related policies to understand the permission patterns
# Check the WorkerHost policy for comparison
echo "Checking WorkerHost policy Deadline permissions:"
cat ./docs/source/_static/managed-policies/AWSDeadlineCloud-WorkerHost.json | jq -r '.Statement[].Action[]' | grep -i "deadline:" || true
# Check the UserAccess policies for comparison
echo -e "\nChecking UserAccess policies Deadline permissions:"
cat ./docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccess*.json | jq -r '.Statement[].Action[]' | grep -i "deadline:" | sort -u || true
# Check ReadOnlyAccess policy for comparison
echo -e "\nChecking ReadOnlyAccess policy Deadline permissions:"
cat ./docs/source/_static/managed-policies/ReadOnlyAccess.json | jq -r '.Statement[].Action[]' | grep -i "deadline:" || true
Length of output: 3920
117-147: Verify necessity of extensive AOSS and AppConfig permissions
The policy adds numerous read-only permissions for Amazon OpenSearch Serverless (AOSS) and AppConfig services. While these are read-only permissions, they provide broad access to configuration and security settings.
✅ Verification successful
AOSS and AppConfig permissions are necessary for AWS Support service role
Based on the evidence from the changelog entries and policy content:
- AOSS (Amazon OpenSearch Serverless) permissions were added in v0.459.0 and expanded in v0.601.0 as part of AWS services that Support needs to access for troubleshooting
- AppConfig permissions were added across multiple versions (v0.302.0, v0.404.0) and are consistently maintained for Support service functionality
- These read-only permissions are part of the standard AWS Support service role policy that enables AWS Support to assist with customer issues across various AWS services
- The permissions follow the principle of least privilege by only allowing read operations needed for troubleshooting
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if these services are commonly used in support scenarios
# Look for support documentation mentioning AOSS and AppConfig troubleshooting
echo "Searching for AOSS support documentation references:"
rg -i "opensearch serverless.*troubleshoot" --type md
echo "Searching for AppConfig support documentation references:"
rg -i "appconfig.*troubleshoot" --type md
Length of output: 339
Script:
#!/bin/bash
# Let's try a broader search to understand the context of these permissions
# Check for any AOSS related documentation or references
echo "Searching for OpenSearch Serverless mentions:"
rg -i "opensearch serverless" --type md -A 2
# Check for AppConfig related documentation or references
echo "Searching for AppConfig mentions:"
rg -i "appconfig" --type md -A 2
# Check if this is part of a broader AWS Support role policy pattern
echo "Checking other AWS Support related policies:"
fd ".*Policy\.json" docs/source/_static/managed-policies/ --exec grep -l "AWSSupport"
# Look for any related policy documentation
echo "Searching for policy documentation:"
rg "AWSSupportServiceRolePolicy" --type md
Length of output: 1963
Script:
#!/bin/bash
# Let's examine the AWS Support service role policy in detail and compare with previous versions
# Check the content of the current AWSSupportServiceRolePolicy
echo "Current AWSSupportServiceRolePolicy content:"
cat docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json
# Look for any recent changes in changelogs related to AOSS or AppConfig in support policies
echo "Checking recent changelog entries for support-related changes:"
rg -i "support.*role|aoss|appconfig" CHANGELOG/ -A 2
# Check if these permissions are part of standard AWS Support patterns
echo "Checking other support-related policies:"
cat docs/source/_static/managed-policies/AWSElasticDisasterRecoveryLaunchActionsPolicy.json
Length of output: 153959
udondan
force-pushed
the
update-aws-managed-policies
branch
from
cc533e4
to
a9f5565
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (1)
66-78: LGTM: Well-implemented tag-based access control for WisdomThe statement implements proper tag-based access control for Wisdom template operations. Consider documenting the requirement for the
AmazonConnectCampaignsEnabledtag in the repository's documentation.Would you like me to help create documentation for the tag requirement?
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (1)
195-208: LGTM: Well-structured segmentation permissionsThe new segmentation permissions are properly scoped and follow a clear pattern for CRUD operations.
Consider implementing appropriate rate limiting and monitoring for segment operations, especially for
CreateSegmentSnapshot, as segment operations can be resource-intensive on large datasets.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
lib/generated/aws-managed-policies/cdk-iam-floyd.tsis excluded by!**/generated/**lib/generated/aws-managed-policies/iam-floyd.tsis excluded by!**/generated/**
📒 Files selected for processing (82)
docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSBackupFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json(2 hunks)docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json(1 hunks)docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json(11 hunks)docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json(2 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json(2 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json(2 hunks)docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json(25 hunks)docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWS_ConfigRole.json(14 hunks)docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonBedrockReadOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json(2 hunks)docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json(1 hunks)docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json(1 hunks)docs/source/_static/managed-policies/AmazonECS_FullAccess.json(8 hunks)docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSComputePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSServicePolicy.json(3 hunks)docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonQDeveloperAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonQFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json(1 hunks)
⛔ Files not processed due to max files limit (19)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json
- docs/source/_static/managed-policies/CloudWatchInternetMonitorFullAccess.json
- docs/source/_static/managed-policies/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.json
- docs/source/_static/managed-policies/CloudWatchSyntheticsFullAccess.json
- docs/source/_static/managed-policies/ElasticLoadBalancingFullAccess.json
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/ReadOnlyAccess.json
- docs/source/_static/managed-policies/ResourceGroupsTaggingAPITagUntagSupportedResources.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/SecurityAudit.json
- docs/source/_static/managed-policies/ViewOnlyAccess.json
- docs/source/_static/managed-policies/index.json
💤 Files with no reviewable changes (3)
- docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json
🚧 Files skipped from review as they are similar to previous changes (65)
- docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSBackupFullAccess.json
- docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json
- docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json
- docs/source/_static/managed-policies/AWSDataSyncFullAccess.json
- docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json
- docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json
- docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json
- docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json
- docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json
- docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSServicePolicy.json
- docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonQDeveloperAccess.json
- docs/source/_static/managed-policies/AmazonQFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json
🔇 Additional comments (82)
docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json (1)
5-5: LGTM: Clear and descriptive Statement ID
The addition of a Statement ID improves policy organization and tracking.
docs/source/_static/managed-policies/AmazonSNSFullAccess.json (2)
5-9: LGTM: Format change maintains functionality.
The change from array to string format for the sns:* action is valid and maintains the same permissions.
10-32: Verify the necessity of duplicated SMS voice permissions.
While the new statement is well-structured with proper security controls (using aws:CalledViaLast condition), these SMS voice permissions appear in other policies as previously identified.
Let's verify if any new policies have been added with these permissions since the last review:
#!/bin/bash
# Description: Check for any new policies with SMS voice permissions
# Expected: Compare with previous findings to identify new additions
# Search for policies containing SMS voice permissions
rg --json -g '*.json' 'sms-voice:' | \
jq -r 'select(.type == "match") | .data.path.text' | \
sort -udocs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (3)
5-11: LGTM: Appropriate permissions for listing campaigns
The new statement correctly grants read-only access to list campaigns, following AWS best practices for service-linked roles.
24-65: LGTM: Well-structured EventBridge permissions with appropriate safeguards
The EventBridge permissions are properly scoped with:
- Resource patterns limited to
ConnectCampaignsRule* - Account-level conditions preventing cross-account access
- Service principal condition ensuring only Connect Campaigns service can manage rules
13-22: Verify the requirement for SendOutboundEmail permission
The statement is well-structured with appropriate resource constraints. However, since SendOutboundEmail is a powerful write action, please verify that this permission is essential for the Connect Campaigns service functionality.
✅ Verification successful
SendOutboundEmail permission is part of AWS-managed policy update
The SendOutboundEmail permission was added as part of an official AWS-managed policy update for the Amazon Connect Campaigns service-linked role. This permission was introduced alongside other campaign-related capabilities including EventBridge rules management and Wisdom integration, indicating it's a required permission for the service's functionality.
Since this is an AWS-managed policy specifically designed for the Connect Campaigns service, and the permission was added through an automated update, we can be confident that this permission is essential for the service to function properly.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any documentation or code that indicates why SendOutboundEmail is needed
rg -i "SendOutboundEmail" --type md
Length of output: 35
Script:
#!/bin/bash
# Let's broaden the search to include all file types and look for any references to SendOutboundEmail
rg -i "SendOutboundEmail"
# Also search for outbound email related terms in markdown and JSON files to understand the context
rg -i "outbound.?email" --type md --type json -A 3 -B 3
Length of output: 1031
Script:
#!/bin/bash
# Let's check the git history of this file to understand when and why SendOutboundEmail was added
git log -p docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json
# Also search for any documentation about campaigns or outbound functionality
rg -i "campaign.*outbound|outbound.*campaign" --type md --type txt
Length of output: 3894
docs/source/_static/managed-policies/AmazonEKSComputePolicy.json (6)
1-3: LGTM: Policy structure and version are correct
The policy follows AWS best practices with the correct version string.
16-28: LGTM: Strong security controls for launch template usage
The policy correctly restricts launch template usage to resources tagged with matching cluster names, preventing cross-cluster template misuse.
55-68: LGTM: Well-constrained tag creation permissions
The policy correctly restricts tag creation to specific EC2 actions, preventing unauthorized tagging of resources.
69-86: LGTM: IAM role permissions are properly scoped
The policy correctly restricts role operations to EKS compute instance profiles and limits PassRole to the EC2 service.
Let's verify the instance profile naming pattern consistency:
#!/bin/bash
# Search for eks-compute instance profile patterns in other policies
rg "arn:aws:iam::.+:instance-profile/eks-compute-" docs/source/_static/managed-policies/29-54: Consider using ForAnyValue instead of ForAllValues for tag keys
The current ForAllValues condition requires all specified tag keys to be present, which might be too restrictive. Consider using ForAnyValue if you want to allow the presence of additional tags beyond the required ones.
Let's check if other EKS policies use similar tag conditions:
#!/bin/bash
# Search for ForAllValues vs ForAnyValue usage in tag conditions
rg -B 2 -A 2 "For(All|Any)Values:StringLike.*aws:TagKeys" docs/source/_static/managed-policies/4-15: LGTM: EC2 instance creation permissions are well-scoped
The permissions follow the principle of least privilege by limiting actions to specific resource types needed for EC2 instance creation.
Let's verify if these ARN patterns align with other EKS policies in the codebase:
✅ Verification successful
LGTM: EC2 instance creation permissions are well-scoped and consistent with other EKS policies
The CreateFleet and RunInstances permissions in AmazonEKSComputePolicy are properly scoped to specific resource types (images, security groups, subnets) and include appropriate conditions. This matches the pattern seen in other EKS-related policies like AmazonEKSLocalOutpostServiceRolePolicy and follows AWS best practices for EKS node management.
The policy also properly restricts launch template usage with the condition aws:ResourceTag/eks:eks-cluster-name, ensuring templates can only be used with their designated clusters.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for similar EC2 resource ARN patterns in other EKS policies
rg -A 2 "arn:aws:ec2:.+:(image|security-group|subnet)" docs/source/_static/managed-policies/
Length of output: 97
Script:
#!/bin/bash
# Let's try a broader search for EC2 ARN patterns in policy files
rg -A 3 "arn:aws:ec2:" docs/source/_static/managed-policies/
# Also search for other policy files that might contain EC2 permissions
fd ".*Policy\.json" docs/source/_static/managed-policies/
Length of output: 316482
Script:
#!/bin/bash
# Let's search for similar EC2 instance creation permissions in EKS policies
rg -A 5 "CreateFleet|RunInstances" docs/source/_static/managed-policies/Amazon(EKS|ECS|EC2).*\.json
Length of output: 236
Script:
#!/bin/bash
# Let's search for similar EC2 instance creation permissions in EKS policies, fixing the regex
rg -A 5 "CreateFleet|RunInstances" "docs/source/_static/managed-policies/AmazonEKS.*\.json" "docs/source/_static/managed-policies/AmazonECS.*\.json" "docs/source/_static/managed-policies/AmazonEC2.*\.json"
Length of output: 492
Script:
#!/bin/bash
# First find the exact policy files we want to examine
fd "Amazon(EKS|ECS|EC2).*\.json" docs/source/_static/managed-policies/
# Then search for EC2 instance creation permissions
rg -A 5 "CreateFleet|RunInstances" docs/source/_static/managed-policies/
Length of output: 81164
docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json (2)
35-35: LGTM: Addition of EC2 instance topology permission.
The new ec2:DescribeInstanceTopology action aligns well with the existing EC2 describe permissions and follows the principle of least privilege by being a read-only action.
35-35: Verify EC2 API compatibility.
Let's ensure this EC2 API action is publicly available and properly documented.
✅ Verification successful
Let me gather more context about this API action by checking the changelog entry and any related discussions.
Based on the search results, I can now provide a final response:
The EC2 API action ec2:DescribeInstanceTopology is a newly added action as of v0.601.0.
This is confirmed by:
- It appears in the CHANGELOG/v0.601.0.md as a new action
- It's properly documented in the codebase's policy statements (lib/generated/policy-statements/ec2.ts)
- It's being used in a managed policy (AmazonEKSClusterPolicy) which suggests it's a valid and publicly available API
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the EC2 API action exists in public documentation
# Expected: Find references to this API action in AWS documentation or other policies
# Search for other policies using this action
rg -l "ec2:DescribeInstanceTopology" --type json
# Search for any documentation or references
rg "DescribeInstanceTopology" --type md
Length of output: 206
Script:
#!/bin/bash
# Check the full context of the changelog entry
cat CHANGELOG/v0.601.0.md
# Look for any related discussions or PRs that introduced this change
rg -B 3 -A 3 "DescribeInstanceTopology"
Length of output: 71512
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (4)
71-75: LGTM for Bedrock and SageMaker actions!
The additions effectively prevent:
- Resource abuse through Bedrock model invocations
- Unauthorized ML endpoint creation and processing jobs
Also applies to: 80-81
84-85: LGTM for STS actions!
The additions of GetSessionToken and GetFederationToken are appropriate as they prevent the generation of new credentials that could be used to maintain persistent access.
86-89: LGTM for resource creation prevention!
The additions appropriately prevent the creation of new resources across:
- Amplify deployments and environments
- CodeBuild projects
- Glue jobs
- MediaPackage channels
Also applies to: 95-95
66-66: LGTM for SavingsPlans action!
Adding CreateSavingsPlan is appropriate as it prevents financial abuse through unauthorized long-term commitments.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (8)
Line range hint 27-47: LGTM! Well-structured job permissions with proper conditions.
The statement effectively restricts job operations to specific types using conditions, which is a good security practice.
Line range hint 49-93: LGTM! Well-implemented S3 permissions with proper safeguards.
The S3 permissions are well-structured with:
- Service principal verification using aws:CalledVia
- Resource pattern restrictions for aws-data-exchange buckets
- Tag-based access control
Line range hint 94-102: LGTM! Necessary S3 bucket discovery permissions.
These broad S3 list permissions are required for bucket discovery and cannot be restricted further.
Line range hint 104-122: LGTM! Required Marketplace integration permissions.
The permissions appropriately cover all necessary Marketplace operations for Data Exchange providers.
Line range hint 124-132: LGTM! Properly restricted KMS permissions.
The KMS permissions are appropriately limited to key discovery operations only.
Line range hint 134-154: LGTM! Well-structured Redshift permissions with proper conditions.
The permissions effectively manage Redshift data shares with:
- Conditional authorization for ADX consumer
- Limited describe permissions
Line range hint 156-162: Consider restricting API Gateway access to specific APIs.
While GET-only permission is good, consider if access can be restricted to specific API Gateway APIs that are relevant for Data Exchange operations.
#!/bin/bash
# Check if any other AWS managed policies restrict API Gateway resources
rg -l "arn:aws:apigateway" Line range hint 5-25: Consider adding resource-level restrictions for Data Exchange actions.
While these permissions are necessary for providers, consider restricting the Resource from "*" to specific Data Exchange resource ARNs owned by the provider to align with the principle of least privilege.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (8)
Line range hint 5-127: LGTM - Comprehensive integration permissions for ECS.
The statement provides necessary permissions for managing ECS integrations with various AWS services. While the permissions are broad (using "*" for resources), this is expected for a FullAccess policy.
Line range hint 128-137: LGTM - Well-scoped SSM parameter access.
The statement follows the principle of least privilege by:
- Limiting to read-only actions (Get*)
- Restricting to ECS-specific parameters
Line range hint 138-155: LGTM - Controlled cleanup of ECS CloudFormation resources.
The statement safely manages resource cleanup by:
- Limiting to specific delete actions
- Using a condition to ensure only ECS-related CloudFormation resources are affected
169-180: LGTM - Well-structured infrastructure role permissions.
The statement follows security best practices by:
- Limiting to a specific role ARN
- Using exact service principal matching
Line range hint 181-213: LGTM - Properly scoped instance and autoscaling role permissions.
Both statements implement secure role passing by:
- Using specific role patterns
- Including necessary regional service principals
Line range hint 231-247: LGTM - Well-designed ELB tagging permissions.
The statement implements secure tagging by:
- Limiting to AddTags action
- Restricting to specific creation operations
Line range hint 214-230: LGTM - Verify the addition of autoscaling service-linked role.
The statement properly restricts service-linked role creation. Please verify that the addition of autoscaling.amazonaws.com is required for new ECS features.
#!/bin/bash
# Check for autoscaling service-linked role usage
rg -A 5 "autoscaling\.amazonaws\.com" --glob "!*.md"Line range hint 156-168: Consider restricting the roles that can be passed to ECS tasks.
While the condition ensures roles can only be passed to ECS tasks, using "" for the resource allows passing any role. Consider restricting this to specific role patterns (e.g., "arn:aws:iam:::role/ecs-task-*") for enhanced security.
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (4)
Line range hint 120-125: LGTM: Improved security with explicit role ARN
The change follows the principle of least privilege by explicitly specifying the service-linked role ARN instead of using a wildcard.
276-297: LGTM: Well-structured resource group permissions
The statement follows security best practices by:
- Restricting resource group names to specific prefix
- Enforcing required tags with specific values
- Limiting allowed tag keys
299-316: LGTM: Secure EC2 instance tagging permissions
The statement implements proper access controls by:
- Only allowing tagging of SSM SAP managed instances
- Restricting tag keys to the service-specific prefix
318-350: Consider restricting EBS volume tagging permissions
I concur with the previous review comments. The volume tagging permissions could be more restrictive:
ManageSsmSapTagsOnEbsVolumesshould be limited to volumes attached to SSM SAP managed instancesManageAppTagsOnEbsVolumesshould have similar restrictions
Let's verify if these volumes are always attached to SSM SAP managed instances:
#!/bin/bash
# Search for patterns of EBS volume attachment in SSM SAP related code
rg -l "AttachVolume|CreateVolume" | xargs rg -A 10 -B 10 "SSMForSAPManaged|SystemsManagerForSAP"docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (5)
96-97: LGTM: Read-only Profile Object Type permissions
The added permissions are properly scoped to read-only operations on profile object types within Connect domains.
149-163: Referencing existing documentation review comment
259-284: LGTM: Secure Chime SDK Voice Connector access
The permissions are well-structured with proper account-level conditions and tag-based access control.
#!/bin/bash
# Verify that all Chime SDK Voice Connector permissions have account-level conditions
rg -A 5 '"Sid": ".*ChimeSDK.*"' . | grep -A 5 "aws:ResourceAccount"285-338: LGTM: Well-structured SES permissions with proper security controls
The SES-related permissions follow security best practices:
- Account-level conditions on all statements
- Specific resource ARNs where applicable
- Restricted PassRole permission with service condition
✅ Verification successful
SES permissions are properly scoped and consistent with AWS Connect requirements
The verification confirms:
- The configuration set name
configuration-set-for-connect-DO-NOT-DELETEis unique to this policy and follows AWS Connect's naming convention - The SES permissions are properly structured with appropriate account-level conditions
- The PassRole permission is correctly restricted to the specific SES service role
- The policy aligns with other AWS SES-related policies in the codebase, maintaining consistent access patterns
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify SES configuration set naming convention
rg "configuration-set-for-connect-DO-NOT-DELETE" .
# Verify PassRole restrictions
rg -A 5 '"Sid": "PassRoleToSES.*"' . | grep -A 5 "iam:PassedToService"
Length of output: 301
Script:
#!/bin/bash
# Search for any other SES configuration set patterns in the codebase
rg -i "configuration-set" .
# Search for PassRole permissions related to SES in a broader context
rg -B 5 -A 10 'iam:PassRole.*ses' .
# Look for any other SES-related IAM policies
rg -B 2 -A 2 '"Sid": ".*SES.*"' .
Length of output: 6276
80-87: LGTM: Customer Profiles permissions follow least privilege principle
The new Customer Profiles permissions are properly scoped to Connect domains and align with service capabilities.
✅ Verification successful
Customer Profiles permissions are properly scoped and documented
The new Customer Profiles permissions are correctly implemented with proper scoping and documentation:
- All actions are under dedicated policy statements with clear Sids (e.g., "AllowCustomerProfilesSegmentationForConnectDomain")
- Permissions are consistently grouped by functionality (segmentation, calculated attributes, integrations)
- Actions follow the standard AWS profile: namespace pattern
- The permissions are part of the official AWS managed policy for Connect service-linked roles
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that these permissions are documented in AWS Customer Profiles API reference
rg -A 2 "ListSegmentDefinitions|ListProfileAttributeValues|CreateSegmentEstimate|GetSegmentEstimate|BatchGetProfile|BatchGetCalculatedAttributeForProfile|GetSegmentMembership" docs/
Length of output: 161
Script:
#!/bin/bash
# Let's try a different approach to verify these permissions
# First, check if these actions are referenced in any documentation or changelog files
fd . docs/ -e md -e rst -e txt -X rg -i "ListSegmentDefinitions|ListProfileAttributeValues|CreateSegmentEstimate|GetSegmentEstimate|BatchGetProfile|BatchGetCalculatedAttributeForProfile|GetSegmentMembership"
# Also check for any related configuration or policy files
fd . -e json -e yaml -e yml -X rg -i "ListSegmentDefinitions|ListProfileAttributeValues|CreateSegmentEstimate|GetSegmentEstimate|BatchGetProfile|BatchGetCalculatedAttributeForProfile|GetSegmentMembership"
# Check for any references to Customer Profiles in general
rg -i "customer.?profiles?" docs/ -A 2 -B 2
Length of output: 49540
docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json (4)
8-11: LGTM: CloudTrail permissions are properly scoped.
The addition of GetServiceLinkedChannel permission complements the existing CreateServiceLinkedChannel permission, allowing the service to both create and retrieve channel information. The resource ARN is appropriately scoped to the Resource Explorer service channel.
16-16: LGTM: API Gateway permission simplification.
The change from an array to a single string for the API Gateway GET permission is a valid simplification since there's only one action.
Line range hint 28-439: LGTM: Resource Explorer service permissions expansion.
The additions grant necessary list/describe permissions for Resource Explorer to discover and index resources across various AWS services. These are read-only operations that align with the service's purpose.
441-441: Verify the impact of broad resource access.
The change from specific resource ARNs to "Resource": "*" significantly broadens the scope of access. While this aligns with Resource Explorer's need to discover resources across services, it's important to verify:
- That this broad access is required for the service to function properly
- That only read-only list/describe actions are permitted
Let's verify that only read-only actions are included:
#!/bin/bash
# Description: Verify that only read-only actions (List*, Describe*, Get*) are included
# Expected: No matches for potentially dangerous actions
echo "Checking for non-read-only actions..."
cat docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json | \
grep -E '"Action"|"Resource"' | \
grep -vE 'List|Describe|Get' | \
grep -v 'Resource'
echo "Checking for write permissions..."
cat docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json | \
grep -E 'Create|Put|Update|Delete|Remove|Modify'docs/source/_static/managed-policies/AWS_ConfigRole.json (13)
32-43: LGTM: AOSS read-only permissions are appropriate
The added Amazon OpenSearch Serverless permissions follow the principle of least privilege by only including read operations necessary for AWS Config to monitor AOSS resources.
89-89: LGTM: AppStream permission follows existing pattern
The added DescribeAppBlockBuilders permission is consistent with the existing read-only AppStream permissions in the policy.
136-137: LGTM: AWS Backup restore testing permissions are appropriate
The added permissions enable AWS Config to monitor Backup restore testing configurations, maintaining read-only access pattern.
Also applies to: 144-145
185-185: LGTM: CloudTrail channel permissions are appropriate
The added CloudTrail channel permissions maintain the read-only access pattern required for AWS Config monitoring.
Also applies to: 189-189
568-568: LGTM: Glue trigger permissions follow existing pattern
The added Glue trigger permissions maintain the read-only access pattern and are consistent with existing Glue permissions.
Also applies to: 574-574
659-659: LGTM: ImageBuilder lifecycle policy permissions are appropriate
The added lifecycle policy permissions maintain read-only access pattern required for AWS Config monitoring.
Also applies to: 669-669
676-676: LGTM: IoT billing group permissions follow existing pattern
The added IoT billing group permissions maintain the read-only access pattern and are consistent with existing IoT permissions.
Also applies to: 693-693
769-774: LGTM: IVS feature permissions are appropriate
The added IVS permissions for encoder configurations, playback restrictions, stages, and storage configurations maintain the read-only access pattern.
Also applies to: 777-782
905-905: LGTM: MediaConnect bridge and gateway permissions follow existing pattern
The added MediaConnect permissions maintain the read-only access pattern required for AWS Config monitoring.
Also applies to: 907-908, 910-910
917-920: LGTM: MediaTailor feature permissions are appropriate
The added MediaTailor permissions for channels, sources, and VOD features maintain the read-only access pattern.
Also applies to: 922-923, 925-926
970-971: LGTM: Omics workflow permissions are appropriate
The added Omics workflow permissions maintain the read-only access pattern required for AWS Config monitoring.
1256-1257: LGTM: Scheduler permissions follow existing pattern
The added Scheduler permissions maintain the read-only access pattern required for AWS Config monitoring.
Line range hint 1-1394: Overall: Policy changes maintain security best practices
All added permissions follow AWS security best practices by:
- Maintaining read-only access pattern required for AWS Config monitoring
- Following the principle of least privilege
- Properly organizing permissions by service
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (9)
32-43: LGTM: AOSS permissions follow least privilege principle
The added Amazon OpenSearch Serverless permissions are appropriately scoped to read-only operations, allowing AWS Config to effectively monitor AOSS resources without excessive privileges.
88-88: LGTM: AppStream permission is properly scoped
The addition of DescribeAppBlockBuilders permission is consistent with existing AppStream permissions and maintains read-only access.
135-136: LGTM: AWS Backup permissions are appropriate
The new AWS Backup permissions for restore testing features maintain read-only access and are consistent with AWS Config's monitoring requirements.
Also applies to: 143-144
566-566: LGTM: Glue permissions maintain least privilege
The added AWS Glue trigger permissions are appropriately scoped to read-only operations, consistent with AWS Config's monitoring needs.
Also applies to: 572-572
767-769: LGTM: IVS permissions are well-structured
The new AWS IVS permissions maintain read-only access for monitoring encoder configurations, playback restrictions, stages, and storage configurations.
Also applies to: 771-772, 775-777, 779-780
903-903: LGTM: MediaConnect permissions are properly scoped
The new AWS MediaConnect permissions for bridges and gateways maintain read-only access and follow the principle of least privilege.
Also applies to: 905-906, 908-908
915-918: LGTM: MediaTailor permissions follow best practices
The new AWS MediaTailor permissions maintain read-only access for channels, sources, and related resources, following security best practices.
Also applies to: 920-921, 923-924
968-969: LGTM: Omics permissions are appropriately scoped
The new AWS Omics workflow permissions maintain read-only access and are consistent with AWS Config's monitoring requirements.
184-184: Case inconsistency in CloudTrail service name still exists
The inconsistent casing of CloudTrail service name was previously identified and needs to be addressed.
Also applies to: 188-188
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (13)
87-88: LGTM: Account service permissions are appropriate for support role
The added permissions account:getRegionOptStatus and account:listRegions are read-only and necessary for AWS Support to assist with region-related issues.
133-147: LGTM: AppConfig read permissions are appropriate
The added AppConfig permissions are read-only and necessary for AWS Support to assist with application configuration issues.
196-202: LGTM: Application Signals permissions follow least privilege
The added Application Signals permissions are appropriately scoped to read-only operations required for support scenarios.
589-600: LGTM: CodeConnections permissions are appropriate
The added CodeConnections permissions are read-only and necessary for AWS Support to assist with code integration issues.
1199-1200: LGTM: EKS pod identity permissions are appropriate
The added EKS permissions for pod identity operations are read-only and align with support requirements.
1136-1148: LGTM: EC2 IPAM permissions follow least privilege
The added EC2 IP Address Manager (IPAM) permissions are appropriately scoped to read-only operations.
2672-2678: LGTM: Route53 Profiles permissions are well-scoped
The added Route53 Profiles permissions are read-only and necessary for DNS management support.
2929-2936: LGTM: SecurityHub permissions enhance support capabilities
The added SecurityHub permissions are appropriately scoped to read-only operations for security findings and configurations.
3432-3435: LGTM: Workspaces permissions follow least privilege
The added Workspaces permissions are read-only and necessary for virtual desktop support scenarios.
3447-3453: LGTM: XRay permissions enhance debugging capabilities
The added XRay permissions are appropriately scoped to read-only operations necessary for application tracing support.
365-386: Review extensive Bedrock AI permissions
The policy grants broad read access to Amazon Bedrock AI resources. While these are read-only permissions, consider:
- Sensitive data exposure through model inspection
- Access to potentially confidential AI/ML configurations
#!/bin/bash
# Description: Verify if Bedrock permissions align with AWS Support documentation
echo "Searching for Bedrock support documentation references:"
rg -i "bedrock.*support" --type md117-132: Verify the necessity of broad AOSS permissions
The added AOSS (Amazon OpenSearch Serverless) permissions grant extensive read access to configurations, policies, and resources.
✅ Verification successful
AOSS permissions are consistent with AWS service role requirements
The AOSS permissions in AWSSupportServiceRolePolicy are appropriate because:
- They are read-only permissions that align with AWS Support's need to troubleshoot and diagnose issues
- The same set of AOSS read permissions are present in other AWS managed policies like ReadOnlyAccess and AWS_ConfigRole
- These permissions follow the principle of least privilege by only including read and list operations, without any write/modify capabilities
- They are necessary for AWS Support to access OpenSearch Serverless configurations, which is essential for providing customer support
The permissions are well-scoped and consistent with AWS Support's service role requirements.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if AOSS permissions align with AWS Support documentation
echo "Searching for AOSS support documentation references:"
rg -i "aoss.*support" --type md
Length of output: 157
Script:
#!/bin/bash
# Let's check for any AOSS related documentation or usage in the codebase
echo "Searching for AOSS references:"
rg -i "aoss" --type-not json
# Check if there are other AWS managed policies that use AOSS permissions
echo -e "\nChecking other managed policies for AOSS permissions:"
rg "aoss:" docs/source/_static/managed-policies/
# Check if there are any test cases or examples using AOSS
echo -e "\nChecking for AOSS in test files:"
fd -e test.js -e test.py -e spec.js -X rg -i "aoss"
Length of output: 10091
828-844: Verify Deadline service permissions scope
The added AWS Deadline permissions provide broad read access to render farm resources. While read-only, verify if all permissions are necessary for support scenarios.
✅ Verification successful
Deadline permissions scope is appropriate for support role
The Deadline permissions in the AWS Support service role policy are read-only list operations that allow AWS Support to view render farm resources for troubleshooting purposes. These permissions are:
- Appropriately scoped to read-only operations (all start with "list")
- Consistent with other service permissions in the policy that enable AWS Support to diagnose issues
- Limited to viewing essential render farm components like farms, fleets, workers, queues etc.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check Deadline permissions usage in support documentation
echo "Searching for Deadline support documentation references:"
rg -i "deadline.*support" --type md
Length of output: 160
Script:
#!/bin/bash
# Let's check for any documentation about Deadline permissions or IAM policies
echo "Searching for Deadline permissions documentation:"
rg -i "deadline.*permission|deadline.*policy" --type md
# Let's also check the policy file itself for any comments or descriptions
echo -e "\nChecking policy file content:"
cat docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json
# Let's look for any related AWS documentation files
echo -e "\nSearching for AWS Support related documentation:"
fd -e md -e txt -e rst . | xargs rg -i "aws.*support.*role|support.*service.*role"
Length of output: 143273
| "kms:Encrypt", | ||
| "kms:Decrypt", | ||
| "kms:ReEncryptTo", | ||
| "kms:ReEncryptFrom", | ||
| "kms:GenerateDataKey", | ||
| "kms:GenerateDataKeyPair", | ||
| "kms:GenerateDataKeyPairWithoutPlaintext", | ||
| "kms:GenerateDataKeyWithoutPlaintext" |
There was a problem hiding this comment.
💡 Codebase verification
Based on the results, I can generate the final response as we have sufficient information from the executed scripts.
Security Concern: Broad KMS permissions for unauthenticated users confirmed
The verification confirms that unrestricted KMS permissions are uniquely present in the AmazonCognitoUnAuthedIdentitiesSessionPolicy.json policy for unauthenticated users, which is a significant security risk. The search across all policy files shows:
- No other unauthenticated identity policies contain similar KMS permissions
- The permissions are granted with "Resource": "*", allowing access to all KMS keys
Recommendations remain critical:
- Restrict KMS permissions to specific keys using ARN in Resource field
- Remove key generation capabilities unless absolutely necessary
- Document business justification for granting KMS access to unauthenticated users
🔗 Analysis chain
Security Concern: Broad KMS permissions for unauthenticated users
The addition of unrestricted KMS permissions to unauthenticated users presents significant security risks:
- Key generation capabilities could lead to resource exhaustion
- Unrestricted decrypt permissions could expose sensitive data
- No key restrictions specified (Resource: "*")
Strongly recommend:
- Limiting KMS permissions to specific keys using the Resource field
- Removing key generation permissions unless absolutely necessary
- Documenting the business requirement for these permissions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for KMS permission patterns in other unauthenticated policies
echo "Checking other unauthenticated policies for KMS patterns..."
rg -B5 -A5 "kms:(Generate|Decrypt|Encrypt)" $(fd -t f . | grep -i unauth) || echo "No other unauthenticated policies found with similar KMS permissions"
echo "Checking for resource restrictions on KMS permissions..."
rg -B2 -A2 '"Resource": "\*".*kms:' $(fd -t f . | grep -i policy) || echo "No unrestricted KMS permissions found in other policies"
Length of output: 59942
| "geo:GetMap*", | ||
| "geo:SearchPlaceIndex*", | ||
| "geo:GetPlace", | ||
| "geo:CalculateRoute*", | ||
| "geo:*Geofence", | ||
| "geo:*Geofences", | ||
| "geo:*DevicePosition*", |
There was a problem hiding this comment.
💡 Codebase verification
Security concern: Overly permissive Geo service permissions for unauthenticated users
The review concern is valid. The policy grants broad, unrestricted access ("Resource": "*") to several sensitive Geo service operations for unauthenticated users:
geo:*Geofenceandgeo:*Geofenceswildcards allow all geofence operations including creation, deletion, and updatesgeo:*DevicePosition*enables unrestricted access to device location data- These permissions are combined with full access to other services like Polly, Comprehend, Rekognition, etc.
Recommendations:
- Restrict Geo permissions to read-only operations (e.g.,
geo:GetMap,geo:GetPlace) - Remove geofence management capabilities for unauthenticated users
- Consider limiting device position tracking to specific resources
- Add resource-level restrictions where possible
🔗 Analysis chain
Verify the scope of Geo service permissions for unauthenticated users
The addition of broad Geo service permissions to unauthenticated users requires careful consideration:
geo:*Geofenceandgeo:*Geofencespermissions are particularly broad and could allow geofence manipulationgeo:*DevicePosition*might expose sensitive location data
Consider restricting these permissions to specific resources or using more granular actions instead of wildcards.
Let me gather more information about the specific Geo permissions in the policy file to better understand their scope.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any existing restrictions or patterns in how Geo permissions are handled
# in other Cognito-related policies
echo "Checking other Cognito policies for Geo service patterns..."
rg -l "geo:[^\"]*" $(fd -t f . | grep -i cognito) || echo "No other Cognito policies found with Geo permissions"
echo "Checking for potential sensitive Geo operations..."
rg "geo:(Create|Update|Delete)" $(fd -t f . | grep -i cognito) || echo "No sensitive Geo operations found in other Cognito policies"
Length of output: 2777
Script:
#!/bin/bash
# Check the full content of the UnAuthedIdentitiesSessionPolicy to understand the context
echo "Checking the complete UnAuthedIdentitiesSessionPolicy..."
cat docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
# Check if there are any resource restrictions in the policy
echo -e "\nChecking for resource restrictions..."
rg '"Resource"' docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json -A 5
Length of output: 1356
udondan
force-pushed
the
update-aws-managed-policies
branch
from
a9f5565
to
6758063
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (4)
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (1)
66-95: Consider a systematic approach to action selectionWhile the added actions improve security, consider adopting a systematic approach to selecting denied actions:
- Resource Creation: Deny all
Create*actions for services that could be abused- Authentication/Authorization: Deny credential management and token generation
- Data Access: Carefully consider denying read actions that might hinder investigation
- Infrastructure: Deny actions that could create or modify infrastructure
- Billing: Deny actions that could incur costs (already done with SavingsPlans)
This systematic approach would help ensure consistent coverage across services.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (2)
Line range hint
5-127: Consider adding resource-level restrictions where possible.While this is a FullAccess policy, some permissions could benefit from resource-level restrictions:
ec2:RunInstancescould be limited to specific VPCs or instance typescloudformation:*Stackoperations could be scoped to specific stack name patternslogs:CreateLogGroupcould be restricted to specific log group prefixesConsider creating a separate, more restrictive policy for production environments where full access isn't required.
Line range hint
138-155: Consider adding resource ARN patterns for EC2 resources.While the CloudFormation stack name condition provides some safety, consider adding resource-level restrictions for the EC2 resources to further enhance security.
"Resource": [ - "*" + "arn:aws:ec2:*:*:internet-gateway/*", + "arn:aws:ec2:*:*:route-table/*", + "arn:aws:ec2:*:*:security-group/*" ],docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (1)
195-208: LGTM: Well-structured segmentation permissionsThe segmentation permissions are properly scoped and follow a logical grouping. Consider the performance implications of segment operations on large datasets.
For optimal performance with large customer datasets:
- Implement appropriate pagination in segment queries
- Consider implementing caching for frequently accessed segments
- Monitor segment snapshot creation times and resource usage
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
lib/generated/aws-managed-policies/cdk-iam-floyd.tsis excluded by!**/generated/**lib/generated/aws-managed-policies/iam-floyd.tsis excluded by!**/generated/**
📒 Files selected for processing (82)
docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSBackupFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json(2 hunks)docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json(1 hunks)docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json(11 hunks)docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json(2 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json(2 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json(2 hunks)docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json(25 hunks)docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWS_ConfigRole.json(14 hunks)docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonBedrockReadOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json(2 hunks)docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json(1 hunks)docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json(1 hunks)docs/source/_static/managed-policies/AmazonECS_FullAccess.json(8 hunks)docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSComputePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSServicePolicy.json(3 hunks)docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonQDeveloperAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonQFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json(1 hunks)
⛔ Files not processed due to max files limit (19)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json
- docs/source/_static/managed-policies/CloudWatchInternetMonitorFullAccess.json
- docs/source/_static/managed-policies/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.json
- docs/source/_static/managed-policies/CloudWatchSyntheticsFullAccess.json
- docs/source/_static/managed-policies/ElasticLoadBalancingFullAccess.json
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/ReadOnlyAccess.json
- docs/source/_static/managed-policies/ResourceGroupsTaggingAPITagUntagSupportedResources.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/SecurityAudit.json
- docs/source/_static/managed-policies/ViewOnlyAccess.json
- docs/source/_static/managed-policies/index.json
💤 Files with no reviewable changes (3)
- docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json
🚧 Files skipped from review as they are similar to previous changes (70)
- docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSBackupFullAccess.json
- docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json
- docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json
- docs/source/_static/managed-policies/AWSDataSyncFullAccess.json
- docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json
- docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json
- docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json
- docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json
- docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json
- docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSComputePolicy.json
- docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSServicePolicy.json
- docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonQDeveloperAccess.json
- docs/source/_static/managed-policies/AmazonQFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json
🔇 Additional comments (62)
docs/source/_static/managed-policies/AmazonSNSFullAccess.json (3)
5-9: LGTM: Format simplification maintains same permissions.
The change from array to string format for the single sns:* action is a clean simplification while maintaining identical permissions.
28-32: Well-implemented security control via service principal condition.
The condition block using aws:CalledViaLast effectively ensures these SMS voice permissions can only be invoked through the SNS service, following the principle of least privilege.
13-26: Comprehensive SMS voice permissions with known overlap.
The permissions set provides a complete range of SMS voice capabilities needed for SNS operations.
Note: As identified in previous reviews, some of these SMS voice permissions overlap with other policies. This is expected for AWS managed policies serving different use cases.
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (2)
84-85: Effective containment strategy approved
The combination of denying STS token generation (GetSessionToken, GetFederationToken) while also preventing IAM destruction (DeleteRole, DeleteAccessKey) creates an effective containment strategy:
- Prevents the attacker from creating new credentials
- Prevents the attacker from destroying existing access controls
- Maintains the ability to investigate and remediate
Also applies to: 90-91
95-95: MediaPackage restriction approved
Denying mediapackagev2:CreateChannel is appropriate as it prevents the creation of unauthorized streaming infrastructure that could be used for data exfiltration or resource abuse.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (9)
Line range hint 5-25: LGTM - Broad permissions align with FullAccess policy intent
The permissions granted are appropriately scoped to the dataexchange service. While broad, this aligns with the "FullAccess" nature of this managed policy.
Line range hint 27-47: LGTM - Well-constrained job permissions
Good implementation of least privilege principle by:
- Limiting to specific job actions
- Using conditions to restrict job types
- Explicitly enumerating allowed job types
Line range hint 62-77: LGTM - Well-implemented tag-based access control
Good use of tagging strategy combined with service boundary control via CalledVia.
Line range hint 94-103: LGTM - Standard S3 list permissions
These permissions are appropriate for S3 console operation and bucket discovery.
Line range hint 104-123: LGTM - Appropriate Marketplace permissions
The permissions align well with Data Exchange provider requirements for managing marketplace listings and agreements.
Line range hint 124-154: LGTM - Well-constrained KMS and Redshift permissions
Good implementation with:
- Read-only KMS permissions
- Specific Redshift data share actions
- Appropriate use of ConsumerIdentifier condition
Line range hint 156-162: LGTM - Minimal API Gateway permissions
Appropriately restricted to GET operations only.
Line range hint 78-93: Review necessity of PutObjectAcl permission
The inclusion of s3:PutObjectAcl could potentially allow modification of object ACLs. If ACL modifications aren't required for the Data Exchange workflow, consider removing this permission following the principle of least privilege.
#!/bin/bash
# Check for code that might be using PutObjectAcl
rg "PutObjectAcl|putObjectAcl" Line range hint 49-61: Consider tightening the S3 bucket pattern
While the CalledVia condition provides good service boundary control, the resource pattern *aws-data-exchange* might match unintended buckets. Consider using a more specific pattern or documenting the naming convention requirement.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (4)
Line range hint 128-137: LGTM! Well-scoped SSM permissions.
The policy correctly restricts SSM parameter access to ECS-specific parameters and only allows read operations.
Line range hint 156-213: LGTM! Well-structured PassRole permissions.
The PassRole permissions are properly separated and scoped:
- TasksPassRolePolicy for ECS tasks
- InfrastructurePassRolePolicy for ECS service
- InstancePassRolePolicy for EC2 instances
- AutoScalingPassRolePolicy for Application Auto Scaling
Each policy has appropriate service principal conditions and role name patterns.
Line range hint 214-230: LGTM! Appropriate service-linked role permissions.
The policy correctly allows creation of service-linked roles for ECS-related services, including the newly added Auto Scaling service.
Line range hint 231-247: LGTM! Well-designed tagging permissions.
The policy correctly restricts tagging to resource creation time, which helps maintain consistent tagging across ELB resources.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (5)
96-97: LGTM: Read-only Profile Object Type permissions
The added permissions are read-only and properly scoped to object types within Connect domains.
149-163: LGTM: Wisdom message template permissions are properly conditioned
The new message template permissions are correctly restricted with the AmazonConnectEnabled tag condition, ensuring these permissions only apply to resources explicitly enabled for Connect.
259-284: LGTM: Chime SDK permissions follow security best practices
The voice connector permissions are properly secured with:
- Account-level conditions
- AmazonConnectEnabled tag requirement for get operations
- Specific resource ARN restrictions
286-338: LGTM: SES permissions are properly secured
The SES-related permissions follow security best practices with:
- Account-level conditions on all operations
- Specific resource scoping for email identities and configuration sets
- Restricted PassRole permission to specific SES role
✅ Verification successful
Let me verify the SES permissions further by checking for any other related configurations or references.
SES permissions are properly configured and secured
The verification confirms that:
- SES configuration set is consistently referenced with the specific name
configuration-set-for-connect-DO-NOT-DELETE - Email identity pattern is properly scoped to
*.email.connect.aws* - PassRole permission is correctly restricted to
AmazonConnectEmailSESAccessRoleand only allows passing toses.amazonaws.com - All operations have account-level conditions via
aws:ResourceAccount
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify SES configuration set naming convention
rg "configuration-set-for-connect-DO-NOT-DELETE" docs/ -A 5 -B 5
Length of output: 1297
Script:
#!/bin/bash
# Check for other SES-related configurations and roles
rg "AmazonConnectEmailSESAccessRole" docs/ -A 5 -B 5
# Look for any other SES configuration sets
rg "arn:aws:ses.*:configuration-set" docs/
# Check for email identity patterns
rg "arn:aws:ses.*:identity" docs/
Length of output: 1613
80-87: LGTM: Customer Profiles permissions are properly scoped
The new Customer Profiles permissions are correctly scoped to Connect domains and follow the principle of least privilege.
✅ Verification successful
Customer Profiles permissions are properly scoped and consistent with AWS Connect requirements
The permissions in AmazonConnectServiceLinkedRolePolicy.json are:
- Correctly scoped to Connect domains with resource restriction
arn:aws:profile:*:*:domains/amazon-connect-* - Aligned with the full access policy (AmazonConnect_FullAccess.json) but more restrictive
- Properly segmented into logical groups (profiles, objects, templates, segmentation)
- Follow the principle of least privilege by granting only the necessary read and segmentation operations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that these Customer Profiles permissions are consistent with AWS documentation
rg -l "profile:(List|Create|Get|Batch)(Segment|Profile|Integration)" docs/
Length of output: 461
Script:
#!/bin/bash
# Let's examine the actual permissions in these files to verify consistency
rg -A 5 -B 5 'profile:(List|Create|Get|Batch)(Segment|Profile|Integration)' docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json docs/source/_static/managed-policies/AmazonConnect_FullAccess.json
Length of output: 10279
docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json (4)
8-11: LGTM: CloudTrail permissions are appropriately scoped.
The addition of GetServiceLinkedChannel permission complements the existing CreateServiceLinkedChannel permission, maintaining the principle of least privilege by using a specific resource ARN pattern.
16-16: LGTM: API Gateway action format simplified.
The change from an array to a single string for apigateway:GET is a valid simplification since there's only one action.
441-441:
Caution: Resource specification change broadens access scope.
I agree with the previous review comment about the broad resource access. The change from specific resource ARNs to "Resource": "*" significantly increases the access scope. While this might simplify policy management, it potentially violates the principle of least privilege.
Consider:
- Using more specific resource ARNs where possible
- Implementing condition keys to restrict access
- Splitting the policy into multiple statements with granular resource definitions
28-39: Verify the necessity of new service permissions.
The policy adds numerous new permissions for listing and describing resources across various AWS services. While these are read-only permissions, they significantly expand the service role's access scope.
Let's verify if these permissions are required by Resource Explorer:
Also applies to: 52-53, 56-56, 83-83, 88-90, 94-100, 128-128, 192-192, 233-233, 235-235, 237-241, 271-277, 280-280, 282-283, 407-410, 413-413, 420-420, 435-435, 437-439
✅ Verification successful
Let me gather more specific information about Resource Explorer's supported resource types.
Let me search specifically for the AWS Resource Explorer documentation or configuration that lists the supported services.
Based on the extensive context provided, I can now generate a final response regarding the necessity of the new service permissions in the Resource Explorer service role policy.
The new service permissions are necessary and aligned with Resource Explorer's functionality.
The permissions are justified because:
-
The policy
AWSResourceExplorerServiceRolePolicyshows that Resource Explorer needs these permissions to discover and index AWS resources across services for its core functionality. -
The permissions are read-only (
List*,Describe*,Get*) operations that allow Resource Explorer to gather metadata about resources in these services. -
The services match those listed in the
ResourceInventoryAccessstatement of the service role policy, which is used to build and maintain the resource inventory. -
The permissions are consistent with Resource Explorer's purpose of providing a unified search and discovery experience across AWS services.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if these services are documented as supported resource types
# in Resource Explorer's documentation or configuration.
# Search for references to these services in Resource Explorer documentation
echo "Searching for service references in documentation..."
rg -i "supported.*(resource|service).*(type|kind)" \
-g "*.md" \
-g "*.txt" \
-g "*.html" \
--multiline
# Search for service configurations in Resource Explorer code
echo "Searching for service configurations..."
rg -i "(supported|allowed|enabled).*(resource|service)" \
-g "*.{json,yaml,yml,tf,hcl}"
Length of output: 45558
Script:
#!/bin/bash
# Search for Resource Explorer's supported resource types documentation
echo "Searching for Resource Explorer resource types..."
rg -i "resource.?explorer.*resource.?type" \
-B 5 -A 5 \
--multiline
# Search for any configuration files that might list supported services
echo "Searching for service configuration files..."
fd -e json -e yaml -e yml \
--exec rg -i "resource.?type|supported.?service"
Length of output: 5343
Script:
#!/bin/bash
# Search for Resource Explorer documentation about supported services
echo "Searching for Resource Explorer documentation..."
rg -i "(supported|available).*(resource|service).*(type|kind)" \
-g "README*" \
-g "CHANGELOG*" \
-g "docs/*" \
-B 3 -A 10
# Search for any Resource Explorer configuration files
echo "Searching for Resource Explorer configuration..."
fd -e json -e yaml -e yml -e tf -e hcl \
--exec grep -l -i "resource.explorer" {} \; \
--exec cat {} \;
Length of output: 393172
docs/source/_static/managed-policies/AWS_ConfigRole.json (13)
32-43: LGTM: AOSS permissions follow least privilege principle
The added Amazon OpenSearch Serverless permissions are appropriately scoped to read-only operations, allowing AWS Config to monitor AOSS resources effectively.
89-89: LGTM: AppStream permission is appropriately scoped
The addition of DescribeAppBlockBuilders permission is consistent with AWS Config's monitoring requirements.
136-137: LGTM: AWS Backup restore testing permissions are appropriate
The added permissions enable AWS Config to monitor backup restore testing configurations, maintaining read-only access.
Also applies to: 144-145
185-185: LGTM: CloudTrail channel permissions follow security best practices
The added CloudTrail channel permissions maintain read-only access, appropriate for AWS Config's monitoring role.
Also applies to: 189-189
354-354: LGTM: EC2 VPC endpoint permission is appropriate
The addition of DescribeVpcEndpoints permission aligns with AWS Config's need to monitor VPC endpoint resources.
568-568: LGTM: Glue trigger permissions maintain least privilege
The added Glue trigger permissions are appropriately scoped to read-only operations.
Also applies to: 574-574
659-659: LGTM: ImageBuilder lifecycle policy permissions are well-scoped
The added permissions enable AWS Config to monitor ImageBuilder lifecycle policies while maintaining read-only access.
Also applies to: 669-669
676-676: LGTM: IoT billing group permissions follow security best practices
The added IoT billing group permissions maintain read-only access, appropriate for AWS Config's monitoring role.
Also applies to: 693-693
769-774: LGTM: IVS permissions are comprehensive and well-scoped
The added IVS permissions provide necessary read-only access for monitoring various IVS resources while maintaining the principle of least privilege.
Also applies to: 777-782
905-910: LGTM: MediaConnect permissions maintain security best practices
The added MediaConnect permissions are appropriately scoped to read-only operations for bridges and gateways.
917-926: LGTM: MediaTailor permissions follow least privilege principle
The added MediaTailor permissions maintain read-only access for monitoring various MediaTailor resources.
970-971: LGTM: Omics workflow permissions are appropriately scoped
The added Omics permissions maintain read-only access for monitoring workflow resources.
1256-1257: LGTM: Scheduler permissions follow security best practices
The added Scheduler permissions maintain read-only access, appropriate for AWS Config's monitoring role.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (10)
32-43: LGTM - AOSS permissions follow least privilege principle
The added Amazon OpenSearch Serverless permissions are appropriately scoped to read-only operations necessary for AWS Config to monitor AOSS resources.
88-88: LGTM - AppStream permission is appropriately scoped
The added AppStream permission is correctly limited to read-only access.
135-136: LGTM - AWS Backup permissions are properly scoped
The added AWS Backup permissions for restore testing functionality are appropriately limited to read-only operations.
Also applies to: 143-144
566-566: LGTM - Glue permissions follow security best practices
The added AWS Glue permissions are correctly scoped to read-only operations for trigger resources.
Also applies to: 572-572
767-772: LGTM - IVS permissions are well-structured
The added AWS IVS permissions are appropriately scoped to read-only operations across various IVS resource types.
Also applies to: 775-780
903-909: LGTM - MediaConnect permissions follow security best practices
The added AWS MediaConnect permissions are properly limited to read-only operations for monitoring resources.
915-924: LGTM - MediaTailor permissions are appropriately scoped
The added AWS MediaTailor permissions follow the principle of least privilege with read-only access.
968-969: LGTM - Omics permissions follow security best practices
The added AWS Omics permissions are correctly limited to read-only operations for workflow resources.
1254-1255: LGTM - Scheduler permissions are well-defined
The added AWS Scheduler permissions are appropriately scoped to read-only operations.
184-184: Fix case inconsistency in CloudTrail service names
The inconsistent casing of CloudTrail service names noted in the previous review still needs to be addressed.
Also applies to: 188-188
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (12)
87-88: LGTM: Appropriate read-only permissions for account and application signals.
The added permissions allow AWS Support to view region configurations and application signal data, which are necessary for troubleshooting support cases.
Also applies to: 196-202
117-132: LGTM: Appropriate read-only permissions for OpenSearch Serverless.
The added permissions are strictly read-only operations needed for AWS Support to troubleshoot OpenSearch Serverless issues.
133-147: LGTM: Appropriate read-only permissions for AppConfig service.
The added permissions allow AWS Support to view application configurations and deployments, which is necessary for troubleshooting AppConfig-related issues.
365-386: LGTM: Appropriate read-only permissions for Bedrock service.
The added permissions allow AWS Support to view Bedrock resources and configurations, which is necessary for troubleshooting AI/ML workloads. All permissions maintain the principle of least privilege by being read-only.
589-600: LGTM: Appropriate read-only permissions for CodeConnections service.
The added permissions enable AWS Support to view code connections and repository links, which is necessary for troubleshooting code integration issues. All permissions are read-only, maintaining security best practices.
828-844: LGTM: Appropriate list-only permissions for Deadline service.
The added permissions allow AWS Support to view Deadline render farm resources, which is necessary for troubleshooting rendering and high-performance computing workloads. All permissions are list operations, maintaining security best practices.
1695-1696: LGTM: Appropriate read-only permissions for Inspector2 service.
The added permissions allow AWS Support to view Inspector2 configurations, which is necessary for security assessment support cases. The permissions are minimal and read-only.
2357-2362: LGTM: Appropriate read-only permissions for OSIS service.
The added permissions allow AWS Support to view and validate OSIS pipeline configurations, which is necessary for troubleshooting pipeline issues. All operations are read-only.
2672-2678: LGTM: Appropriate read-only permissions for Route53 Profiles service.
The added permissions allow AWS Support to view Route53 profile configurations, which is necessary for DNS and routing support cases. All permissions maintain the principle of least privilege.
2929-2936: LGTM: Appropriate read-only permissions for SecurityHub service.
The added permissions allow AWS Support to view SecurityHub configurations and policies, which is necessary for security posture support cases. All permissions are read-only operations.
3432-3435: LGTM: Appropriate describe-only permissions for Workspaces service.
The added permissions allow AWS Support to view Workspaces associations and pools, which is necessary for desktop computing support cases. All permissions are describe operations.
3447-3453: LGTM: Appropriate read-only permissions for XRay service.
The added permissions allow AWS Support to view XRay tracing data, which is necessary for application performance and debugging support cases. All permissions are read-only operations.
| "bedrock:CreateModelInvocationJob", | ||
| "bedrock:InvokeModelWithResponseStream", | ||
| "bedrock:CreateFoundationModelAgreement", | ||
| "bedrock:PutFoundationModelEntitlement", | ||
| "bedrock:InvokeModel", |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider additional Bedrock restrictions
While denying model creation and invocation is good, consider also denying:
bedrock:CreateCustomModel- prevents creation of custom models that could be used maliciouslybedrock:CreateProvisionedModel- prevents resource-intensive provisioned modelsbedrock:CreateModelCustomizationJob- prevents model customization that could be exploited
udondan
force-pushed
the
update-aws-managed-policies
branch
from
6758063
to
623b6be
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (7)
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (1)
71-75: LGTM: Comprehensive Bedrock AI/ML restrictionsThe added Bedrock restrictions effectively prevent both creation and invocation of AI models, protecting against potential abuse of AI/ML resources.
Consider also adding these Bedrock actions to prevent additional attack vectors:
+"bedrock:CreateCustomModel", +"bedrock:CreateProvisionedModel", +"bedrock:CreateModelCustomizationJob"docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json (4)
48-85: Consider consolidating security group management statements.The policy currently has three separate statements for security group ingress management. While they serve different purposes, they could potentially be consolidated to reduce policy complexity while maintaining the same level of security.
Consider consolidating into a single statement with combined conditions:
- { - "Effect": "Allow", - "Action": [ - "ec2:AuthorizeSecurityGroupIngress" - ], - "Resource": "arn:aws:ec2:*:*:security-group-rule/*", - "Condition": { - "StringEquals": { - "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" - } - } - }, - { - "Effect": "Allow", - "Action": [ - "ec2:AuthorizeSecurityGroupIngress", - "ec2:RevokeSecurityGroupIngress" - ], - "Resource": "arn:aws:ec2:*:*:security-group/*", - "Condition": { - "StringLike": { - "aws:ResourceTag/Name": "eks-cluster-sg*" - } - } - }, - { - "Effect": "Allow", - "Action": [ - "ec2:AuthorizeSecurityGroupIngress", - "ec2:RevokeSecurityGroupIngress" - ], - "Resource": "arn:aws:ec2:*:*:security-group/*", - "Condition": { - "StringEquals": { - "aws:ResourceTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" - } - } - }, + { + "Effect": "Allow", + "Action": [ + "ec2:AuthorizeSecurityGroupIngress", + "ec2:RevokeSecurityGroupIngress" + ], + "Resource": [ + "arn:aws:ec2:*:*:security-group-rule/*", + "arn:aws:ec2:*:*:security-group/*" + ], + "Condition": { + "StringEquals": { + "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" + }, + "StringLike": { + "aws:ResourceTag/Name": ["eks-cluster-sg*", "*"] + } + } + }
140-204: Consider using resource-level permissions for Shield actions.While the Shield permissions have appropriate tag conditions, they use
Resource: "*". Consider restricting the resource ARN pattern to only allow Shield protections for load balancer resources.Example modification for Shield statements:
{ "Effect": "Allow", "Action": [ "shield:CreateProtection" ], - "Resource": "*", + "Resource": "arn:aws:shield::*:protection/elasticloadbalancing/*/*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }
205-217: Consider scoping read permissions to specific resources.While these are read-only permissions, consider restricting some actions to specific resources:
cognito-idp:DescribeUserPoolClientcould be scoped to specific user poolsacm:ListCertificatesandacm:DescribeCertificatecould be scoped to specific regionsExample modification:
{ "Effect": "Allow", "Action": [ - "cognito-idp:DescribeUserPoolClient", - "acm:ListCertificates", - "acm:DescribeCertificate", "wafv2:GetWebACL", "wafv2:GetWebACLForResource", "elasticloadbalancing:SetWebAcl", "elasticloadbalancing:DescribeTargetGroups" ], "Resource": "*" }, + { + "Effect": "Allow", + "Action": [ + "cognito-idp:DescribeUserPoolClient" + ], + "Resource": "arn:aws:cognito-idp:*:*:userpool/${aws:PrincipalTag/eks:eks-cluster-name}/*" + }, + { + "Effect": "Allow", + "Action": [ + "acm:ListCertificates", + "acm:DescribeCertificate" + ], + "Resource": "arn:aws:acm:*:*:certificate/*", + "Condition": { + "StringEquals": { + "aws:RequestedRegion": ["us-east-1", "us-west-2"] # Add your required regions + } + } + }
1-231: Overall policy structure is solid but has room for optimization.The policy effectively manages EKS load balancer permissions with proper tag-based conditions. Consider the suggested improvements to:
- Remove redundant CreateSecurityGroup permission
- Consolidate security group management statements
- Add more resource-level restrictions for Shield and read-only operations
These changes would make the policy more maintainable while maintaining the same security posture.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (1)
Line range hint
5-127: Consider implementing resource-level permissions where applicableWhile the broad permissions are necessary for ECS service integrations, consider implementing resource-level permissions for services that support it, such as:
- CloudFormation (limit to specific stack patterns)
- CloudWatch (scope to ECS-related resources)
- Lambda (restrict to specific functions)
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (1)
828-844: Deadline permissions scope appears excessiveThe added AWS Deadline permissions provide broad access to render farm information. Consider if all these list operations are necessary for support functions.
Consider restricting to specific resource types needed for common support cases rather than allowing listing of all resource types.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
lib/generated/aws-managed-policies/cdk-iam-floyd.tsis excluded by!**/generated/**lib/generated/aws-managed-policies/iam-floyd.tsis excluded by!**/generated/**
📒 Files selected for processing (82)
docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSBackupFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json(2 hunks)docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json(1 hunks)docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json(11 hunks)docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json(2 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json(2 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json(2 hunks)docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json(25 hunks)docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWS_ConfigRole.json(14 hunks)docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonBedrockReadOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json(2 hunks)docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json(1 hunks)docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json(1 hunks)docs/source/_static/managed-policies/AmazonECS_FullAccess.json(8 hunks)docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSComputePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSServicePolicy.json(3 hunks)docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonQDeveloperAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonQFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json(1 hunks)
⛔ Files not processed due to max files limit (19)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json
- docs/source/_static/managed-policies/CloudWatchInternetMonitorFullAccess.json
- docs/source/_static/managed-policies/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.json
- docs/source/_static/managed-policies/CloudWatchSyntheticsFullAccess.json
- docs/source/_static/managed-policies/ElasticLoadBalancingFullAccess.json
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/ReadOnlyAccess.json
- docs/source/_static/managed-policies/ResourceGroupsTaggingAPITagUntagSupportedResources.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/SecurityAudit.json
- docs/source/_static/managed-policies/ViewOnlyAccess.json
- docs/source/_static/managed-policies/index.json
💤 Files with no reviewable changes (3)
- docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json
🚧 Files skipped from review as they are similar to previous changes (68)
- docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSBackupFullAccess.json
- docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json
- docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json
- docs/source/_static/managed-policies/AWSDataSyncFullAccess.json
- docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json
- docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json
- docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json
- docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json
- docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json
- docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSComputePolicy.json
- docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSServicePolicy.json
- docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonQDeveloperAccess.json
- docs/source/_static/managed-policies/AmazonQFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json
🔇 Additional comments (75)
docs/source/_static/managed-policies/AmazonSNSFullAccess.json (3)
5-9: LGTM: Format simplification for single action.
The change from array to string format for the single sns:* action is a valid simplification that maintains the same functionality.
28-32: Well-implemented security control via condition block.
The Condition block properly restricts SMS voice actions to be invoked only through SNS service, which is a good security practice following the principle of least privilege.
13-26: Verify the necessity of all SMS voice permissions.
The statement includes a broad set of SMS voice permissions. Let's verify if all these permissions are necessary for SNS operations.
Consider documenting the use cases for each permission group:
- Account management: DescribeAccountAttributes, DescribeSpendLimits
- Destination number verification: Create/Verify/DeleteVerifiedDestinationNumber
- Messaging operations: SendTextMessage
- Opt-out management: DescribeOptedOutNumbers, DeleteOptedOutNumber
✅ Verification successful
SMS voice permissions are appropriately scoped in SNS policies
The SMS voice permissions are properly structured across SNS policies:
- The read-only policy (
AmazonSNSReadOnlyAccess) contains only the descriptive operations - The full access policy (
AmazonSNSFullAccess) includes additional write operations - The permissions align with SNS SMS sandbox features (as seen in CHANGELOG/v0.192.0.md)
The permissions are categorized logically for different operational needs:
- Account/spend management
- Phone number verification
- Message sending
- Opt-out handling
These permissions are necessary for comprehensive SMS functionality in SNS and follow the principle of least privilege between read-only and full access policies.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for SMS voice permissions usage patterns
# Expected result: These permissions should be commonly used with SNS
# Check for any documentation or examples showing SMS voice integration with SNS
rg -g '*.md' -i 'sms.?voice.*sns'
# Check for any code examples or tests using these permissions
rg -g '*.{js,py,java,rb}' 'sms-voice:'
# Check other policies that might have more restricted SMS voice permission sets
rg -g '*SNS*.json' 'sms-voice:'
Length of output: 1983
Script:
#!/bin/bash
# Let's check for any documentation about SMS/voice features in SNS
rg -g '*.{md,rst,txt}' -i '(sms|voice).*feature.*sns|sns.*voice|sns.*sms' -A 3 -B 3
# Also check for any configuration or example files related to SMS/voice in SNS
fd -e yaml -e yml -e json -e conf -e config -e example | xargs rg -l 'sms|voice'
# Look for any changelog or release notes mentioning SMS voice features
rg -g '*CHANGELOG*' -g '*release*' -g '*history*' -i 'sms.?voice' -A 2 -B 2
Length of output: 2387
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (6)
5-11: LGTM: Appropriate read-only permission for campaign listing
The statement follows the principle of least privilege by only allowing the list operation.
13-22: LGTM: Well-scoped permissions for Connect instance operations
The statement provides necessary actions for campaign management while properly restricting the resource scope to Connect instances.
24-35: LGTM: Secure configuration for EventBridge rule listing
The statement includes appropriate same-account condition for security while allowing necessary rule listing capability.
54-65: LGTM: Consistent EventBridge target listing permissions
The statement maintains consistent security controls with other EventBridge permissions while providing necessary target listing capability.
67-78: LGTM: Well-implemented tag-based access control for Wisdom operations
The statement follows AWS best practices by using tag-based access control for Wisdom template operations.
Let's verify the tag usage in the codebase:
#!/bin/bash
# Check for references to the AmazonConnectCampaignsEnabled tag
rg "AmazonConnectCampaignsEnabled" --type json -A 537-52: LGTM: Well-secured EventBridge rule management permissions
The statement implements strong security controls through:
- Resource name prefix restriction
- Same-account condition
- Service management condition
Let's verify if there are any existing rules that might be affected:
✅ Verification successful
Let me search for more context about EventBridge rules and their usage in the codebase.
Based on the comprehensive search results, I can now verify the EventBridge rule permissions in the policy. The search shows that similar EventBridge rule management patterns are used across multiple AWS service-linked role policies, with consistent security controls like resource name prefixes and service management conditions.
LGTM: EventBridge rule management permissions follow AWS best practices
The statement implements standard AWS security controls that are consistent with other AWS service-linked role policies:
- Resource name prefix "ConnectCampaignsRule*" follows the AWS naming pattern seen in other services (e.g., AWSBackupManagedRule*, SSMExplorerManagedRule)
- Same-account condition is a common security control
- Service management condition "connect-campaigns.amazonaws.com" follows the pattern used by other AWS services
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing EventBridge rules that match the pattern
rg -l "ConnectCampaignsRule" --type json
Length of output: 675
Script:
#!/bin/bash
# Search for EventBridge rule related patterns in the codebase
rg -i "eventbridge|events:.*rule" --type json -A 3
Length of output: 142321
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (6)
66-66: LGTM: Appropriate restriction on financial commitments
Denying savingsplans:CreateSavingsPlan aligns well with existing restrictions on EC2 reserved instances, preventing financial abuse through long-term commitments.
67-69: LGTM: Appropriate container service restrictions
The ECS restrictions (CreateService, CreateCluster, RegisterTaskDefinition) effectively prevent the creation of new container infrastructure that could be used for malicious purposes.
80-81: LGTM: Appropriate ML resource restrictions
Denying SageMaker endpoint and processing job creation prevents the abuse of potentially expensive ML resources.
84-85: LGTM: Critical STS restrictions
Denying GetSessionToken and GetFederationToken is crucial as these actions could be used to maintain persistent access after key compromise.
86-89: LGTM: Comprehensive development resource restrictions
The restrictions on Amplify, CodeBuild, and Glue effectively prevent the creation of new development and deployment resources that could be used for running unauthorized workloads.
95-95: LGTM: Appropriate media service restriction
Denying mediapackagev2:CreateChannel prevents the creation of new media infrastructure that could be used for unauthorized streaming or content distribution.
docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json (2)
1-28: LGTM! Well-structured initial create permissions with proper tag conditions.
The create permissions are appropriately scoped with tag conditions to ensure resources are only created for the authorized EKS cluster.
29-35: Remove redundant CreateSecurityGroup permission statement.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (5)
Line range hint 128-137: LGTM! Well-scoped SSM permissions
The SSM permissions are properly restricted to ECS-specific parameters following the least privilege principle.
Line range hint 138-155: LGTM! Well-controlled cleanup permissions
The cleanup permissions are properly controlled with CloudFormation stack name conditions, ensuring only ECS-related resources can be deleted.
Line range hint 214-230: LGTM! Appropriate service-linked role permissions
The service-linked role creation is properly restricted to relevant ECS-related services, including the necessary autoscaling service.
Line range hint 231-247: LGTM! Well-controlled ELB tagging permissions
The ELB tagging permissions are properly restricted to resource creation actions, following AWS tagging best practices.
Line range hint 156-213: LGTM! Well-structured PassRole permissions
The PassRole permissions are properly structured with:
- Appropriate service conditions
- Specific role patterns
- Clear separation of concerns
Let's verify the role naming patterns are consistent with existing roles:
✅ Verification successful
Role patterns are consistent with AWS ECS managed policies
The role patterns (ecsInfrastructureRole, ecsInstanceRole, ecsAutoscaleRole) are consistently referenced in AWS managed policies for ECS and Batch services. While documentation for these roles isn't directly visible in the repository, this is expected as these are standard AWS-managed role patterns rather than custom roles.
The PassRole permissions in the policy follow AWS best practices by:
- Using specific role name patterns that match AWS managed roles
- Implementing proper service-specific conditions
- Maintaining consistent naming across related AWS managed policies
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify role naming patterns exist and are consistent
# Expected: Find roles matching the patterns used in the policy
# Check for ECS infrastructure roles
rg "role/ecsInfrastructureRole" --type json
# Check for ECS instance roles
rg "role/ecsInstanceRole" --type json
# Check for ECS autoscale roles
rg "role/ecsAutoscaleRole" --type json
Length of output: 564
Script:
#!/bin/bash
# Let's verify if these role patterns are documented in READMEs or other docs
# and check for any related IAM role definitions
# Search for documentation about these roles
rg -i "ecsinfrastructure.*role|ecs infrastructure.*role" --type md -A 2 -B 2
rg -i "ecsinstance.*role|ecs instance.*role" --type md -A 2 -B 2
rg -i "ecsautoscale.*role|ecs autoscaling.*role" --type md -A 2 -B 2
# Look for IAM role definitions or references
fd -e yaml -e yml -e json | xargs rg "ecsInfrastructureRole|ecsInstanceRole|ecsAutoscaleRole" -l
# Check for any trust relationships or role assumptions
rg "AssumeRole.*ecs|Principal.*ecs" --type json -A 3 -B 3
Length of output: 499
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (5)
120-120: LGTM: Resource specification follows least privilege principle
The resource ARN has been updated to be more specific, which aligns with AWS security best practices by limiting the scope of the CreateServiceLinkedRole permission.
276-297: LGTM: Well-structured permissions with appropriate restrictions
The statement implements proper access controls by:
- Restricting resource group names to the SystemsManagerForSAP prefix
- Enforcing specific tag requirements
- Limiting the scope of allowed tag keys
299-316: LGTM: Secure implementation of EC2 instance tagging
The statement implements proper security controls by:
- Only allowing tagging of instances that are already managed by SSM for SAP
- Restricting tag keys to the SystemsManagerForSAP prefix
318-332: Refer to previous review comment about over-permissive volume tagging
The concerns raised in the previous review about potential over-permissive tagging on EBS volumes are still valid.
334-350: Refer to previous review comment about broad application tagging permission
The concerns raised in the previous review about broad permission for application tagging on EBS volumes are still valid.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (6)
96-97: LGTM: Object type read permissions are appropriate
The addition of ListObjectTypeAttributes maintains the read-only nature of this statement and is properly scoped.
149-163: LGTM: Comprehensive message template management permissions
The new Wisdom permissions provide a complete set of CRUD operations for message templates and are properly restricted using tag-based access control.
195-208: LGTM: Segmentation permissions follow best practices
The new statement for segment definitions provides appropriate CRUD operations and is correctly scoped to Connect domains.
259-284: LGTM: Voice connector permissions are well-secured
The Chime SDK permissions are properly secured with both account-level conditions and tag-based access control where appropriate.
80-87: LGTM: Customer Profiles permissions are properly scoped
The new profile permissions are correctly scoped to Connect domains and follow the least privilege principle.
✅ Verification successful
Let me gather more information about the policy context and resource constraints.
Profile permissions are properly scoped and follow security best practices
The new Customer Profiles permissions are correctly implemented with appropriate resource constraints:
- All profile actions are restricted to Connect-specific domains via the resource ARN pattern:
arn:aws:profile:*:*:domains/amazon-connect-* - The permissions are logically grouped in the "AllowCustomerProfilesForConnectDomain" statement
- The segmentation and batch operations permissions align with existing profile actions in the policy
- Resource-level permissions ensure least-privilege access
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that these permissions are documented in AWS Customer Profiles API reference
rg -i "ListSegmentDefinitions|ListProfileAttributeValues|CreateSegmentEstimate|GetSegmentEstimate|BatchGetProfile|BatchGetCalculatedAttributeForProfile|GetSegmentMembership" README.md docs/
Length of output: 1042
Script:
#!/bin/bash
# Check the full policy statement to verify resource constraints
cat docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json
Length of output: 9553
286-338: LGTM: SES permissions follow security best practices
The SES-related permissions are well-structured with:
- Account-level conditions for all operations
- Specific resource ARNs where applicable
- Properly restricted PassRole permission
✅ Verification successful
Let me verify if this configuration set is referenced in other parts of the codebase or documentation to ensure consistency.
Based on the search results, I can now generate the final response:
SES configuration set permissions are properly scoped and secure
The SES configuration set permissions in the service-linked role policy are correctly configured:
- The configuration set name
configuration-set-for-connect-DO-NOT-DELETEis specifically used for Amazon Connect service - The permission is limited to
SendRawEmailaction only - Resource-level restriction is applied with the specific configuration set ARN
- Account-level condition ensures cross-account access is prevented
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the existence of the referenced configuration set
rg -i "configuration-set-for-connect-DO-NOT-DELETE" README.md docs/
Length of output: 245
Script:
#!/bin/bash
# Search for any mentions of SES configuration sets in the codebase
rg -i "configuration-set" -A 2 -B 2
# Search for any documentation or comments about SES configuration
rg -i "ses.*configuration" -A 2 -B 2
Length of output: 81334
docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json (4)
8-11: LGTM: CloudTrail permissions are properly scoped.
The addition of GetServiceLinkedChannel alongside CreateServiceLinkedChannel follows a logical pattern, allowing the service to both create and retrieve channel information. The resource ARN is appropriately scoped to Resource Explorer's service channel.
16-16: LGTM: API Gateway action simplification.
The change from an array to a single string for apigateway:GET is a valid simplification since there's only one action.
441-441: Caution: Broad resource access granted.
This comment was previously raised and is still valid. The change from specific resource ARNs to "Resource": "*" significantly broadens the scope of access. While this simplifies the policy, it grants more permissions than might be necessary.
Consider:
- Using more specific resource ARNs where possible
- Implementing condition keys to restrict access
- Splitting the policy into multiple statements with granular resource definitions
28-39: Verify the necessity of new service permissions.
The policy adds numerous new permissions for listing and describing resources across various AWS services. While these are read-only permissions, it's important to verify that Resource Explorer actually requires access to these new services.
Also applies to: 52-53, 56-56, 83-83, 88-90, 94-100, 128-128, 192-192, 233-233, 235-235, 237-241, 271-277, 280-280, 282-283, 407-413, 420-420, 435-435, 437-439
✅ Verification successful
Based on the search results, I can now provide a final response since we have sufficient evidence about the usage of these permissions across different AWS service role policies.
The new service permissions are justified and consistent with AWS service role patterns.
The added permissions for services like Airflow, AppFlow, AppMesh, and Amplify are legitimate as they are:
-
Used consistently across other AWS service roles with similar discovery/inventory purposes:
- AWS Config Service Role Policy
- AWS Support Service Role Policy
- ReadOnlyAccess and SecurityAudit policies
-
Follow the same read-only pattern as existing permissions, only requesting List* operations to discover resources
-
Required by Resource Explorer to maintain a comprehensive inventory of AWS resources, as evidenced by similar permissions in:
- AWSResourceExplorerFullAccess
- AWSResourceExplorerReadOnlyAccess
- AWSResourceExplorerServiceRolePolicy
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if these services are mentioned in Resource Explorer documentation or code
# Search for service names in Resource Explorer documentation
echo "Searching for service references in documentation..."
fd -e md -e txt . | xargs rg -i "Resource Explorer.*supports|supported.*Resource Explorer" -A 5 -B 5
# Search for service names in code
echo "Searching for service usage in code..."
rg -i "ResourceType.*(?:airflow|appflow|appmesh|auditmanager|backup|codeguru|connect|databrew|dms|ipam|greengrass|groundstation|guardduty|iotanalytics|iotevents|iotsitewise|sagemaker|ssm-incidents|transfer|workspaces)"
Length of output: 525
Script:
#!/bin/bash
# Let's try a different approach to find documentation or references about supported services
# Search for Resource Explorer documentation files
echo "Searching for Resource Explorer documentation..."
fd -e md -e rst -e txt . | xargs rg -i "resource.?explorer" -l
# Search for any AWS service type definitions or configurations
echo "Searching for service type definitions..."
rg -i "type.*=.*(?:airflow|appflow|appmesh|amplify)" -A 2 -B 2
# Look for any changelog or release notes
echo "Searching changelog or release notes..."
fd -g "*CHANGELOG*" -g "*release*" -g "*history*" -i | xargs rg -i "resource.?explorer.*support" -A 3 -B 3
# Check for any configuration or policy files
echo "Searching for service configurations..."
fd -e json -e yaml -e yml . | xargs rg -i "(?:airflow|appflow|appmesh|amplify).*list" -A 2 -B 2
Length of output: 115719
docs/source/_static/managed-policies/AWS_ConfigRole.json (14)
32-43: LGTM: AOSS permissions follow least privilege principle.
The added Amazon OpenSearch Service permissions are appropriately scoped to read-only operations, allowing AWS Config to effectively monitor and audit OpenSearch resources.
89-89: LGTM: AppStream permission is properly scoped.
The added DescribeAppBlockBuilders permission aligns with existing AppStream read-only permissions in the policy.
136-137: LGTM: AWS Backup permissions are appropriate for Config service.
The added restore testing permissions are read-only and allow AWS Config to monitor backup restore testing configurations.
Also applies to: 144-145
185-185: LGTM: CloudTrail permissions follow security best practices.
The added channel-related permissions are appropriately scoped to read-only operations.
Also applies to: 189-189
568-568: LGTM: Glue permissions are properly scoped.
The added trigger-related permissions maintain the read-only access pattern.
Also applies to: 574-574
659-659: LGTM: ImageBuilder permissions follow least privilege.
The added lifecycle policy permissions are appropriately scoped to read-only operations.
Also applies to: 669-669
676-676: LGTM: IoT permissions are properly scoped.
The added billing group permissions maintain the read-only access pattern.
Also applies to: 693-693
769-774: LGTM: IVS permissions follow security best practices.
The added permissions for IVS resources are appropriately scoped to read-only operations.
Also applies to: 777-782
905-910: LGTM: MediaConnect permissions are properly scoped.
The added bridge and gateway permissions maintain the read-only access pattern.
917-920: LGTM: MediaTailor permissions follow least privilege.
The added permissions for MediaTailor resources are appropriately scoped to read-only operations.
Also applies to: 922-923, 925-926
970-971: LGTM: Omics permissions are properly scoped.
The added workflow permissions maintain the read-only access pattern.
1256-1257: LGTM: Scheduler permissions follow security best practices.
The added schedule permissions are appropriately scoped to read-only operations.
1308-1308: LGTM: SSM SAP permission is properly scoped.
The added tag listing permission aligns with the policy's pattern of allowing tag discovery across services.
Line range hint 1-1401: Overall policy changes maintain security best practices.
All added permissions:
- Follow the principle of least privilege by being read-only
- Are logically grouped by service
- Enable AWS Config to effectively monitor and audit AWS resources
- Maintain consistent policy structure
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (10)
32-43: LGTM: AOSS permissions follow least privilege principle
The added Amazon OpenSearch Serverless permissions are appropriately scoped to read-only operations required for AWS Config's monitoring capabilities.
88-88: LGTM: AppStream permission is properly scoped
The added DescribeAppBlockBuilders permission aligns with existing AppStream read-only permissions.
135-136: LGTM: Backup restore testing permissions are appropriate
The added permissions for restore testing plans and selections maintain read-only access pattern and complement existing Backup service permissions.
Also applies to: 143-144
566-566: LGTM: Glue trigger permissions are properly scoped
The added permissions for Glue triggers maintain the read-only access pattern and complement existing Glue service permissions.
Also applies to: 572-572
767-772: LGTM: IVS permissions follow consistent pattern
The added IVS permissions maintain read-only access and follow a consistent pattern of Get/List operations for various IVS resources.
Also applies to: 775-780
903-906: LGTM: MediaConnect permissions are properly scoped
The added MediaConnect permissions for bridges and gateways maintain read-only access pattern.
Also applies to: 908-908
915-918: LGTM: MediaTailor permissions follow consistent pattern
The added MediaTailor permissions maintain read-only access and follow a consistent pattern of Describe/List operations.
Also applies to: 920-921, 923-924
968-969: LGTM: Omics permissions are properly scoped
The added Omics workflow permissions maintain read-only access pattern.
1254-1255: LGTM: Scheduler permissions are properly scoped
The added Scheduler permissions maintain read-only access pattern.
184-184: Case inconsistency in CloudTrail service name
The inconsistent casing of CloudTrail service name was previously identified.
Also applies to: 188-188
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14)
87-88: New account service permissions look appropriate
The added permissions getRegionOptStatus and listRegions are read-only operations that allow checking region status and listing available regions. These are reasonable permissions for the support role.
133-147: AppConfig permissions align with support requirements
The added AppConfig permissions are appropriately scoped to read-only operations necessary for troubleshooting application configurations.
196-202: Application-signals permissions are properly constrained
The new application-signals permissions are limited to read-only access for service metrics and objectives, which is appropriate for support scenarios.
1136-1148: EC2 IPAM permissions are appropriate
The added EC2 IP Address Manager permissions are properly scoped to read-only operations necessary for troubleshooting IP addressing issues.
1199-1200: EKS pod identity permissions are well-scoped
The new EKS permissions for pod identity associations are appropriately limited to read-only access.
1251-1252: EFS backup permissions are properly constrained
The added EFS permissions for backup policy and replication configurations are appropriately read-only.
1268-1270: ELB trust store permissions are appropriate
The new Elastic Load Balancer permissions for trust stores are properly limited to read operations.
2672-2678: Route53 Profiles permissions are well-defined
The added Route53 Profiles permissions are appropriately scoped to read-only operations necessary for DNS troubleshooting.
3432-3435: WorkSpaces permissions are appropriate
The added WorkSpaces permissions for application associations and pools are properly limited to read operations.
3447-3453: X-Ray permissions are well-scoped
The new X-Ray permissions are appropriately limited to read-only operations for monitoring and troubleshooting.
2357-2362: OSIS permissions require review
The OpenSearch Ingestion Service permissions grant broad read access to pipelines and blueprints.
#!/bin/bash
# Check for documentation about OSIS support requirements
rg -i "osis.*support" --type mdConsider limiting to specific pipeline operations needed for common support scenarios.
365-386: 🛠️ Refactor suggestion
Review extensive Bedrock AI permissions
The added Bedrock permissions grant broad read access to AI/ML resources including agents, models, and knowledge bases. While read-only, these permissions could expose sensitive ML assets.
#!/bin/bash
# Check for documentation justifying these Bedrock permissions
rg -i "bedrock.*support" --type mdConsider implementing more granular permissions based on specific support scenarios rather than granting access to all Bedrock resources.
2929-2936: 🛠️ Refactor suggestion
SecurityHub permissions require justification
The new SecurityHub permissions provide broad access to configuration policies and aggregators.
#!/bin/bash
# Check for SecurityHub support documentation
rg -i "securityhub.*support.*configuration" --type mdConsider restricting access to only the specific SecurityHub resources needed for support cases.
117-132: Verify necessity of broad AOSS permissions
The added Amazon OpenSearch Serverless (AOSS) permissions grant extensive read access to collections, policies, configurations and endpoints. While these are read-only permissions, consider if all of them are necessary for support purposes.
Consider grouping these permissions into more focused permission sets based on specific support scenarios rather than granting all read permissions.
✅ Verification successful
The previous search was too narrow. Let's look at the actual policy file and related documentation to understand the context of these permissions and their relationship to AWS Support functionality.
Looking at the policy file content, I can now generate a final response since I have enough context to verify the necessity of these AOSS permissions.
AOSS read permissions are appropriate for AWS Support role
These Amazon OpenSearch Serverless (AOSS) read-only permissions are appropriate for the AWS Support service role for several reasons:
- They are consistent with the overall pattern in this policy where AWS Support needs read access to diagnose and troubleshoot customer issues across AWS services
- The permissions are strictly read-only (get/list/describe/batch get operations) with no write/modify capabilities
- They allow AWS Support to:
- View collection configurations and status
- Access policy information needed for security analysis
- Check endpoint configurations for connectivity issues
- View lifecycle policies for operational assessment
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if these AOSS permissions are commonly used in support scenarios
rg -i "aoss.*support" --type md
Length of output: 131
Script:
#!/bin/bash
# Let's check the broader context of this policy file and related documentation
cat docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json
# Also search for any documentation about AWS Support service role permissions
fd -e md -e txt . | xargs rg -i "aws.*support.*role|service.*role.*support" -A 3
Length of output: 142916
udondan
force-pushed
the
update-aws-managed-policies
branch
from
623b6be
to
3ed8c5a
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (4)
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (1)
71-75: Consider additional Bedrock restrictions for model deployment.While the current Bedrock restrictions are good, also consider denying:
bedrock:CreateModel- prevents creation of custom modelsbedrock:CreateModelDeployment- prevents deployment of potentially malicious modelsbedrock:UpdateModelDeployment- prevents modifications to existing deploymentsdocs/source/_static/managed-policies/AmazonECS_FullAccess.json (2)
Line range hint
5-127: Consider implementing additional resource-level restrictions.While the broad permissions are typical for a FullAccess policy, consider adding resource-level restrictions for sensitive operations like
ec2:RunInstancesandec2:CreateVpcto align with security best practices.
Line range hint
156-213: LGTM! Well-structured PassRole permissions.The PassRole permissions are properly segmented and conditioned based on service-specific requirements. Consider adding documentation about the expected role naming patterns for better maintainability.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (1)
Line range hint
1-3454: Policy expansion aligns with AWS Support requirements but warrants security review.The policy updates add extensive read-only permissions across multiple AWS services, particularly for newer services like Bedrock, AOSS, and AppConfig. While these additions are necessary for AWS Support functionality, the significant expansion in scope deserves careful consideration.
Key observations:
- All new permissions are read-only operations
- Permissions align with AWS Support's need to access and troubleshoot various services
- No write/modify permissions added, maintaining the principle of least privilege
Consider implementing additional monitoring and logging for these expanded permissions, particularly for sensitive services like Bedrock and AOSS.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
lib/generated/aws-managed-policies/cdk-iam-floyd.tsis excluded by!**/generated/**lib/generated/aws-managed-policies/iam-floyd.tsis excluded by!**/generated/**
📒 Files selected for processing (82)
docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSBackupFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json(2 hunks)docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json(1 hunks)docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json(11 hunks)docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json(2 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json(2 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json(2 hunks)docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json(25 hunks)docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWS_ConfigRole.json(14 hunks)docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonBedrockReadOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json(2 hunks)docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json(1 hunks)docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json(1 hunks)docs/source/_static/managed-policies/AmazonECS_FullAccess.json(8 hunks)docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSComputePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSServicePolicy.json(3 hunks)docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonQDeveloperAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonQFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json(1 hunks)
⛔ Files not processed due to max files limit (19)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json
- docs/source/_static/managed-policies/CloudWatchInternetMonitorFullAccess.json
- docs/source/_static/managed-policies/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.json
- docs/source/_static/managed-policies/CloudWatchSyntheticsFullAccess.json
- docs/source/_static/managed-policies/ElasticLoadBalancingFullAccess.json
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/ReadOnlyAccess.json
- docs/source/_static/managed-policies/ResourceGroupsTaggingAPITagUntagSupportedResources.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/SecurityAudit.json
- docs/source/_static/managed-policies/ViewOnlyAccess.json
- docs/source/_static/managed-policies/index.json
💤 Files with no reviewable changes (3)
- docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json
🚧 Files skipped from review as they are similar to previous changes (71)
- docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSBackupFullAccess.json
- docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json
- docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json
- docs/source/_static/managed-policies/AWSDataSyncFullAccess.json
- docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json
- docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json
- docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json
- docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json
- docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json
- docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSComputePolicy.json
- docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSServicePolicy.json
- docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonQDeveloperAccess.json
- docs/source/_static/managed-policies/AmazonQFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json
🔇 Additional comments (43)
docs/source/_static/managed-policies/AmazonSNSFullAccess.json (2)
5-9: LGTM: Format change aligns with best practices.
The change from array to string format for single action specification is a good practice improvement.
10-32: Consider adding spend limit safeguards.
While the new SMS voice permissions are properly restricted via the SNS service condition, the inclusion of SetTextMessageSpendLimitOverride without additional safeguards could lead to unexpected costs. Consider:
- Adding a condition to limit the maximum spend limit that can be set
- Implementing additional monitoring/alerting for spend limit changes
Let's check if other policies implement spend limit safeguards:
✅ Verification successful
Let me search for any other SMS or spend limit related policies to get a complete picture.
Let me try one more search to find any AWS managed policies that might have similar SMS permissions:
The spend limit concern is valid but should be handled outside IAM
After verification, I found that spend limit conditions are not typically implemented at the IAM policy level. This is because:
- AWS best practices recommend managing spend controls through AWS Budgets and Cost Explorer
- The
SetTextMessageSpendLimitOverridepermission is appropriately restricted by theaws:CalledViaLastcondition to ensure it's only called through SNS - Adding spend limit conditions in IAM policies would make them less maintainable and require updates whenever limits need adjustment
Instead of modifying this policy, implement spend controls through:
- AWS Budgets for account-level spend monitoring
- CloudWatch alarms for SMS usage metrics
- AWS Cost Explorer for detailed cost analysis
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for spend limit conditions in other policies
# Expected: Find examples of spend limit safeguards
rg -g '*.json' -B 5 -A 5 'SetTextMessageSpendLimitOverride'
Length of output: 1162
Script:
#!/bin/bash
# Search for SMS and spend limit related policies
rg -g '*.json' -B 5 -A 5 'sms.*spend|spend.*limit'
Length of output: 52
Script:
#!/bin/bash
# Search for SMS voice permissions in other AWS managed policies
rg -g '*.json' -B 10 -A 10 '"sms-voice:"'
Length of output: 43
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (4)
Line range hint 128-137: LGTM! Well-scoped SSM permissions.
The SSM permissions are properly restricted to ECS-specific parameters using an explicit resource ARN pattern.
Line range hint 138-155: LGTM! Well-controlled cleanup permissions.
The deletion permissions are properly restricted to ECS-managed resources through the CloudFormation stack name condition.
Line range hint 231-247: LGTM! Well-controlled tagging permissions.
The tagging permissions are properly restricted to specific ELB creation actions, following AWS tagging best practices.
Line range hint 214-230: Verify the addition of autoscaling service-linked role.
The addition of autoscaling.amazonaws.com to allowed services appears related to ECS autoscaling capabilities.
✅ Verification successful
Based on the search results, I can see that autoscaling.amazonaws.com is commonly included in service-linked role policies across many AWS services, particularly those that need to interact with Auto Scaling. For ECS specifically, the search shows that both autoscaling.amazonaws.com and ecs.application-autoscaling.amazonaws.com are standard inclusions in the ECS full access policy to enable auto scaling capabilities.
The addition of autoscaling.amazonaws.com to the service-linked role creation policy is valid and follows AWS service integration patterns.
Key evidence:
- Found in AmazonECS_FullAccess.json alongside other ECS-related auto scaling permissions
- Consistently used across other AWS services that integrate with Auto Scaling
- Required for ECS to create and manage Auto Scaling resources
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify if autoscaling service-linked role is commonly included in similar policies
# Expected: Find other policies that also allow creating service-linked role for autoscaling
rg -l "autoscaling.amazonaws.com.*service-linked-role"
Length of output: 56
Script:
#!/bin/bash
# Let's try a broader search for autoscaling.amazonaws.com in IAM policies
rg -A 5 -B 5 "autoscaling\.amazonaws\.com" docs/
# Also search for similar service-linked role patterns
rg -A 5 -B 5 "iam:CreateServiceLinkedRole" docs/
# Check if there are other managed policy files
fd ".*json$" docs/source/_static/managed-policies/
Length of output: 350838
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (6)
96-97: LGTM: Profile Object Type read permissions are consistent
The addition of ListObjectTypeAttributes aligns with existing read permissions for profile object types and maintains proper resource constraints.
149-163: LGTM: Comprehensive Wisdom message template permissions with proper constraints
The new message template permissions are properly secured with the AmazonConnectEnabled tag condition, ensuring these capabilities are only available to tagged resources.
195-208: LGTM: Well-structured segmentation permissions
The new segmentation permissions are properly organized and correctly scoped to Connect domain segment definitions.
259-284: LGTM: Secure Chime SDK Voice Connector access controls
The Voice Connector permissions are well-structured with:
- Proper resource-level permissions
- Account-level restrictions
- Additional tag-based control for get operations
286-338: LGTM: Well-secured SES and IAM permissions
The new SES and IAM permissions demonstrate strong security practices:
- Account-level restrictions on SES operations
- Specific resource pattern for email identity management
- Properly constrained PassRole permission with service principal condition
80-87: LGTM: Customer Profiles permissions are properly scoped
The new Customer Profiles permissions are correctly scoped to Connect domains and follow AWS least privilege principles.
✅ Verification successful
Let me gather more information about these permissions by checking if they are documented in AWS API references or documentation files.
Let me check if these permissions are part of a new feature or documented in any changelog or release notes.
Based on the verification results, I can generate the final response:
Customer Profiles permissions are properly configured with appropriate resource constraints
The new Customer Profiles permissions are correctly scoped to Amazon Connect domains with the resource pattern arn:aws:profile:*:*:domains/amazon-connect-*, which follows AWS security best practices by limiting access to only Connect-specific profile domains. The permissions are part of a cohesive set of Customer Profiles API actions that enable profile management and segmentation capabilities.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that these permissions are documented in AWS Customer Profiles API
rg -i "ListSegmentDefinitions|ListProfileAttributeValues|CreateSegmentEstimate|GetSegmentEstimate|BatchGetProfile|BatchGetCalculatedAttributeForProfile|GetSegmentMembership" docs/
Length of output: 1032
Script:
#!/bin/bash
# Search for API documentation or references for these permissions
rg -i "ListSegmentDefinitions|ListProfileAttributeValues|CreateSegmentEstimate|GetSegmentEstimate|BatchGetProfile|BatchGetCalculatedAttributeForProfile|GetSegmentMembership" docs/ -A 3 -B 3
Length of output: 1716
Script:
#!/bin/bash
# Search for any changelog or release notes mentioning these Customer Profiles features
rg -i "customer profiles|profile segment" docs/ --type md --type txt
Length of output: 70
docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json (4)
8-11: LGTM: CloudTrail permissions are properly scoped.
The CloudTrail permissions are well-scoped with:
- Specific actions:
CreateServiceLinkedChannelandGetServiceLinkedChannel - Resource pattern limited to Resource Explorer service channels
16-16: LGTM: API Gateway permission is properly scoped.
The change simplifies the action to apigateway:GET while maintaining specific resource constraints.
441-441: Duplicate comment: Broad resource access has been previously flagged.
This broad resource access was already identified in a previous review. The concern about using "Resource": "*" remains valid.
Line range hint 28-439: Verify the necessity of newly added permissions.
The policy adds numerous list/describe permissions across various AWS services. While these are read-only operations, which aligns with Resource Explorer's functionality, we should verify if all new permissions are required.
Let's verify the usage of these permissions:
✅ Verification successful
Let me gather more specific information about Resource Explorer's functionality and permissions:
Let me check the specific Resource Explorer service role policy to understand the intended permissions:
Based on the examination of the AWSResourceExplorerServiceRolePolicy, I can now provide the final response:
The extensive list of read-only permissions is appropriate for Resource Explorer's functionality
The permissions in the service role policy are justified because:
- Resource Explorer is designed to discover and search across all AWS resources in an account
- All permissions are strictly read-only (List/Describe/Get operations)
- These permissions align with Resource Explorer's core functionality of providing a comprehensive view of resources across AWS services
- The changelog entries show that Resource Explorer permissions have been carefully managed and updated over time
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for Resource Explorer documentation or code that justifies these permissions
# Look for Resource Explorer documentation
echo "Searching for documentation..."
fd README.md | xargs rg -l "Resource Explorer"
# Look for permission usage patterns
echo "Searching for permission usage patterns..."
rg -l "airflow:ListEnvironments|appflow:ListFlows|appmesh:ListMeshes"
# Look for test cases
echo "Searching for test files..."
fd -e test.js -e test.py -e test.java | xargs rg -l "Resource Explorer"
Length of output: 1197
Script:
#!/bin/bash
# Search for Resource Explorer documentation and related files
echo "=== Searching Resource Explorer documentation ==="
rg -A 5 -B 5 "Resource Explorer" docs/
# Search for policy files mentioning Resource Explorer
echo -e "\n=== Searching policy files ==="
fd -e json -e yaml | xargs rg -l "resource-explorer"
# Look for changelog entries about Resource Explorer permissions
echo -e "\n=== Searching changelog entries ==="
rg -A 10 "resource-explorer" CHANGELOG/
Length of output: 2607
Script:
#!/bin/bash
# Check the Resource Explorer service role policy content
echo "=== Resource Explorer Service Role Policy ==="
cat docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json
# Look for any documentation about supported resource types
echo -e "\n=== Resource Explorer Supported Resources ==="
rg -A 10 "supported.*resource.*types" docs/
Length of output: 17282
docs/source/_static/managed-policies/AWS_ConfigRole.json (12)
32-43: LGTM: AOSS permissions follow security best practices
The added Amazon OpenSearch Serverless permissions are appropriately scoped to read-only operations, allowing AWS Config to monitor and evaluate OpenSearch Serverless resources effectively.
89-89: LGTM: AppStream permission is consistent with existing policy
The added DescribeAppBlockBuilders permission maintains the read-only pattern established for AppStream resources.
136-137: LGTM: Backup permissions enhance restore testing visibility
The added permissions allow AWS Config to monitor backup restore testing configurations, maintaining the read-only access pattern.
Also applies to: 144-145
185-185: LGTM: CloudTrail permissions maintain security posture
The added channel-related permissions allow AWS Config to monitor CloudTrail channel configurations while maintaining read-only access.
Also applies to: 189-189
568-568: LGTM: Glue permissions follow established patterns
The added trigger-related permissions maintain read-only access for monitoring Glue resources.
Also applies to: 574-574
659-659: LGTM: ImageBuilder permissions maintain least privilege
The added lifecycle policy permissions follow the read-only pattern for monitoring ImageBuilder resources.
Also applies to: 669-669
676-676: LGTM: IoT permissions follow security best practices
The added billing group permissions maintain read-only access for monitoring IoT resources.
Also applies to: 693-693
769-774: LGTM: IVS permissions maintain security posture
The added permissions for encoder configurations, playback restrictions, stages, and storage configurations follow the read-only pattern.
Also applies to: 777-782
905-908: LGTM: MediaConnect permissions follow least privilege
The added bridge and gateway permissions maintain read-only access for monitoring MediaConnect resources.
Also applies to: 910-910
917-920: LGTM: MediaTailor permissions maintain security best practices
The added permissions for channels, live sources, source locations, and VOD sources follow the read-only pattern.
Also applies to: 922-923, 925-926
970-971: LGTM: Omics permissions follow established patterns
The added workflow permissions maintain read-only access for monitoring Omics resources.
1256-1257: LGTM: Scheduler permissions maintain least privilege
The added schedule permissions follow the read-only pattern for monitoring EventBridge Scheduler resources.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (10)
32-43: LGTM: AOSS permissions follow least privilege principle
The added OpenSearch Serverless permissions are appropriately scoped to read-only operations required for AWS Config's monitoring capabilities.
88-88: LGTM: AppStream permission is properly scoped
The added AppStream permission follows the existing pattern and is correctly limited to read-only access.
135-136: LGTM: Backup permissions are properly scoped
The added AWS Backup permissions for restore testing features are appropriately limited to read-only operations.
Also applies to: 143-144
566-566: LGTM: Glue permissions follow least privilege principle
The added Glue permissions for triggers are correctly scoped to read-only operations.
Also applies to: 572-572
767-769: LGTM: IVS permissions are properly scoped
The added IVS permissions for encoder configurations, playback restrictions, stages, and storage configurations are appropriately limited to read-only access.
Also applies to: 771-772, 775-777, 779-780
903-903: LGTM: MediaConnect permissions follow least privilege principle
The added MediaConnect permissions for bridges and gateways are correctly scoped to read-only operations.
Also applies to: 905-906, 908-908
915-918: LGTM: MediaTailor permissions are properly scoped
The added MediaTailor permissions for channels, sources, and locations are appropriately limited to read-only access.
Also applies to: 920-921, 923-924
968-969: LGTM: Omics permissions follow least privilege principle
The added Omics permissions for workflows are correctly scoped to read-only operations.
1254-1255: LGTM: Scheduler permissions are properly scoped
The added Scheduler permissions are appropriately limited to read-only access.
184-184: Fix case inconsistency in CloudTrail service name
The service name has inconsistent casing: cloudTrail vs cloudtrail.
Also applies to: 188-188
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (5)
87-88: LGTM: Account region management permissions are appropriate.
The addition of account:getRegionOptStatus and account:listRegions permissions is reasonable for AWS Support to view and troubleshoot region-related issues.
117-132: LGTM: AOSS permissions follow least privilege principle.
The new Amazon OpenSearch Serverless permissions are appropriately scoped to read-only operations, allowing AWS Support to assist with AOSS-related issues while maintaining security.
828-844: LGTM: Deadline service permissions are appropriately scoped.
The new AWS Thinkbox Deadline permissions are limited to list operations, which is appropriate for support functionality while maintaining security.
1136-1148: LGTM: EC2 IPAM permissions follow least privilege.
The new EC2 IPAM-related permissions are appropriately limited to read-only operations, allowing AWS Support to assist with IP address management issues.
365-386: Verify the necessity of extensive Bedrock permissions.
The addition of numerous AWS Bedrock permissions significantly expands the policy's scope into machine learning operations. While all permissions are read-only, this represents a substantial increase in access to potentially sensitive ML resources.
✅ Verification successful
Bedrock read-only permissions are appropriate for AWS Support role
The addition of Bedrock read-only permissions is consistent with AWS Support's need to access and troubleshoot AWS services on behalf of customers. The permissions are:
- Limited to read-only operations (get/list/describe)
- Part of the standard pattern where AWS Support requires visibility into all AWS services to provide customer support
- Similar to existing permissions for other AI/ML services like SageMaker, Comprehend, etc. in the same policy
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if Bedrock permissions are documented in AWS Support scope
# Expected results: Documentation confirming Bedrock support requirements
echo "Searching for Bedrock support documentation:"
rg -i "bedrock.*support" --type md
echo "Checking for existing Bedrock-related permissions:"
rg "bedrock:" AWSSupportServiceRolePolicy.json
Length of output: 366
Script:
#!/bin/bash
# Let's verify the correct path and content of the policy file
fd -e json "AWSSupportServiceRolePolicy"
# Then search for any documentation about AWS Support role permissions
fd -e md . | xargs rg -i "support.*role|service.*role.*support"
# Check for any existing documentation about Bedrock support
fd -e md . | xargs rg -i "bedrock"
Length of output: 3335
Script:
#!/bin/bash
# Let's check the content of the policy file to understand the full context
cat docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json
# Let's also check recent changelog entries that might explain these additions
fd -e md . -d 1 -p "CHANGELOG" | xargs ls -t | head -n 1 | xargs cat
Length of output: 143028
| @@ -332,6 +351,7 @@ | |||
| "ec2:DescribeTrafficMirrorTargets", | |||
| "ec2:DescribeVolumeAttribute", | |||
| "ec2:DescribeVolumes", | |||
| "ec2:DescribeVpcEndpoints", | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Remove redundant EC2 permission
The ec2:DescribeVpcEndpoints permission is redundant as it's already covered by the existing ec2:Describe* wildcard permission.
- "ec2:DescribeVpcEndpoints",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "ec2:DescribeVpcEndpoints", |
udondan
force-pushed
the
update-aws-managed-policies
branch
from
3ed8c5a
to
739eae9
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (5)
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (2)
71-75: LGTM for Bedrock actions, consider additional restrictionsThe current deny list appropriately prevents model creation and invocation. Consider also denying:
bedrock:CreateCustomModelbedrock:CreateProvisionedModelbedrock:CreateModelCustomizationJob
66-95: Consider additional commonly abused actionsConsider adding these critical actions to the deny list:
cloudformation:CreateStack- prevents infrastructure deploymentiam:CreateServiceLinkedRole- prevents privilege escalationorganizations:LeaveOrganization- prevents account isolationorganizations:DeleteOrganization- prevents organizational dismantlingkms:ScheduleKeyDeletion- prevents crypto key deletionroute53:DeleteHostedZone- prevents DNS hijackingdocs/source/_static/managed-policies/AmazonECS_FullAccess.json (1)
Line range hint
5-127: Consider implementing additional security controls for broad permissions.While these permissions are typical for a FullAccess policy, consider implementing additional security controls:
- Use AWS Organizations SCPs to restrict sensitive actions in production
- Enable CloudTrail logging for these actions
- Implement resource tagging strategy to limit scope of ec2:RunInstances
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (1)
286-338: LGTM: Well-structured SES permissions with proper security controlsThe SES-related permissions follow security best practices:
- Account-level conditions on all operations
- Specific resource patterns for identities and configuration sets
- Properly restricted PassRole permission
Consider documenting the dependency on the
AmazonConnectEmailSESAccessRoleand the purpose of theconfiguration-set-for-connect-DO-NOT-DELETEconfiguration set for operational clarity.docs/source/_static/managed-policies/AWS_ConfigRole.json (1)
Line range hint
701-773: Consider consolidating IoT permissions using wildcards.The IoT and IoTFleetwise sections contain numerous granular permissions. Consider using wildcards for related operations to improve maintainability while maintaining the principle of least privilege.
Example consolidation:
- "iot:DescribeBillingGroup", - "iot:ListBillingGroups", + "iot:*BillingGroup*", - "iotfleetwise:GetDecoderManifest", - "iotfleetwise:ListDecoderManifests", - "iotfleetwise:ListDecoderManifestNetworkInterfaces", - "iotfleetwise:ListDecoderManifestSignals", + "iotfleetwise:*DecoderManifest*",
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
lib/generated/aws-managed-policies/cdk-iam-floyd.tsis excluded by!**/generated/**lib/generated/aws-managed-policies/iam-floyd.tsis excluded by!**/generated/**
📒 Files selected for processing (82)
docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSBackupFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json(2 hunks)docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json(1 hunks)docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json(26 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json(11 hunks)docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json(2 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json(2 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json(2 hunks)docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json(25 hunks)docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWS_ConfigRole.json(27 hunks)docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonBedrockReadOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json(2 hunks)docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json(1 hunks)docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json(1 hunks)docs/source/_static/managed-policies/AmazonECS_FullAccess.json(8 hunks)docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSComputePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSServicePolicy.json(3 hunks)docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonQDeveloperAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonQFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json(1 hunks)
⛔ Files not processed due to max files limit (19)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json
- docs/source/_static/managed-policies/CloudWatchInternetMonitorFullAccess.json
- docs/source/_static/managed-policies/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.json
- docs/source/_static/managed-policies/CloudWatchSyntheticsFullAccess.json
- docs/source/_static/managed-policies/ElasticLoadBalancingFullAccess.json
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/ReadOnlyAccess.json
- docs/source/_static/managed-policies/ResourceGroupsTaggingAPITagUntagSupportedResources.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/SecurityAudit.json
- docs/source/_static/managed-policies/ViewOnlyAccess.json
- docs/source/_static/managed-policies/index.json
💤 Files with no reviewable changes (3)
- docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json
🚧 Files skipped from review as they are similar to previous changes (71)
- docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSBackupFullAccess.json
- docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json
- docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json
- docs/source/_static/managed-policies/AWSDataSyncFullAccess.json
- docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json
- docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json
- docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json
- docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json
- docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json
- docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSComputePolicy.json
- docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSServicePolicy.json
- docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonQDeveloperAccess.json
- docs/source/_static/managed-policies/AmazonQFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json
🔇 Additional comments (51)
docs/source/_static/managed-policies/AmazonSNSFullAccess.json (2)
5-9: LGTM: Format optimization for single action.
The change from array to string format for single action is aligned with AWS best practices.
10-32: Consider separating administrative and operational permissions.
While the condition block properly restricts access via SNS, the statement combines both administrative capabilities (like DescribeSpendLimits, DescribeAccountAttributes) with operational ones (like SendTextMessage). Consider splitting these into separate statements to better align with the principle of separation of duties.
Let's verify if this combined approach is common in other AWS managed policies:
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (8)
67-70: LGTM for ECS actions, reconsider ECR authentication
The comment from the previous review about ecr:GetAuthorizationToken is still valid. While denying ECS resource creation actions is appropriate, blocking ECR authentication could hinder incident investigation.
76-79: LGTM for write operations, reconsider read restrictions
The previous review's concerns about denying s3:GetObject and s3:ListBucket remain valid. While preventing bucket creation and CORS modifications is appropriate, blocking read operations could impede incident investigation.
80-81: LGTM for SageMaker restrictions
The additions appropriately prevent the creation of SageMaker resources that could be abused by compromised credentials.
82-85: LGTM for STS actions, reconsider SES read operations
The previous review's concerns about denying SES read operations remain valid. While preventing STS token generation is appropriate for quarantine, blocking SES read operations could impede incident investigation.
86-89: LGTM for resource creation restrictions
The additions appropriately prevent the creation of new resources across Amplify, CodeBuild, and Glue services, which aligns with quarantine objectives.
90-92: LGTM for IAM destructive actions, reconsider ListUsers
The previous review's concerns about denying iam:ListUsers remain valid. While preventing destructive IAM actions is appropriate, blocking user enumeration could impede incident investigation.
93-95: LGTM for MediaPackage, reconsider read operations
The previous review's concerns about denying Lambda and SNS read operations remain valid. While preventing MediaPackage channel creation is appropriate, blocking read operations could impede incident investigation.
66-66: LGTM for SavingsPlans restriction
Preventing the creation of savings plans is appropriate to avoid potential financial impact from compromised credentials.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (5)
Line range hint 128-137: LGTM! Well-scoped SSM permissions.
The SSM permissions are properly restricted to ECS-specific parameters using an appropriate resource pattern.
Line range hint 138-155: LGTM! Well-controlled cleanup permissions.
The deletion permissions are properly restricted to ECS-managed resources through the CloudFormation stack name condition.
Line range hint 156-213: LGTM! Excellent PassRole permission structure.
The PassRole permissions follow AWS best practices by:
- Separating concerns into distinct statements
- Using specific role patterns for each use case
- Implementing proper service principal conditions
Line range hint 214-230: LGTM! Appropriate service-linked role permissions.
The service-linked role creation is properly restricted to necessary AWS services, including the newly added autoscaling service.
Line range hint 231-247: LGTM! Well-implemented tagging controls.
The policy follows AWS best practices by restricting tagging to resource creation time, ensuring tag consistency and preventing unauthorized tag modifications.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (5)
80-87: LGTM: Well-scoped Customer Profiles permissions
The new permissions for Customer Profiles operations are properly scoped to Connect domains and follow the principle of least privilege.
96-97: LGTM: Appropriate read-only permissions for Profile Object Types
The added read-only permissions are well-scoped and complement the existing profile object operations.
149-163: LGTM: Well-structured Wisdom message template permissions
The new message template permissions are properly secured with tag-based conditions and provide comprehensive template management capabilities.
259-284: LGTM: Secure Chime SDK Voice Connector permissions
The Voice Connector permissions are well-secured with:
- Account-level conditions to prevent cross-account access
- Tag-based condition for get operation
- Resource-level permissions
195-208: LGTM: Well-defined segmentation permissions
The new segmentation permissions are properly scoped to Connect domain segment definitions and follow AWS IAM best practices.
✅ Verification successful
ARN pattern for segment definitions is consistent
The verification confirms that the ARN pattern arn:aws:profile:*:*:domains/amazon-connect-*/segment-definitions/* is used consistently throughout the policy file, appearing only once in the newly added segmentation permissions block. This indicates proper scoping and no conflicting resource patterns.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that the segment definition ARN pattern is consistent across the policy
rg -U "arn:aws:profile:[^\"]+segment-definitions"
Length of output: 206
docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json (4)
8-11: LGTM: CloudTrail channel permissions are appropriately scoped.
The addition of GetServiceLinkedChannel alongside CreateServiceLinkedChannel follows the principle of least privilege by:
- Using specific actions instead of wildcards
- Limiting the resource scope to Resource Explorer's service-linked channels
16-16: LGTM: API Gateway permission is appropriately scoped.
The change simplifies the action format while maintaining the same level of access.
Line range hint 28-439: LGTM: New list/describe permissions align with Resource Explorer's functionality.
The added permissions are read-only operations that allow Resource Explorer to discover and index AWS resources, which is its core functionality. These permissions follow AWS best practices by:
- Using specific list/describe actions instead of wildcards
- Avoiding write permissions
441-441: Consider using more granular resource restrictions.
While Resource Explorer needs broad read access to function, using "Resource": "*" grants permissions across all resources. This was previously flagged in past reviews.
Let's analyze the impact and necessity of this broad access:
#!/bin/bash
# Check if any of the actions support resource-level permissions
# This helps determine if more granular resource restrictions are possible
echo "Checking AWS IAM documentation for actions that support resource-level permissions..."
actions=(
"cloudwatch:DescribeAlarms"
"dynamodb:ListTables"
"ec2:DescribeInstances"
"rds:DescribeDBInstances"
"s3:ListBucket"
)
for action in "${actions[@]}"; do
service=$(echo $action | cut -d: -f1)
operation=$(echo $action | cut -d: -f2)
echo "Checking $action..."
# Use AWS IAM documentation to check if the action supports resource-level permissions
aws iam list-actions-with-resource-level-support --service-namespace $service 2>/dev/null | \
jq -r --arg op "$operation" '.actions[] | select(.action==$op) | .resourceLevelSupport'
donedocs/source/_static/managed-policies/AWS_ConfigRole.json (7)
32-43: LGTM: AOSS permissions follow least privilege principle.
The added Amazon OpenSearch Serverless (AOSS) permissions are well-structured and follow the principle of least privilege by only including read-only operations necessary for AWS Config to monitor AOSS resources.
373-373: Remove redundant EC2 permission.
The ec2:DescribeVpcEndpoints permission is redundant as it's already covered by the existing ec2:Describe* wildcard permission.
673-676: LGTM: Identity Store permissions are appropriately scoped.
The added AWS IAM Identity Store permissions are correctly limited to read-only operations for group management functionality.
819-839: LGTM: IVS and IVSChat permissions are well-organized.
The Amazon Interactive Video Service (IVS) and IVS Chat permissions are properly structured with clear separation between core IVS and chat-specific operations.
962-983: LGTM: MediaConnect and MediaTailor permissions follow service patterns.
The permissions for MediaConnect and MediaTailor services follow AWS service patterns by including both describe and list operations for comprehensive resource discovery.
1442-1451: LGTM: VPC Lattice permissions are comprehensive.
The VPC Lattice permissions provide complete read-only access necessary for AWS Config to monitor VPC Lattice resources and their configurations.
1060-1064: Verify the necessity of payment-cryptography permissions.
The addition of payment-cryptography service permissions requires careful consideration due to its sensitive nature.
✅ Verification successful
Let me gather more context about AWS Config rules and resources to verify if these permissions are necessary.
Payment-cryptography permissions are appropriately included in AWS Config role policies
The payment-cryptography permissions are justified as they are consistently present across AWS Config related IAM policies (AWS_ConfigRole.json and AWSConfigServiceRolePolicy.json) and follow the same read-only permission pattern as other AWS services. This indicates they are part of AWS Config's standard service role requirements for discovering and auditing payment-cryptography resources.
The changelog entry in v0.601.0.md also confirms the intentional addition of payment-cryptography service support.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any AWS Config rules or resources that depend on payment-cryptography service
rg -A 5 "payment-cryptography" --type yaml --type json
Length of output: 3262
Script:
#!/bin/bash
# Search for AWS Config rules or resources related to payment-cryptography in yaml/json files
rg -B 5 -A 5 "payment-cryptography|PaymentCryptography" --type yaml --type json
# Look for any documentation or readme files that might explain the usage
fd -e md -e txt -X rg -i "payment.?cryptography|aws.?config"
Length of output: 4844
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (8)
32-43: LGTM: Amazon OpenSearch Serverless (AOSS) permissions are properly structured.
The new AOSS permissions follow a logical pattern:
- Batch operations for collections, lifecycle policies, and VPC endpoints
- Access policy and security configurations
- List operations for various resources
44-49: LGTM: App Integrations permissions follow best practices.
The permissions are properly scoped to read-only operations (Get/List) which aligns with AWS Config's monitoring role.
671-674: LGTM: Identity Store permissions are properly scoped.
The added Identity Store permissions are appropriately limited to read-only operations for groups and group memberships.
1058-1062: LGTM: Payment Cryptography permissions follow security best practices.
The new permissions for the Payment Cryptography service are properly restricted to read-only operations for keys and aliases.
1440-1449: LGTM: VPC Lattice permissions are well-structured.
The VPC Lattice permissions follow a consistent pattern of Get/List operations for various resources:
- Access log subscriptions
- Services and service networks
- Target groups and targets
1325-1329: LGTM: Amazon EventBridge Scheduler permissions are properly scoped.
The Scheduler permissions are appropriately limited to read-only operations for schedules and schedule groups.
Line range hint 1-1500: Overall assessment of the policy changes.
The changes to this AWS Config service role policy:
- Add read-only permissions for new AWS services
- Maintain the principle of least privilege by only granting Get/List/Describe permissions
- Follow a consistent alphabetical ordering
- Are properly scoped for AWS Config's monitoring and assessment capabilities
The only issue found is the case inconsistency in CloudTrail service name.
189-194:
Fix case inconsistency in CloudTrail service name.
The service name has inconsistent casing: cloudTrail vs cloudtrail.
Apply this fix:
- "cloudTrail:GetChannel",
+ "cloudtrail:GetChannel",
- "cloudTrail:ListChannels",
+ "cloudtrail:ListChannels",Likely invalid or redundant comment.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (12)
87-88: Account and Application Signals permissions look appropriate.
The new permissions for account region management and application signals monitoring are consistent with AWS Support's need to diagnose regional issues and monitor application health.
Also applies to: 196-202
117-133: AOSS permissions align with support requirements.
The added Amazon OpenSearch Serverless (AOSS) permissions are read-only and necessary for AWS Support to troubleshoot OpenSearch related issues.
133-147: AppConfig permissions follow least privilege principle.
The new AppConfig permissions are appropriately scoped to read-only operations needed for configuration troubleshooting.
828-844: Deadline service permissions are appropriate.
The added AWS Deadline permissions are read-only and necessary for supporting render farm operations.
1061-1061: EC2 IPAM permissions are well-scoped.
The new EC2 permissions focus on IP address management (IPAM) functionality and are appropriately read-only.
Also applies to: 1107-1107, 1136-1148
1199-1200: EKS pod identity permissions are minimal.
The added EKS permissions for pod identity associations are limited to describe/list operations.
2357-2362: OSIS permissions follow best practices.
The OpenSearch Ingestion Service (OSIS) permissions are read-only and necessary for pipeline troubleshooting.
2672-2678: Route53 Profiles permissions are well-defined.
The new Route53 Profiles permissions are appropriately scoped to read-only operations.
2929-2936: SecurityHub permissions enhance support capabilities.
The added SecurityHub permissions enable AWS Support to assist with security configuration and compliance issues.
3432-3435: WorkSpaces permissions follow service patterns.
The new WorkSpaces permissions maintain consistency with existing patterns of read-only access.
3447-3453: X-Ray permissions enhance debugging capabilities.
The added X-Ray permissions are appropriate for support scenarios involving distributed tracing and performance analysis.
365-386: Review Bedrock AI permissions scope.
The extensive Bedrock permissions grant access to sensitive AI/ML resources. While these are read-only permissions needed for support, consider:
- Monitoring usage of these permissions
- Ensuring data privacy when support accesses AI model information
✅ Verification successful
The Bedrock read-only permissions are appropriate for AWS Support role.
Based on the policy content and changelog entries, these Bedrock permissions are:
- Read-only operations (all start with "get" or "list")
- Part of standard AWS Support service role permissions added recently (visible in changelogs)
- Consistent with other service permissions in the policy that allow AWS Support to view resources for troubleshooting
The permissions are scoped appropriately to allow AWS Support to assist customers with Bedrock-related issues while maintaining the principle of least privilege by only allowing read access.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if there are any existing Bedrock-related support cases or documentation
# that justify these permissions
echo "Searching for Bedrock-related support documentation:"
rg -i "bedrock.*support" --type md
Length of output: 151
Script:
#!/bin/bash
# Let's check the broader context of where these Bedrock permissions are used
# First, check the full policy file content
echo "Checking the full policy content:"
cat docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json
# Then search for any Bedrock-related documentation or references
echo -e "\nSearching for Bedrock references in documentation:"
rg -i "bedrock" --type md --type txt
# Look for any AWS Support role related documentation
echo -e "\nSearching for AWS Support role documentation:"
rg -i "aws.*support.*role" --type md --type txt
Length of output: 146345
udondan
force-pushed
the
update-aws-managed-policies
branch
from
739eae9
to
39749a4
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
docs/source/_static/managed-policies/AmazonSNSFullAccess.json (1)
20-23: Consider implementing CloudWatch alarms for spend monitoring.The policy includes permissions for spend limit management (
SetTextMessageSpendLimitOverride). While the permission itself is appropriate, it's recommended to complement this with CloudWatch alarms to monitor SMS usage and costs.Would you like assistance in creating a CloudWatch alarm configuration for SMS spending monitoring?
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (2)
Line range hint
138-155: Consider tightening the CloudFormation stack name pattern.While the condition helps prevent accidental deletion of non-ECS resources, the pattern
EC2ContainerService-*might be too broad. Consider using a more specific pattern likeEC2ContainerService-ECS-*to ensure only ECS-related resources are affected.
Line range hint
156-168: Restrict IAM PassRole permissions to specific roles.The current policy allows passing any IAM role to ECS tasks, which could lead to privilege escalation. Consider restricting the resource to specific role patterns:
"Resource": [ - "*" + "arn:aws:iam::*:role/ecs-task-*" ],docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (1)
285-338: LGTM with architectural note: SES integration permissions.The SES permissions are well-structured with proper scoping:
- Account-level isolation
- Limited to Connect-provided email identities
- Specific configuration set for Connect
Note: The configuration set name
configuration-set-for-connect-DO-NOT-DELETEsuggests this is a managed resource. Consider documenting this requirement in the operational documentation.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
lib/generated/aws-managed-policies/cdk-iam-floyd.tsis excluded by!**/generated/**lib/generated/aws-managed-policies/iam-floyd.tsis excluded by!**/generated/**
📒 Files selected for processing (82)
docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSBackupFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json(2 hunks)docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json(1 hunks)docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json(26 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json(11 hunks)docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json(2 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json(2 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json(2 hunks)docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json(25 hunks)docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWS_ConfigRole.json(27 hunks)docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonBedrockReadOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json(2 hunks)docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json(1 hunks)docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json(1 hunks)docs/source/_static/managed-policies/AmazonECS_FullAccess.json(8 hunks)docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSComputePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSServicePolicy.json(3 hunks)docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemFullAccess.json(3 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json(2 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonQDeveloperAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonQFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json(1 hunks)
⛔ Files not processed due to max files limit (21)
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json
- docs/source/_static/managed-policies/CloudWatchInternetMonitorFullAccess.json
- docs/source/_static/managed-policies/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.json
- docs/source/_static/managed-policies/CloudWatchSyntheticsFullAccess.json
- docs/source/_static/managed-policies/ElasticLoadBalancingFullAccess.json
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/ReadOnlyAccess.json
- docs/source/_static/managed-policies/ResourceGroupsTaggingAPITagUntagSupportedResources.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/SecurityAudit.json
- docs/source/_static/managed-policies/ViewOnlyAccess.json
- docs/source/_static/managed-policies/index.json
💤 Files with no reviewable changes (3)
- docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json
🚧 Files skipped from review as they are similar to previous changes (67)
- docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSBackupFullAccess.json
- docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json
- docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json
- docs/source/_static/managed-policies/AWSDataSyncFullAccess.json
- docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json
- docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json
- docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json
- docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json
- docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json
- docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSComputePolicy.json
- docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSServicePolicy.json
- docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonQDeveloperAccess.json
- docs/source/_static/managed-policies/AmazonQFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json
🔇 Additional comments (80)
docs/source/_static/managed-policies/AmazonSNSFullAccess.json (2)
5-9: LGTM: Format change maintains same permissions.
The change from array to string format for the sns:* action is valid and maintains the same level of access.
28-32: Well-implemented security control via service principal condition.
The Condition block properly restricts these permissions to be used only through the SNS service principal, which is a security best practice for cross-service access.
docs/source/_static/managed-policies/AmazonElasticFileSystemServiceRolePolicy.json (1)
79-81: LGTM! The new EFS replication permissions are properly configured.
The addition of ReplicationRead and ReplicationWrite permissions is consistent with EFS replication functionality and follows AWS IAM best practices for service role policies.
Let's verify these permissions are documented in AWS:
✅ Verification successful
Let me gather more context about these permissions by checking if they are documented in any markdown or policy documentation files.
Based on the search results, I can see that the new EFS replication permissions are consistently used across multiple AWS managed policies including AmazonElasticFileSystemFullAccess, AmazonElasticFileSystemReadOnlyAccess, and AmazonElasticFileSystemServiceRolePolicy. Let me verify if these permissions are part of a broader replication feature update.
Based on the comprehensive search results, I can now generate the final response:
The EFS replication permissions are properly integrated across AWS managed policies
The new permissions ReplicationRead and ReplicationWrite are consistently implemented across the EFS policy hierarchy:
- ReadOnlyAccess policy includes
ReplicationReadfor read-only operations - FullAccess policy includes both
ReplicationReadandReplicationWrite - ServiceRolePolicy includes both permissions alongside other replication-related actions like
CreateReplicationConfiguration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the new EFS actions exist in AWS documentation
# Expected: Both new actions should be found in AWS documentation
# Search for documentation references to the new EFS replication actions
rg -i "elasticfilesystem:ReplicationRead|elasticfilesystem:ReplicationWrite" README.md docs/
Length of output: 718
Script:
#!/bin/bash
# Search for documentation about these new EFS replication permissions
rg -i "replication.*permission|permission.*replication" docs/
# Also check for any changelog or release notes
fd -e md -e txt . docs/ -x cat {} \; | rg -i "replication.*permission|permission.*replication|elasticfilesystem:Replication"
Length of output: 44262
Script:
#!/bin/bash
# Check for any related replication changes in the policies
rg -B5 -A5 "elasticfilesystem:Replication" docs/source/_static/managed-policies/
# Look for any changelog or documentation updates
fd changelog -e md -e txt docs/ -x cat {}
Length of output: 4070
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (7)
5-11: LGTM: Appropriate permissions for list operation
The statement correctly implements the list operation permission with service-level scope.
13-22: LGTM: Well-scoped instance-level permissions
The statement properly restricts actions to specific Connect instance resources with appropriate campaign-related permissions.
24-35: LGTM: Strong security with same-account condition
Excellent implementation of security best practices by including the same-account condition for EventBridge rule listing.
37-52: LGTM: Excellent security controls with dual conditions
The statement implements strong security through:
- Resource name prefix restriction
- Same-account condition
- Service management verification
54-65: LGTM: Consistent security pattern maintained
The statement follows the same strong security pattern established in previous EventBridge permissions.
Line range hint 1-81: Overall policy review: Well-structured and secure
The policy demonstrates excellent security practices throughout:
- Consistent use of account-level conditions
- Appropriate resource scoping
- Tag-based access control
- Service-specific resource naming
67-78: LGTM with verification: Tag-based access control
The statement implements appropriate tag-based access control for Wisdom operations.
docs/source/_static/managed-policies/AmazonElasticFileSystemFullAccess.json (4)
5-6: LGTM: Statement structure is well-formatted.
The explicit Sid and Effect declaration improves readability.
63-63: LGTM: CreateServiceLinkedRole positioning maintained.
53-54: Verify new replication permissions are standard AWS actions.
The addition of ReplicationRead and ReplicationWrite permissions aligns with EFS replication capabilities.
✅ Verification successful
ReplicationRead and ReplicationWrite are verified standard AWS EFS actions
These permissions are confirmed as standard AWS actions for EFS replication as they appear in multiple AWS-managed policies with consistent usage patterns:
- Present in the read-only policy (ReplicationRead only)
- Present in the service role policy (both ReplicationRead and ReplicationWrite)
- Present in the full access policy (both permissions)
- Used alongside other replication-related actions like DescribeReplicationConfigurations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify these are standard AWS actions by checking other AWS managed policies
# Test: Search for these actions in other policy files
rg -l "elasticfilesystem:Replication(Read|Write)" --type json
Length of output: 396
Script:
#!/bin/bash
# Let's examine the content of these policies to understand the context of replication permissions
rg "elasticfilesystem:Replication(Read|Write)" -A 2 -B 2 --type json
Length of output: 2083
73-82: LGTM: IAM PassRole permission properly restricted.
The new IAM PassRole permission follows AWS security best practices by:
- Restricting the passed roles to EFS service only
- Using StringLike condition for service validation
✅ Verification successful
The previous command had a syntax error. Let's try these new commands to:
- Find all PassRole permissions with more context
- Locate all EFS-related policy files to understand the permission structure
Based on the search results, I can now generate the final response. The results show that the PassRole permission pattern in the EFS policy follows AWS best practices, similar to other AWS service policies, by properly restricting the service using the iam:PassedToService condition.
LGTM: IAM PassRole permission follows AWS security best practices
The PassRole permission in AmazonElasticFileSystemFullAccess policy is properly configured with:
- Service-specific restriction using
iam:PassedToServicecondition to "elasticfilesystem.amazonaws.com" - Similar pattern used across other AWS managed policies like EventBridge, AppRunner, Lambda, etc.
- Resource pattern "arn:aws:iam:::role/" is consistent with other AWS managed policies that require role passing capabilities
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify similar PassRole patterns in other AWS managed policies
# Test: Look for similar PassRole patterns with service restrictions
rg -A 5 '"Action": "iam:PassRole".*"StringLike".*"iam:PassedToService":' --type json
Length of output: 396
Script:
#!/bin/bash
# Let's try a different approach to search for PassRole patterns
rg -U '"Action":\s*"iam:PassRole"' --type json -A 10 -B 2
# Also search for any EFS-related IAM policies
fd . -e json -x grep -l "elasticfilesystem" {}
Length of output: 127891
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (11)
66-66: LGTM for SavingsPlan restriction
Denying savingsplans:CreateSavingsPlan is appropriate as it prevents financial abuse through long-term commitments, aligning with existing restrictions on EC2 reserved instance actions.
67-70: LGTM for ECS restrictions
71-75: LGTM for comprehensive Bedrock restrictions
The denied actions appropriately prevent abuse of AI/ML resources by blocking model invocation, creation of agreements, and entitlement modifications.
76-79: LGTM for S3 write restrictions
80-81: LGTM for SageMaker restrictions
The denied actions appropriately prevent abuse of SageMaker resources by blocking creation of endpoints and processing jobs.
82-85: LGTM for STS restrictions
86-89: LGTM for development service restrictions
The denied actions appropriately prevent abuse by blocking creation of new resources in Amplify, CodeBuild, and Glue services.
90-92: LGTM for IAM delete actions
93-94: LGTM for monitoring service actions
95-95: LGTM for MediaPackage restriction
Denying mediapackagev2:CreateChannel appropriately prevents creation of new MediaPackage resources that could be abused.
66-95: LGTM for overall policy structure
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (7)
Line range hint 128-137: LGTM! Well-scoped SSM permissions.
The SSM permissions are properly restricted to ECS-specific parameters and limited to read-only operations.
169-180: LGTM! Well-implemented infrastructure role permissions.
The policy follows IAM best practices with specific role ARN and exact service principal matching.
Line range hint 181-197: LGTM! Properly scoped instance role permissions.
The policy correctly handles both global and China regions while maintaining proper role restrictions.
Line range hint 198-213: LGTM! Well-implemented autoscaling role permissions.
The policy maintains consistency with other role policies while ensuring proper restrictions.
Line range hint 231-247: LGTM! Well-implemented ELB tagging permissions.
The policy correctly restricts tagging to resource creation time, following AWS tagging best practices.
Line range hint 5-127: Consider adding resource constraints to critical permissions.
While broad permissions are expected for a FullAccess policy, consider adding resource constraints for critical operations:
- EC2:RunInstances could be limited to specific instance types or AMIs
- CloudFormation operations could be scoped to ECS-related stacks only
Let's verify if there are any existing resource constraints in related policies:
Line range hint 214-230: LGTM! Verify if all required services are included.
The policy correctly restricts service-linked role creation to ECS-related services.
Let's check if we're missing any ECS-related services:
✅ Verification successful
Let me search for more context about ECS-related services to ensure we have a complete list.
Service-linked role creation policy is complete and correctly configured
The policy correctly includes all necessary AWS services for ECS operations:
ecs.amazonaws.com- Core ECS serviceautoscaling.amazonaws.com- EC2 Auto Scalingecs.application-autoscaling.amazonaws.com- Application Auto Scaling for ECSspot.amazonaws.comandspotfleet.amazonaws.com- Spot Instance integration
The verification shows that ecs-tasks.amazonaws.com is used in a different context (for task execution) and doesn't require a service-linked role. No additional ECS-related services requiring service-linked roles were found in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other ECS-related service-linked roles in AWS documentation
rg "ecs.*\.amazonaws\.com" --type json
Length of output: 2297
Script:
#!/bin/bash
# Search for other potential ECS-related services in AWS documentation
rg "ecs.*tasks.*\.amazonaws\.com" --type json
rg "ecs.*container.*\.amazonaws\.com" --type json
Length of output: 776
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (5)
Line range hint 120-125: LGTM: Improved security with explicit service role ARN
The change improves security by explicitly specifying the AppRegistry service role ARN instead of using a wildcard pattern.
276-297: LGTM: Well-scoped resource group permissions
The new statement follows the principle of least privilege with:
- Resource prefix limitation to "SystemsManagerForSAP-*"
- Required SSMForSAPCreated tag
- ARN pattern restriction for awsApplication tag
- Explicit tag key restrictions
299-316: LGTM: Well-scoped EC2 instance tagging permissions
The statement implements proper access controls:
- Only allows managing tags with "SystemsManagerForSAP-*" prefix
- Requires instances to be already tagged with SSMForSAPManaged=True
318-332:
Add volume association condition for better security
The current implementation allows tagging any EBS volume with SystemsManagerForSAP-* tags, which could be too permissive. Consider adding a condition to ensure volumes are associated with SSM-managed SAP instances.
Add a condition to restrict tagging to volumes attached to SSM-managed instances:
{
"Sid": "ManageSsmSapTagsOnEbsVolumes",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": "arn:aws:ec2:*:*:volume/*",
"Condition": {
+ "StringEquals": {
+ "ec2:ResourceTag/SSMForSAPManaged": "True"
+ },
"ForAllValues:StringLike": {
"aws:TagKeys": [
"SystemsManagerForSAP-*"
]
}
}
}334-350:
Add volume association condition for application tagging
Similar to the previous statement, this allows tagging any EBS volume with the awsApplication tag. While the ArnLike condition ensures proper tag values, it should be restricted to volumes associated with SSM-managed SAP instances.
Add a condition to restrict tagging to volumes attached to SSM-managed instances:
{
"Sid": "ManageAppTagsOnEbsVolumes",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": "arn:aws:ec2:*:*:volume/*",
"Condition": {
+ "StringEquals": {
+ "ec2:ResourceTag/SSMForSAPManaged": "True"
+ },
"ArnLike": {
"aws:RequestTag/awsApplication": "arn:aws:resource-groups:*:*:group/*/*"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"awsApplication"
]
}
}
}docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (5)
96-97: LGTM: Read-only Profile Object Type permissions.
The added permissions are read-only and properly scoped to specific object types within Connect domains.
149-163: Skipping comment as past review is still valid.
The previous review comment about documenting new Wisdom message template permissions is still applicable.
195-208: LGTM: Well-structured segmentation permissions.
The new Customer Profiles segmentation permissions are properly scoped to segment definitions within Connect domains and follow AWS best practices.
259-284: LGTM: Secure Chime SDK Voice Connector access.
The permissions are well-structured with:
- Account-level isolation using
aws:ResourceAccount - Additional
AmazonConnectEnabledtag requirement for get operations
80-87: LGTM: Customer Profiles permissions are properly scoped.
The new Customer Profiles permissions are appropriately scoped to Connect domains and follow the principle of least privilege.
✅ Verification successful
Based on the code analysis, I can now provide a definitive response about the Customer Profiles permissions in the AmazonConnectServiceLinkedRolePolicy.json file.
The Customer Profiles permissions are correctly scoped and necessary.
The permissions are required for Amazon Connect to integrate with Customer Profiles service. The policy grants read-only and controlled operations that are essential for:
- Listing integrations, segments, and profile data (
profile:List*actions) - Retrieving profile information (
profile:Get*,profile:BatchGet*actions) - Creating segment estimates (
profile:CreateSegmentEstimate)
These permissions align with the generated code in lib/generated/policy-statements/connectcustomerprofiles.ts which shows these are valid Customer Profiles service actions. The permissions follow the principle of least privilege by:
- Only including necessary read operations and controlled estimate creation
- Not including any destructive or administrative actions
- Being properly scoped to Connect domains through resource-level permissions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that these Customer Profiles permissions are used in Connect integration code
rg -l "profile:(List|Get|Create|Batch)(Integration|Segment|Profile)" --type ts --type js
Length of output: 90
Script:
#!/bin/bash
# Let's try a different approach to verify the Customer Profiles permissions
# 1. Check for any references to Customer Profiles in the codebase
rg -i "customer.?profiles?" --type ts --type js -l
# 2. Look for AWS SDK imports related to Customer Profiles
rg "@aws-sdk/client-customer-profiles" --type ts --type js -l
# 3. Search for profile-related method calls
rg "\.(list|get|create|batch)(Integration|Segment|Profile)" --type ts --type js -l
# 4. Check if there are any documentation files explaining the Customer Profiles feature
fd -e md -e txt -e rst | xargs rg -l "customer.?profiles?"
Length of output: 485
Script:
#!/bin/bash
# Let's examine the content of the generated files to understand the Customer Profiles integration
cat lib/generated/policy-statements/connectcustomerprofiles.ts
# Also check the Connect integration file
cat lib/generated/policy-statements/connect.ts
# Check the IAM Floyd generated file for any Customer Profiles related policies
cat lib/generated/aws-managed-policies/iam-floyd.ts
Length of output: 475218
docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json (4)
8-11: LGTM: CloudTrail permissions are appropriately scoped.
The addition of GetServiceLinkedChannel alongside CreateServiceLinkedChannel is logical and follows the principle of least privilege by using a specific resource ARN pattern.
16-16: LGTM: ApiGateway action format simplified.
The change from an array to a single string for apigateway:GET is a valid simplification since there's only one action.
Line range hint 28-439: LGTM: New service permissions align with Resource Explorer's functionality.
The additions grant necessary list/describe permissions that Resource Explorer needs to discover and index resources across various AWS services. These are read-only operations that don't modify any resources.
441-441: Consider using more granular resource restrictions.
The previous review comment about broad resource access with "Resource": "*" remains valid. While Resource Explorer needs access to discover resources across services, consider:
- Using service-specific resource ARNs where possible
- Implementing condition keys to restrict by:
- Region
- Account
- Resource tags
- Other relevant attributes
Example with conditions:
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"rds:Describe*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
}
}
}Let's verify if any other AWS managed policies use more granular restrictions:
#!/bin/bash
# Search for AWS managed policies that use resource-level permissions for similar actions
rg -l "Resource(?:[^*]|$)" docs/source/_static/managed-policies/ | while read -r policy; do
echo "=== $policy ==="
rg "Describe|List" -A 2 -B 2 "$policy"
donedocs/source/_static/managed-policies/AWS_ConfigRole.json (15)
32-43: AOSS permissions look good!
The added permissions for Amazon OpenSearch Serverless are appropriately scoped to read-only operations, allowing AWS Config to effectively monitor AOSS resources.
45-50: App Integrations permissions are properly scoped!
The added permissions for AWS AppIntegrations service are correctly limited to read-only operations necessary for AWS Config monitoring.
190-195: CloudTrail channel permissions are appropriate!
The added permissions for CloudTrail channels are correctly scoped to read-only operations required for AWS Config monitoring.
Line range hint 259-284: Connect service permissions are well-defined!
The added permissions for Amazon Connect are appropriately limited to read-only operations necessary for AWS Config to monitor Connect resources.
316-317: DataZone permissions are minimal and appropriate!
The added permissions for AWS DataZone are correctly scoped to essential read-only operations.
759-773: IoT Fleetwise permissions are properly structured!
The added permissions for AWS IoT Fleetwise service are appropriately limited to read-only operations required for AWS Config monitoring.
819-839: IVS and IVS Chat permissions are well-defined!
The added permissions for Amazon IVS and IVS Chat are correctly scoped to read-only operations necessary for AWS Config monitoring.
962-983: MediaConnect and MediaTailor permissions are appropriate!
The added permissions for AWS MediaConnect and MediaTailor services are correctly limited to read-only operations required for AWS Config monitoring.
1027-1031: OAM and Omics permissions are properly scoped!
The added permissions for AWS Observability Access Manager and Omics services are appropriately limited to read-only operations.
1060-1064: Payment Cryptography permissions are well-defined!
The added permissions for AWS Payment Cryptography service are correctly scoped to read-only operations necessary for AWS Config monitoring.
1122-1123: RDS Proxy permissions are appropriate!
The added permissions for Amazon RDS Proxy are correctly limited to read-only operations required for AWS Config monitoring.
1273-1273: S3 Storage Lens permissions are properly structured!
The added permissions for S3 Storage Lens are appropriately limited to read-only operations necessary for AWS Config monitoring.
Also applies to: 1280-1281
1327-1331: Scheduler permissions are well-defined!
The added permissions for AWS Scheduler service are correctly scoped to read-only operations required for AWS Config monitoring.
1442-1451: VPC Lattice permissions are appropriate!
The added permissions for AWS VPC Lattice service are correctly limited to read-only operations necessary for AWS Config monitoring.
Line range hint 1-1475: Overall policy changes look excellent!
The updates to the AWS Config Role policy maintain the principle of least privilege by:
- Adding only read-only permissions for new AWS services
- Maintaining consistent permission patterns (Get/List/Describe operations)
- Enabling AWS Config to effectively monitor resources across new services
These changes align well with AWS Config's monitoring requirements and security best practices.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (8)
32-43: LGTM: Well-structured AOSS permissions
The new Amazon OpenSearch Serverless permissions are appropriately scoped with read-only actions, following the principle of least privilege.
189-189: Case inconsistency in CloudTrail service name still exists
Also applies to: 194-194
Line range hint 258-283: LGTM: Comprehensive Connect service permissions
The new Amazon Connect permissions are well-structured with appropriate read-only actions for monitoring purposes.
757-771: LGTM: Well-defined IoT FleetWise permissions
The AWS IoT FleetWise permissions are properly scoped with read-only actions for monitoring and auditing purposes.
817-837: LGTM: Appropriate IVS and IVS Chat permissions
The Amazon IVS and IVS Chat permissions are correctly structured with read-only access for configuration monitoring.
960-981: LGTM: Comprehensive MediaConnect and MediaTailor permissions
The AWS MediaConnect and MediaTailor permissions are well-defined with appropriate read-only actions for service monitoring.
1028-1029: LGTM: Well-structured Omics and Scheduler permissions
The AWS Omics and EventBridge Scheduler permissions are properly scoped with read-only actions for configuration monitoring.
Also applies to: 1325-1329
1440-1449: LGTM: Appropriate VPC Lattice permissions
The AWS VPC Lattice permissions are correctly structured with read-only access for monitoring service configurations.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (11)
87-88: LGTM: Account service permissions are appropriate for support role.
The added permissions getRegionOptStatus and listRegions are read-only and necessary for AWS Support to help troubleshoot region-related issues.
133-147: LGTM: AppConfig read permissions are appropriate.
The added AppConfig permissions are read-only and commonly needed for support scenarios involving application configuration troubleshooting.
196-202: LGTM: Application Signals permissions are appropriate.
The added Application Signals permissions are read-only and necessary for AWS Support to help troubleshoot application monitoring and observability issues.
828-844: LGTM: Deadline service permissions are appropriate.
The added AWS Deadline permissions are read-only and necessary for supporting render farm and high-performance computing workloads.
1199-1200: LGTM: EKS pod identity permissions are appropriate.
The added EKS permissions for pod identity associations are read-only and necessary for troubleshooting pod identity issues in EKS clusters.
2357-2362: LGTM: OSIS permissions follow least privilege.
The added OpenSearch Ingestion Service (OSIS) permissions are appropriately scoped to read-only actions required for support scenarios.
2672-2678: LGTM: Route53 Profiles permissions are appropriate.
The added Route53 Profiles permissions are read-only and necessary for DNS and routing troubleshooting support.
3447-3453: LGTM: X-Ray permissions are appropriate.
The added X-Ray permissions are read-only and necessary for AWS Support to help troubleshoot application tracing and performance issues.
2929-2936:
Review Security Hub configuration access.
The added Security Hub permissions provide access to security configuration and policy information. While read-only, verify if this broad access to security settings is necessary.
#!/bin/bash
# Description: Verify Security Hub permissions scope
# Expected: Documentation justifying access to security configurations
echo "Searching for Security Hub support documentation:"
rg -i "securityhub.*support" --type md
echo "Analyzing Security Hub permissions in other policies:"
rg -i "securityhub:(describe|get|list)" --type json ./docs/source/_static/managed-policies/117-132: Verify the necessity of broad AOSS permissions.
The added Amazon OpenSearch Service (AOSS) permissions grant extensive read access to configurations, policies, and resources. While these are read-only permissions, they provide broad visibility into AOSS resources.
✅ Verification successful
AOSS permissions in AWSSupportServiceRolePolicy are consistent with standard read-only access patterns
The AOSS permissions in the AWSSupportServiceRolePolicy align with established patterns seen in other AWS managed policies like ReadOnlyAccess and AWSConfigServiceRolePolicy. These read-only permissions are necessary for AWS Support to:
- Diagnose AOSS-related issues by viewing collections and configurations
- Verify security settings and access policies
- Review lifecycle policies and VPC endpoints
The permissions follow the principle of least privilege by:
- Including only read operations (get/list/batch-get)
- Matching the scope of similar service role policies
- Enabling essential troubleshooting capabilities
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if AOSS permissions are commonly used in support scenarios
# Expected: Documentation or support cases referencing AOSS troubleshooting
echo "Searching for AOSS support documentation references:"
rg -i "opensearch.*support" --type md
echo "Searching for AOSS in support policy templates:"
rg -i "aoss:(get|list|batch)" --type json ./docs/source/_static/managed-policies/
Length of output: 5260
Script:
#!/bin/bash
# Let's search for AOSS permissions in other AWS managed policies to understand the common patterns
echo "Searching for AOSS permissions in managed policies:"
rg -i "aoss:" --type json ./docs/source/_static/managed-policies/
# Let's also check if there are any AOSS related documentation or comments
echo -e "\nSearching for AOSS/OpenSearch documentation:"
rg -i "opensearch|aoss" --type md
Length of output: 6631
365-386:
Review extensive Bedrock AI permissions.
The added Bedrock permissions provide broad access to AI/ML resources including agents, models, and knowledge bases. While read-only, these permissions could expose sensitive ML model data.
✅ Verification successful
Bedrock permissions are appropriate for AWS Support service role
The added Bedrock permissions are read-only (get and list operations) and consistent with AWS Support's need to troubleshoot and assist customers with Bedrock services. This follows the same pattern as other AWS services in the policy where Support requires read access to diagnose issues. The permissions:
- Are limited to read-only operations
- Match recent Bedrock feature additions seen in changelogs
- Follow the same pattern as other service permissions in the AWSSupportServiceRolePolicy
- Are necessary for AWS Support to provide assistance with Bedrock services
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify if Bedrock permissions follow least privilege
# Expected: Documentation justifying each permission
echo "Searching for Bedrock support documentation:"
rg -i "bedrock.*support" --type md
echo "Checking other AWS managed policies for Bedrock scope:"
rg -i "bedrock:(get|list)" --type json ./docs/source/_static/managed-policies/
Length of output: 5260
Script:
#!/bin/bash
# Let's search specifically for Bedrock permissions and documentation
echo "Searching for Bedrock permissions in AWSSupportServiceRolePolicy:"
cat ./docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json | jq '.Statement[] | select(.Resource == "*") | .Action[]' | grep -i "bedrock"
echo "Searching for Bedrock documentation or comments:"
rg -i "bedrock" --type md
echo "Checking if this is a new addition by looking at git history:"
git log -p ./docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json | grep -A 10 -B 10 "bedrock"
Length of output: 5430
udondan
force-pushed
the
update-aws-managed-policies
branch
from
39749a4
to
62e4fb1
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (6)
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (2)
Line range hint
5-25: Consider explicitly listing permissions instead of using wildcards.While the wildcards (Get*, Update*, List*, Delete*) are scoped to the dataexchange namespace, it's a security best practice to explicitly list all required permissions. This ensures better visibility and control over granted permissions, especially as new API actions are added in future service updates.
Line range hint
1-164: Consider implementing additional security controls.While the policy is generally well-structured, consider these additional security measures:
- Implement aws:PrincipalTag conditions where applicable
- Add aws:RequestTag conditions for resource creation
- Consider using aws:SourceVpc or aws:SourceVpce conditions if the service is used within VPC
These additions would enhance the security posture while maintaining functionality.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (1)
Line range hint
138-155: Consider adding additional tag conditions for enhanced safety.While the current condition restricts deletions to ECS CloudFormation stacks, consider adding additional tag conditions to prevent accidental deletion of critical infrastructure.
"Condition": { "StringLike": { "ec2:ResourceTag/aws:cloudformation:stack-name": "EC2ContainerService-*" - } + }, + "StringNotEquals": { + "ec2:ResourceTag/Environment": "production" + } }docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (1)
195-208: LGTM: Well-scoped segmentation permissionsThe new statement properly implements least privilege by:
- Scoping resources to segment-definitions within Connect domains
- Including only necessary segmentation-related actions
Consider implementing appropriate monitoring and alerting for segment operations, especially for large-scale segments that might impact performance.
docs/source/_static/managed-policies/AWS_ConfigRole.json (2)
Line range hint
701-773: Review extensive IoT and IoTFleetwise permissionsThe large block of IoT and IoTFleetwise permissions appears to be properly scoped to read-only operations. However, consider splitting these into separate statements for better manageability:
- Core IoT permissions
- IoTFleetwise permissions
{ + "Sid": "AWSConfigRoleIoTStatementID", "Effect": "Allow", "Action": [ "iot:DescribeBillingGroup", "iot:ListBillingGroups", ... ], "Resource": "*" }, { + "Sid": "AWSConfigRoleIoTFleetwiseStatementID", "Effect": "Allow", "Action": [ "iotfleetwise:GetDecoderManifest", "iotfleetwise:ListDecoderManifests", ... ], "Resource": "*" }
962-983: Consolidate MediaConnect and MediaTailor permissionsThe permissions for MediaConnect and MediaTailor services are scattered across multiple locations in the policy. Consider grouping them together for better maintainability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
lib/generated/aws-managed-policies/cdk-iam-floyd.tsis excluded by!**/generated/**lib/generated/aws-managed-policies/iam-floyd.tsis excluded by!**/generated/**
📒 Files selected for processing (82)
docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSBackupFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json(2 hunks)docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json(1 hunks)docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json(26 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json(11 hunks)docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json(2 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json(2 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json(2 hunks)docs/source/_static/managed-policies/AWSIPAMServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSLicenseManagerUserSubscriptionsServiceRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json(2 hunks)docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json(25 hunks)docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWS_ConfigRole.json(27 hunks)docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonBedrockReadOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json(2 hunks)docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json(1 hunks)docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json(1 hunks)docs/source/_static/managed-policies/AmazonECS_FullAccess.json(8 hunks)docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSComputePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSServicePolicy.json(3 hunks)docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemFullAccess.json(3 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json(2 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonQDeveloperAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonQFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json(1 hunks)
⛔ Files not processed due to max files limit (23)
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json
- docs/source/_static/managed-policies/CloudWatchInternetMonitorFullAccess.json
- docs/source/_static/managed-policies/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.json
- docs/source/_static/managed-policies/CloudWatchSyntheticsFullAccess.json
- docs/source/_static/managed-policies/ElasticLoadBalancingFullAccess.json
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/ReadOnlyAccess.json
- docs/source/_static/managed-policies/ResourceGroupsTaggingAPITagUntagSupportedResources.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/SecurityAudit.json
- docs/source/_static/managed-policies/ViewOnlyAccess.json
- docs/source/_static/managed-policies/index.json
💤 Files with no reviewable changes (3)
- docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json
🚧 Files skipped from review as they are similar to previous changes (68)
- docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSBackupFullAccess.json
- docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json
- docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json
- docs/source/_static/managed-policies/AWSDataSyncFullAccess.json
- docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json
- docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json
- docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json
- docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json
- docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json
- docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSComputePolicy.json
- docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSServicePolicy.json
- docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemFullAccess.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonQDeveloperAccess.json
- docs/source/_static/managed-policies/AmazonQFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSNSFullAccess.json
- docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
🔇 Additional comments (72)
docs/source/_static/managed-policies/AWSIPAMServiceRolePolicy.json (2)
27-30: LGTM! The additional Organizations permissions enhance IPAM's resource discovery capabilities.
The new permissions allow IPAM to traverse the AWS Organizations hierarchy, which is essential for comprehensive IP address management across complex organizational structures. These read-only permissions follow the principle of least privilege and complement the existing Organizations access.
27-30: Verify alignment with AWS IPAM documentation.
Let's confirm these permissions are documented in AWS IPAM's service role requirements.
✅ Verification successful
Let me search for more specific information about AWS IPAM permissions.
Let me search for the actual content of the IPAM service role policy to verify these permissions.
The Organizations permissions in the IPAM service role policy are correctly aligned with AWS documentation
The Organizations permissions listed in the policy (ListDelegatedAdministrators, ListChildren, ListParents, DescribeOrganizationalUnit) are part of the official AWS IPAM service role policy (AWSIPAMServiceRolePolicy) and are required for IPAM to discover and manage IP addresses across an AWS Organizations structure. These permissions allow IPAM to:
- List accounts in the organization
- Navigate the organizational hierarchy
- Access organizational unit information
- Identify delegated administrators
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for documentation references to new Organizations permissions
# Test: Check if these permissions are mentioned in AWS documentation files
rg -i "organizations:(ListChildren|ListParents|DescribeOrganizationalUnit).*IPAM"
# Test: Look for any IPAM-related documentation that mentions Organizations integration
rg -i "ipam.*organizations"
Length of output: 44182
Script:
#!/bin/bash
# Search for IPAM-related documentation and permissions
rg -i "ipam.*permission"
# Search for any IPAM-related Organizations integration documentation
rg -i "ipam.*organizations" -A 5
# Look for IPAM service role documentation
rg -i "ipamservicerolepolicy" -A 10
Length of output: 135147
Script:
#!/bin/bash
# Get the content of the IPAM service role policy
cat docs/source/_static/managed-policies/AWSIPAMServiceRolePolicy.json
# Search for any IPAM documentation files
fd -e md -e txt -e rst -e html ipam
Length of output: 1482
docs/source/_static/managed-policies/AWSLicenseManagerUserSubscriptionsServiceRolePolicy.json (5)
83-90: LGTM! Appropriate read-only Route53 permissions.
The new statement follows the principle of least privilege by granting only the necessary read-only Route53 permissions needed for DNS operations.
92-98: LGTM! Consistent with existing EC2 read permissions.
The new statement maintains consistency with the policy's existing EC2 read permissions and follows AWS best practices for EC2 describe actions.
100-114: LGTM! Network resource permissions properly configured.
Both statements grant appropriate read-only access to network resources (subnets and network interfaces), maintaining consistency with AWS best practices for EC2 describe actions.
116-121: LGTM! Well-scoped Secrets Manager access.
The statement follows security best practices by:
- Limiting access to secrets with the specific prefix "license-manager-user-"
- Granting only the necessary GetSecretValue permission
Let's verify no other secrets access exists in the policy:
#!/bin/bash
# Description: Verify no broader secrets access exists
# Expect: Only the scoped secret access we reviewed
rg "secretsmanager:" docs/source/_static/managed-policies/AWSLicenseManagerUserSubscriptionsServiceRolePolicy.json45-49: LGTM! Additional product codes properly scoped.
The new product codes maintain the principle of least privilege by restricting EC2 termination and tagging actions to specific AWS Marketplace products.
Let's verify these product codes are valid AWS Marketplace products:
✅ Verification successful
Product codes are properly restricted in EC2WritePermissions
The verification confirms that:
- The product codes are used in a properly structured IAM policy
- They are correctly applied as a condition on EC2 termination and tagging actions
- The scope is appropriately limited to specific EC2 instances through the Resource ARN
- The implementation follows AWS security best practices by using the principle of least privilege
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the product codes exist in AWS Marketplace
# Note: This is a basic check for references to these codes
rg -i "bz0vcy31ooqlzk5tsash4r1ik|d44g89hc0gp9jdzm99rznthpw|77yzkpa7kvee1y1tt7wnsdwoc|a8jthu9h8pjsn4b8ylvfl6sfr|7at6der8hnlov1g347e6tdkde|3t0v0vuhvxjzm6m462f9v8iz4|4gs2prcp03ojilgkjx8m3ifh7"
Length of output: 325
Script:
#!/bin/bash
# Let's try a different approach to verify these product codes
# Search for the specific file and examine its content
cat "docs/source/_static/managed-policies/AWSLicenseManagerUserSubscriptionsServiceRolePolicy.json"
Length of output: 2936
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (11)
66-66: LGTM: Appropriate cost protection measure
Denying savingsplans:CreateSavingsPlan prevents financial abuse through unauthorized long-term commitments.
70-70: Consider allowing ECR authentication for incident response
The past review comment about allowing ecr:GetAuthorizationToken for incident investigation remains valid.
71-75: LGTM: Comprehensive Bedrock AI protection
The added Bedrock actions effectively prevent abuse of AI resources by blocking model invocations and foundation model agreements.
The past review comment about additional Bedrock restrictions remains valid.
76-79: Reconsider denying S3 read actions
The past review comment about allowing s3:GetObject and s3:ListBucket for incident response remains valid.
80-81: LGTM: Appropriate ML resource protection
The SageMaker actions effectively prevent abuse of ML resources by blocking endpoint creation and processing jobs.
82-83: Reconsider denying SES read actions
The past review comment about allowing SES read-only actions for incident response remains valid.
84-85: LGTM: Critical credential security measures
Denying these STS actions is crucial as it prevents obtaining new credentials that could be used to maintain unauthorized access.
86-89: LGTM: Comprehensive resource creation protection
The added actions appropriately prevent creation of new resources across Amplify, CodeBuild, and Glue services.
90-92: Reconsider denying IAM:ListUsers
The past review comment about allowing iam:ListUsers for incident response remains valid.
93-95: Reconsider denying Lambda and SNS read actions
The past review comment about allowing Lambda and SNS read-only actions for incident response remains valid.
66-95: Consider additional commonly abused actions
The past review comment about adding commonly abused actions remains valid.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (6)
Line range hint 27-47: LGTM! Well-structured job permissions.
The permissions are properly scoped with explicit conditions on job types, following the principle of least privilege.
Line range hint 49-102: LGTM! Excellent S3 permission controls.
The S3 permissions demonstrate strong security practices:
- Resource pattern restrictions (
aws-data-exchange*) - Service principal conditions (
aws:CalledVia) - Tag-based access control
- Separation of read and write permissions
This implementation effectively prevents unauthorized access while maintaining necessary functionality.
Line range hint 124-132: LGTM! Appropriate read-only KMS permissions.
The KMS permissions are properly limited to read-only key operations, following the principle of least privilege.
Line range hint 134-154: LGTM! Well-controlled Redshift permissions.
The Redshift permissions are properly implemented with:
- Consumer identifier condition for data share authorization
- Limited describe permissions
- Clear separation of conditional and non-conditional actions
Line range hint 156-162: Verify resource-level permissions support for API Gateway GET operations.
While limiting to GET operations is good, let's verify if we can scope the resource access more granularly.
#!/bin/bash
# Description: Check AWS documentation for API Gateway resource-level permission support
# Note: This helps determine if we can make the policy more restrictive
# Search for API Gateway IAM documentation references
rg -i "apigateway.*resource-level" docs/Line range hint 104-122: Verify resource-level permissions support for Marketplace actions.
While the actions are well-scoped, the policy uses a broad resource wildcard (*). Let's verify if more granular resource-level permissions are supported for these Marketplace actions.
✅ Verification successful
Based on the search results, I can now provide a definitive response about resource-level permissions for AWS Marketplace actions. Looking at the various AWS Marketplace policies in the repository, I can see clear patterns of resource-level permission support:
Resource-level permissions are supported for some AWS Marketplace actions
Several policies demonstrate that resource-level permissions are supported for certain AWS Marketplace actions:
- Tag-related operations (
TagResource,UntagResource,ListTagsForResource) support ARN-level restrictions:arn:aws:aws-marketplace:*:*:AWSMarketplace/* - Entity operations support product-specific ARNs:
arn:aws:aws-marketplace:*:*:*/SaaSProduct/* - Agreement operations support conditional constraints (e.g.,
AgreementTypecondition) - Private marketplace operations support specific resource types:
AWSMarketplace/Experience/*,AWSMarketplace/Audience/*, etc.
However, the actions in your policy segment (entity and changeset management) are consistently used with "Resource": "*" across multiple policies, including read-only policies, suggesting these specific operations do not support resource-level restrictions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check AWS documentation for resource-level permission support
# Note: This helps determine if we can make the policy more restrictive
# Search for AWS Marketplace IAM documentation references
rg -i "marketplace.*resource-level" docs/
Length of output: 42
Script:
#!/bin/bash
# Let's search for any documentation or references about AWS Marketplace permissions
# in the repository, particularly focusing on IAM policies
# Search for AWS Marketplace related IAM documentation
rg -i "aws-marketplace" docs/ -A 5 -B 5
# Also search for any comments or documentation specifically about these actions
rg -i "DescribeEntity|ListEntities|DescribeChangeSet|ListChangeSets|StartChangeSet|CancelChangeSet" docs/
# Look for any policy files containing marketplace permissions
fd -e json -e yaml -e yml . docs/ --exec grep -l "aws-marketplace"
Length of output: 92210
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (5)
Line range hint 128-137: LGTM - Well-scoped SSM parameter access.
The statement correctly restricts access to ECS-related parameters only, with appropriate read-only permissions.
Line range hint 156-213: LGTM - Well-structured PassRole permissions.
The PassRole permissions are properly segregated by role type and service, following the principle of least privilege.
Line range hint 214-230: LGTM - Appropriate service-linked role creation permissions.
The statement correctly restricts service-linked role creation to necessary ECS-related services.
Line range hint 231-247: LGTM - Well-constrained ELB tagging permissions.
The statement appropriately restricts tagging to resource creation time for specific ELB actions.
Line range hint 5-127: LGTM - Comprehensive permissions for ECS management.
The extensive list of permissions is appropriate for a full access policy, covering necessary integrations with related services like CloudFormation, CloudWatch, CodeDeploy, etc.
Let's verify these permissions are consistent with the official AWS managed policy:
✅ Verification successful
Policy changes are consistent with AWS ECS service requirements
The changes in AmazonECS_FullAccess.json are verified to be appropriate:
- Added descriptive Sid identifiers to improve policy readability
- Added new InfrastructurePassRolePolicy statement for ECS infrastructure role
- Reordered service-linked role services (ecs.amazonaws.com before autoscaling.amazonaws.com)
- All permissions align with related ECS policies (ServiceRolePolicy and TaskExecutionRolePolicy)
- Changes maintain the necessary scope for ECS full access functionality
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Compare with AWS official policy
gh api repos/aws/aws-cdk/contents/packages/@aws-cdk/aws-iam/lib/managed-policy.ts | jq -r '.content' | base64 -d | grep -A 10 'AmazonECS_FullAccess'
Length of output: 245
Script:
#!/bin/bash
# Let's verify if this policy file exists in other locations and check its content
fd -e json "AmazonECS_FullAccess.json"
# Let's also check if there are any other ECS policy files for comparison
fd -e json -e yaml -e yml | grep -i "ecs.*policy\|policy.*ecs"
Length of output: 595
Script:
#!/bin/bash
# Let's examine the content of these related policies to verify consistency
cat docs/source/_static/managed-policies/AmazonECSServiceRolePolicy.json docs/source/_static/managed-policies/AmazonECSTaskExecutionRolePolicy.json
# Also check if there are any recent changes to these policies
git log -p docs/source/_static/managed-policies/AmazonECS_FullAccess.json
Length of output: 16306
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (5)
Line range hint 120-125: LGTM: Improved security with explicit service role ARN
The change enhances security by explicitly specifying the service role ARN instead of using a wildcard pattern. The condition ensures the role can only be created for the AppRegistry service.
276-297: LGTM: Well-structured resource group permissions
The statement follows security best practices by:
- Restricting to specific resource group prefix
- Enforcing required tags
- Ensuring application tag references valid resource group ARNs
299-316: LGTM: Well-scoped EC2 instance tagging permissions
The statement implements proper access controls by:
- Restricting to SSM-managed instances
- Limiting to specific tag key pattern
318-332: Skip: Issue already identified in previous review
The concerns about over-permissive EBS volume tagging were already raised in the previous review comments and remain valid.
334-350: Skip: Issue already identified in previous review
The concerns about broad permissions for application tagging on EBS volumes were already raised in the previous review comments and remain valid.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (5)
96-97: LGTM: Additional read-only permissions for Profile Object Types
The new permissions are properly scoped and maintain the read-only nature of the statement.
149-163: Skipping comment as past review is still valid
The previous review comment about documenting new Wisdom message template capabilities is still applicable.
259-284: LGTM: Well-structured Chime SDK Voice Connector permissions
The permissions are properly implemented with:
- Separate statements for Get and List operations
- Resource-level and account-level conditions for enhanced security
285-338: LGTM: Comprehensive SES permissions with proper security controls
The SES-related statements implement proper security controls through:
- Account-level conditions
- Resource-specific ARNs where applicable
- Restricted PassRole permission
#!/bin/bash
# Verify the existence of the referenced SES configuration set
rg "configuration-set-for-connect-DO-NOT-DELETE"
# Verify the existence of the referenced IAM role
rg "AmazonConnectEmailSESAccessRole"80-87: LGTM: Enhanced Customer Profiles capabilities with proper scoping
The new permissions align with Customer Profiles service capabilities and are properly scoped to Connect domains.
✅ Verification successful
Profile permissions are properly scoped and consistent with existing usage
The new Customer Profiles permissions in AmazonConnectServiceLinkedRolePolicy.json are properly scoped to Amazon Connect domains (arn:aws:profile:*:*:domains/amazon-connect-*) and align with existing profile-related permissions across AWS services. The permissions are read-only or limited to specific Connect domain operations, following the principle of least privilege.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify if these new profile actions are used in the codebase
rg -l "profile:(List|Get|Create|Batch)(Integration|Segment|Profile|Attribute)"
Length of output: 417
Script:
#!/bin/bash
# Let's try a different search pattern to find any references to these profile actions
rg -i "profile" docs/source/_static/managed-policies/ -A 2 -B 2
Length of output: 290883
docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json (4)
8-11: LGTM: CloudTrail channel access is properly scoped.
The addition of GetServiceLinkedChannel alongside CreateServiceLinkedChannel follows the principle of least privilege by:
- Including only the necessary actions
- Restricting access to specific Resource Explorer channels using an ARN pattern
16-16: LGTM: API Gateway action format simplified.
The change from an array to a single string for apigateway:GET is a valid simplification since there's only one action.
Line range hint 28-439: LGTM: Additional list/describe permissions align with Resource Explorer's purpose.
The new permissions are appropriate for Resource Explorer as they:
- Only include read-only actions (List/Describe/Get)
- Enable discovery of resources across various AWS services
- Follow a consistent pattern of granting minimum required permissions for resource discovery
441-441: Consider implementing more granular resource restrictions.
While using "Resource": "*" is common for read-only list/describe operations (as many don't support resource-level permissions), consider:
- Using condition keys to restrict by region or account
- Implementing resource-level permissions where supported
Let's check which of these actions support resource-level permissions:
#!/bin/bash
# Description: Search for AWS IAM documentation to identify actions that support resource-level permissions
# Note: This is a basic check and may need manual verification
# Get all actions from the policy
rg '"Action":' -A 400 | grep -o '"[^"]*:[^"]*"' | tr -d '"' | sort -u > /tmp/actions.txt
# Search for documentation patterns that might indicate resource-level permission support
while IFS= read -r action; do
service=$(echo "$action" | cut -d':' -f1)
rg -l "resource-level permissions.*${service}" || rg -l "resource-specific permissions.*${service}"
done < /tmp/actions.txtdocs/source/_static/managed-policies/AWS_ConfigRole.json (7)
32-43: Review Amazon OpenSearch Serverless (AOSS) permissions
The new AOSS permissions follow AWS best practices by:
- Including both read operations (Get*) and list operations (List*)
- Following a consistent pattern for collection, policy, and security config management
190-195: Review CloudTrail channel permissions
The addition of CloudTrail channel-related permissions is consistent with existing CloudTrail permissions in the policy.
373-373: Remove redundant EC2 permission
The ec2:DescribeVpcEndpoints permission is redundant as it's already covered by the existing ec2:Describe* wildcard permission.
819-839: Review IVS (Interactive Video Service) permissions
The new IVS permissions are appropriately scoped to read-only operations and follow a consistent pattern of Get/List operations.
1442-1451: Review VPC Lattice permissions
The VPC Lattice permissions are appropriately scoped to read-only operations and follow AWS best practices for service discovery and monitoring.
1060-1064: Review Payment Cryptography permissions
The addition of payment-cryptography service permissions requires careful consideration:
- These permissions provide access to cryptographic keys and aliases
- Ensure this aligns with your security requirements
#!/bin/bash
# Check for any existing payment-cryptography resources
aws payment-cryptography list-keys --query 'Keys[*].KeyArn' --output text
aws payment-cryptography list-aliases --query 'Aliases[*].AliasArn' --output text141-150: Verify AWS Backup testing permissions scope
The new restore testing permissions are appropriately scoped to read-only operations. However, consider if these broad permissions align with the principle of least privilege for your Config role.
✅ Verification successful
AWS Config role's backup testing permissions are appropriately scoped
The restore testing permissions in the AWS Config role are correctly scoped to read-only operations and align with the principle of least privilege. These permissions are part of a broader set of read-only actions that AWS Config needs to assess and audit backup configurations, including:
- Listing backup resources (vaults, plans, frameworks)
- Describing backup configurations
- Reading restore testing plans and selections
The permissions do not grant any write or modify access, which is appropriate for AWS Config's monitoring and compliance assessment role.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any AWS Backup resources that might be affected
aws backup list-backup-vaults --query 'BackupVaultList[*].BackupVaultName' --output text
aws backup list-backup-plans --query 'BackupPlansList[*].BackupPlanId' --output text
Length of output: 395
Script:
#!/bin/bash
# Let's check the AWS Config role policy context and usage
rg -A 5 -B 5 "AWS_ConfigRole" .
Length of output: 45516
Script:
#!/bin/bash
# Check for any references to AWS Backup in the codebase
rg -l "backup:" .
Length of output: 2085
Script:
#!/bin/bash
# Check if there are any AWS Backup related configurations or resources defined
fd -e yaml -e yml -e json | xargs rg "backup" -l
Length of output: 2184
Script:
#!/bin/bash
# Let's examine the AWS Config role policy to understand the context of these permissions
rg -A 10 -B 10 '"backup:.*Testing' docs/source/_static/managed-policies/AWS_ConfigRole.json
Length of output: 1312
Script:
#!/bin/bash
# Check if there are any AWS Config rules or resources that use AWS Backup
rg -A 5 -B 5 'AWS::Backup' .
Length of output: 28
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (6)
32-43: LGTM: AOSS permissions follow AWS best practices
The new Amazon OpenSearch Serverless (AOSS) permissions are correctly scoped to read-only operations, following the principle of least privilege. The permissions are comprehensive for AWS Config to monitor AOSS resources.
189-189: Fix case inconsistency in CloudTrail service name
The service name has inconsistent casing between lines:
- Line 189:
cloudTrail:GetChannel - Line 194:
cloudTrail:ListChannels
vs other CloudTrail actions usingcloudtrail
Also applies to: 194-194
Line range hint 699-771: LGTM: IoT and IoTFleetwise permissions are properly structured
The new IoT and IoTFleetwise permissions are correctly organized and follow the read-only pattern required for AWS Config monitoring. The permissions cover all necessary resource types including billing groups, thing groups, and fleet management components.
817-837: LGTM: IVS and IVSChat permissions follow service patterns
The new Interactive Video Service (IVS) and IVSChat permissions maintain consistency with other service permissions in the policy:
- Read-only operations only
- Comprehensive coverage of resource types
- Follows AWS naming conventions
1440-1449: LGTM: VPC Lattice permissions are well-structured
The new VPC Lattice permissions follow AWS best practices:
- Read-only access for AWS Config monitoring
- Comprehensive coverage of VPC Lattice resources
- Consistent naming patterns
Line range hint 1-1500: Verify impact of extensive permission additions
This update adds numerous new permissions across multiple AWS services. While the additions follow proper patterns (read-only, descriptive operations), it's important to verify that these changes align with AWS Config's monitoring requirements.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (16)
87-88: LGTM: Account service permissions are appropriate for support role
The added permissions getRegionOptStatus and listRegions are read-only and necessary for AWS Support to help troubleshoot region-related issues.
117-132: LGTM: AOSS permissions follow least privilege principle
The added Amazon OpenSearch Serverless permissions are all read-only operations necessary for support and troubleshooting:
- Batch operations for collections, lifecycle policies, and VPC endpoints
- Access policy and security configuration operations
- List operations for various AOSS resources
133-147: LGTM: AppConfig permissions are appropriate
The added AppConfig permissions are read-only operations required for AWS Support to assist with application configuration issues:
- Get operations for applications, configurations, deployments, etc.
- List operations for various AppConfig resources
196-202: LGTM: Application Signals permissions follow security best practices
The added Application Signals permissions are read-only and necessary for AWS Support to help troubleshoot application monitoring and observability:
- Get operations for services and service level objectives
- List operations for dependencies and operations
589-600: LGTM: CodeConnections permissions align with support requirements
The added CodeConnections permissions are read-only operations necessary for AWS Support to assist with code integration issues:
- Get operations for connections, hosts, and repository links
- List operations for various CodeConnections resources
828-844: LGTM: Deadline permissions are appropriate for support role
The added Deadline permissions are read-only list operations required for AWS Support to help troubleshoot render farm and high-performance computing workloads.
1061-1061: LGTM: EC2 permissions follow security best practices
The added EC2 permissions are read-only operations necessary for AWS Support to assist with:
- Snapshot tier status information
- Subnet CIDR reservations
- IPAM-related operations
Also applies to: 1107-1107, 1136-1148
1199-1200: LGTM: EKS pod identity permissions are appropriate
The added EKS permissions for pod identity associations are read-only operations required for troubleshooting pod identity issues.
1251-1252: LGTM: EFS permissions follow least privilege
The added EFS permissions for backup policy and replication configurations are read-only operations necessary for support tasks.
1268-1270: LGTM: ELB trust store permissions are appropriate
The added Elastic Load Balancing permissions for trust stores are read-only operations required for SSL/TLS troubleshooting.
2357-2362: LGTM: OSIS permissions align with support requirements
The added OpenSearch Ingestion permissions are read-only operations necessary for troubleshooting ingestion pipelines.
2672-2678: LGTM: Route53 Profiles permissions follow security best practices
The added Route53 Profiles permissions are read-only operations required for DNS and traffic management support.
2929-2936: LGTM: SecurityHub permissions are appropriate
The added SecurityHub permissions are read-only operations necessary for security posture management support.
3432-3435: LGTM: WorkSpaces permissions follow least privilege
The added WorkSpaces permissions for application and workspace associations are read-only operations required for desktop virtualization support.
3447-3453: LGTM: X-Ray permissions align with support requirements
The added X-Ray permissions are read-only operations necessary for distributed tracing support:
- Resource policies
- Insight impact graphs
- Sampling and tracing operations
365-386: Verify usage of extensive Bedrock permissions
While the permissions are read-only, the broad scope of Bedrock permissions warrants verification of necessity for support operations.
✅ Verification successful
Let me gather more information about AWS Support's interaction with Bedrock services.
Bedrock read-only permissions are appropriate for AWS Support operations
The verification shows these Bedrock permissions are justified for the AWS Support service role:
- They match the read-only permissions pattern found in AWS ReadOnlyAccess policy, indicating these are standard read-only operations needed for service inspection
- The permissions are consistent with AWS Support's need to diagnose and troubleshoot Bedrock-related customer issues
- No write/modify permissions are included, maintaining the principle of least privilege
- The permissions align with other AWS service role policies that require Bedrock inspection capabilities (e.g., AWSAuditManagerServiceRolePolicy)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if these Bedrock permissions are referenced in AWS Support documentation
echo "Searching for Bedrock permissions usage in AWS Support documentation:"
rg -i "bedrock:(get|list)" --type md
Length of output: 1193
Script:
#!/bin/bash
# Search for Bedrock related documentation or references
echo "Searching for Bedrock mentions in documentation:"
rg -i "amazon bedrock" --type md -A 5 -B 5
# Search for support policy related files
echo -e "\nSearching for other AWS support service role policy files:"
fd "support.*policy" --type f
# Check if there are any other IAM policies with Bedrock permissions
echo -e "\nSearching for Bedrock permissions in other IAM policies:"
rg -i "bedrock:" --type json
Length of output: 16984
udondan
force-pushed
the
update-aws-managed-policies
branch
from
62e4fb1
to
70e6d31
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (1)
195-208: LGTM: Well-structured segmentation permissionsThe new permissions for segment definitions are properly scoped and follow AWS best practices for resource-level permissions.
Consider implementing appropriate caching strategies for segment snapshots to optimize performance and reduce costs, especially for frequently accessed segments.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (1)
Line range hint
1-1524: Consider organizing permissions by service categoryWhile the permissions are comprehensive, consider organizing them into logical service categories (e.g., Security Services, Analytics Services, etc.) using separate Sid blocks for better maintainability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (2)
lib/generated/aws-managed-policies/cdk-iam-floyd.tsis excluded by!**/generated/**lib/generated/aws-managed-policies/iam-floyd.tsis excluded by!**/generated/**
📒 Files selected for processing (82)
docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSBackupFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json(2 hunks)docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json(1 hunks)docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json(1 hunks)docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json(26 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json(11 hunks)docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json(1 hunks)docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json(2 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json(1 hunks)docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json(2 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json(2 hunks)docs/source/_static/managed-policies/AWSIPAMServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSLicenseManagerUserSubscriptionsServiceRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json(2 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json(2 hunks)docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json(13 hunks)docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json(2 hunks)docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json(25 hunks)docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AWS_ConfigRole.json(27 hunks)docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonBedrockReadOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json(2 hunks)docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json(1 hunks)docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json(1 hunks)docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json(1 hunks)docs/source/_static/managed-policies/AmazonECS_FullAccess.json(8 hunks)docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSComputePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonEKSServicePolicy.json(3 hunks)docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json(5 hunks)docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemFullAccess.json(3 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json(2 hunks)docs/source/_static/managed-policies/AmazonElasticFileSystemServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json(1 hunks)docs/source/_static/managed-policies/AmazonQDeveloperAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonQFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json(0 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json(1 hunks)docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json(1 hunks)
⛔ Files not processed due to max files limit (23)
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsFullAccess.json
- docs/source/_static/managed-policies/AmazonVerifiedPermissionsReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json
- docs/source/_static/managed-policies/CloudWatchInternetMonitorFullAccess.json
- docs/source/_static/managed-policies/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.json
- docs/source/_static/managed-policies/CloudWatchSyntheticsFullAccess.json
- docs/source/_static/managed-policies/ElasticLoadBalancingFullAccess.json
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/ReadOnlyAccess.json
- docs/source/_static/managed-policies/ResourceGroupsTaggingAPITagUntagSupportedResources.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/SecurityAudit.json
- docs/source/_static/managed-policies/ViewOnlyAccess.json
- docs/source/_static/managed-policies/index.json
💤 Files with no reviewable changes (3)
- docs/source/_static/managed-policies/AWSReachabilityAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSBetaServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonRDSPreviewServiceRolePolicy.json
🚧 Files skipped from review as they are similar to previous changes (72)
- docs/source/_static/managed-policies/AWSApplicationAutoscalingECSServicePolicy.json
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSBackupFullAccess.json
- docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json
- docs/source/_static/managed-policies/AWSCloudFrontVPCOriginServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantOwnerFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeDataGrantReceiverFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDataExchangeReadOnly.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json
- docs/source/_static/managed-policies/AWSDataSyncFullAccess.json
- docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json
- docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSElasticLoadBalancingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSGlobalAcceleratorSLRPolicy.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSIPAMServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSLicenseManagerUserSubscriptionsServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsFullAccess.json
- docs/source/_static/managed-policies/AWSMarketplaceSellerProductsReadOnly.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json
- docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSTrustedAdvisorServiceRolePolicy.json
- docs/source/_static/managed-policies/AccessAnalyzerServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonDataZoneRedshiftGlueProvisioningPolicy.json
- docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json
- docs/source/_static/managed-policies/AmazonEKSBlockStoragePolicy.json
- docs/source/_static/managed-policies/AmazonEKSClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSComputePolicy.json
- docs/source/_static/managed-policies/AmazonEKSLoadBalancingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSLocalOutpostClusterPolicy.json
- docs/source/_static/managed-policies/AmazonEKSNetworkingPolicy.json
- docs/source/_static/managed-policies/AmazonEKSServicePolicy.json
- docs/source/_static/managed-policies/AmazonEKSServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonEKSWorkerNodeMinimalPolicy.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemFullAccess.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonElasticFileSystemServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonGuardDutyServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonInspector2ServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonOpenSearchServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonQDeveloperAccess.json
- docs/source/_static/managed-policies/AmazonQFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSNSFullAccess.json
- docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
🔇 Additional comments (57)
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (3)
71-75: LGTM for Bedrock actions
The added Bedrock actions appropriately prevent both resource creation and model invocation, which could be exploited in a compromised key scenario.
80-81: LGTM for SageMaker actions
The added SageMaker actions appropriately prevent creation of endpoints and processing jobs, which could be exploited for resource abuse or malicious workloads.
86-89: LGTM for application service actions
The added denials for Amplify, CodeBuild, and Glue appropriately prevent creation of new resources that could be exploited in a compromised key scenario.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (6)
Line range hint 128-137: LGTM! Well-scoped SSM parameter access
The SSM parameter access is properly restricted to ECS-specific parameters using an appropriate resource ARN pattern.
Line range hint 156-213: LGTM! Well-structured PassRole permissions
The PassRole permissions are properly segmented and conditioned:
- Tasks: Restricted to ecs-tasks.amazonaws.com
- Infrastructure: Specific to ecsInfrastructureRole
- Instance: Limited to EC2 service and ecsInstanceRole
- AutoScaling: Constrained to autoscaling service and ecsAutoscaleRole
Line range hint 214-230: LGTM! Appropriate service-linked role creation permissions
The service-linked role creation is properly restricted to necessary ECS-related services.
Line range hint 231-247: LGTM! Well-conditioned ELB tagging permissions
The tagging permissions are appropriately restricted to resource creation actions, following AWS best practices.
Line range hint 138-155: LGTM! Properly conditioned cleanup permissions
The deletion permissions are appropriately restricted to ECS-managed resources through the CloudFormation stack name condition.
Let's verify the stack name pattern is consistent with ECS:
#!/bin/bash
# Description: Check for CloudFormation stack name patterns in ECS documentation
rg -A 2 "EC2ContainerService-" Line range hint 5-127: Consider adding resource-level restrictions for critical permissions
While broad permissions are often needed for ECS service integration, consider restricting critical permissions where possible:
- EC2
RunInstancescould be limited to specific instance types or AMIs - CloudFormation actions could be scoped to specific stack name patterns
- CloudWatch and Logs actions could be restricted to ECS-specific resources
Let's verify if any of these permissions can be restricted based on AWS documentation:
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (5)
96-97: LGTM: Read-only profile object type permissions
The added read-only permissions for profile object types are properly scoped and follow the principle of least privilege.
149-163: Referencing existing documentation review comment
The previous review comment about updating documentation for new Wisdom message template permissions is still valid and applicable.
259-284: LGTM: Secure Voice Connector permissions
The Chime SDK Voice Connector permissions are well-structured with appropriate security controls:
- Account-level isolation using
aws:ResourceAccount - Additional tag-based control for GetVoiceConnector
286-338: LGTM: Well-structured SES permissions with proper isolation
The SES-related permissions are properly structured with:
- Account-level isolation
- Specific resource ARNs where applicable
- Properly scoped PassRole permission
#!/bin/bash
# Verify the existence and protection of the DO-NOT-DELETE configuration set
rg -l "configuration-set-for-connect-DO-NOT-DELETE"
# Check for any deletion-related permissions on this configuration set
rg "configuration-set-for-connect-DO-NOT-DELETE.*Delete"80-87: LGTM: Customer Profiles permissions are properly scoped
The new permissions for profile integrations and segmentation operations are correctly scoped to Connect domains using the appropriate resource ARN pattern.
✅ Verification successful
Customer Profiles permissions are properly implemented with appropriate resource constraints
The verification confirms that:
- All new profile permissions (ListIntegrations, ListSegmentDefinitions, etc.) are correctly scoped to Connect domains with the resource pattern
arn:aws:profile:*:*:domains/amazon-connect-* - The permissions follow a logical grouping with separate statements for different functionality (basic profile operations, object types, segmentation)
- Resource-level permissions are properly applied with specific ARN patterns for each permission group
- The least privilege principle is maintained as permissions are limited to specific Connect domain resources
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that these permissions align with the AWS Customer Profiles API documentation
curl -s https://awscli.amazonaws.com/v2/documentation/api/latest/reference/customer-profiles/index.html | grep -A 2 -B 2 "profile:ListSegmentDefinitions\|profile:ListProfileAttributeValues\|profile:CreateSegmentEstimate"
Length of output: 283
Script:
#!/bin/bash
# Let's verify the policy structure and resource constraints
cat docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json | jq -r '.Statement[] | select(.Action | arrays and (arrays | any(contains("profile:"))))'
# Also check for any related documentation or comments
rg -A 3 -B 3 "Customer Profiles" docs/
Length of output: 2695
docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json (4)
8-11: LGTM: CloudTrail channel operations are properly scoped.
The addition of GetServiceLinkedChannel alongside CreateServiceLinkedChannel is logical and follows the principle of least privilege by using a specific resource ARN pattern.
16-16: LGTM: API Gateway action simplification.
The change from an array to a single string for apigateway:GET improves readability while maintaining the same permissions.
441-441:
Caution: Broad resource access granted.
The change from specific resource ARNs to "Resource": "*" significantly broadens the scope of this policy.
Consider one of these alternatives:
- Use resource-level permissions where supported by the service
- Add condition keys to restrict access by region or account
- Split the policy into multiple statements with more granular resource definitions
Example with condition keys:
- "Resource": "*"
+ "Resource": "*",
+ "Condition": {
+ "StringEquals": {
+ "aws:RequestedRegion": ["us-west-2", "us-east-1"]
+ }
+ }Line range hint 28-439: Verify the necessity of newly added permissions.
The policy adds numerous list/describe actions across various AWS services. While these are read-only operations, it's important to ensure that each addition is necessary for Resource Explorer's functionality.
Run this script to analyze the new permissions:
docs/source/_static/managed-policies/AWS_ConfigRole.json (18)
32-43: LGTM: AOSS permissions follow least privilege principle
The new Amazon OpenSearch Serverless (AOSS) permissions are appropriately scoped to read-only operations needed for AWS Config to monitor AOSS resources.
45-50: LGTM: App Integrations permissions are properly scoped
The added App Integrations permissions are correctly limited to read-only operations required for AWS Config's monitoring capabilities.
141-150: LGTM: AWS Backup permissions align with service requirements
The new AWS Backup permissions for restore testing plans are appropriately scoped to read-only access needed for AWS Config's assessment capabilities.
190-195: LGTM: CloudTrail permissions follow service patterns
The additional CloudTrail permissions for channels and event data stores follow the established pattern of read-only access required for AWS Config service.
Line range hint 259-284: LGTM: Connect permissions maintain least privilege
The Amazon Connect permissions are properly scoped to read-only operations necessary for AWS Config to monitor Connect resources.
373-373: Remove redundant EC2 permission
The ec2:DescribeVpcEndpoints permission is redundant as it's already covered by the existing ec2:Describe* wildcard permission.
Line range hint 701-738: LGTM: IoT permissions are well-structured
The IoT permissions for billing groups, thing groups, and thing types are appropriately limited to read-only operations required for AWS Config's monitoring capabilities.
759-773: LGTM: IoT FleetWise permissions follow best practices
The IoT FleetWise permissions are correctly scoped to read-only operations necessary for AWS Config to monitor FleetWise resources.
801-817: LGTM: IoT Wireless permissions maintain security
The IoT Wireless permissions are appropriately limited to read-only access required for AWS Config's assessment capabilities.
819-839: LGTM: IVS permissions follow service requirements
The Amazon Interactive Video Service (IVS) permissions are properly scoped to read-only operations needed for AWS Config service.
930-934: LGTM: CloudWatch Logs permissions are appropriate
The additional CloudWatch Logs permissions for anomaly detectors are correctly limited to read-only access.
962-983: LGTM: Media service permissions follow patterns
The MediaConnect and MediaTailor permissions are appropriately scoped to read-only operations required for AWS Config's monitoring capabilities.
1027-1031: LGTM: OAM and Omics permissions maintain least privilege
The Observability Access Manager (OAM) and Omics permissions are properly limited to read-only operations necessary for AWS Config service.
1060-1064: LGTM: Payment Cryptography permissions are well-scoped
The Payment Cryptography permissions are appropriately limited to read-only operations required for AWS Config's assessment capabilities.
1122-1123: LGTM: RDS Proxy permissions follow best practices
The RDS Proxy permissions for target groups and targets are correctly scoped to read-only access.
1273-1281: LGTM: S3 Storage Lens permissions maintain security
The S3 Storage Lens permissions for groups are appropriately limited to read-only operations needed for AWS Config service.
1327-1331: LGTM: Scheduler permissions follow service patterns
The EventBridge Scheduler permissions are properly scoped to read-only operations required for AWS Config's monitoring capabilities.
1442-1451: LGTM: VPC Lattice permissions are well-structured
The VPC Lattice permissions are appropriately limited to read-only operations necessary for AWS Config to monitor Lattice resources.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (4)
32-43: LGTM: Well-structured AOSS permissions block
The new Amazon OpenSearch Serverless (AOSS) permissions are logically grouped and follow the principle of least privilege by including only read operations.
140-149: LGTM: Comprehensive Backup service permissions
The new AWS Backup permissions for restore testing capabilities are properly scoped to read-only operations and maintain consistency with existing backup permissions.
1058-1062: LGTM: Essential Payment Cryptography read permissions
The Payment Cryptography permissions are appropriately limited to read-only operations for keys and aliases.
1440-1449: LGTM: Complete VPC Lattice read permissions
The VPC Lattice permissions follow best practices by including all necessary read operations for managing access logs, services, and target groups.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (17)
87-88: LGTM: Account service permissions are appropriate for support role
The added permissions account:getRegionOptStatus and account:listRegions are read-only operations that allow the support role to view region-related information, which is necessary for troubleshooting region-specific issues.
117-132: LGTM: AOSS permissions follow least privilege principle
The added Amazon OpenSearch Serverless (AOSS) permissions are all read-only operations that allow viewing configurations, policies, and resources. This aligns with the support role's need to diagnose OpenSearch Serverless issues.
133-147: LGTM: AppConfig permissions are appropriately scoped
The added AppConfig permissions are read-only operations that allow viewing applications, configurations, deployments, and environments. These are necessary for troubleshooting application configuration issues.
196-202: LGTM: Application Signals permissions follow service role pattern
The added Application Signals permissions are read-only operations that allow viewing service metrics and objectives, which is appropriate for the support role's monitoring and troubleshooting capabilities.
365-386: LGTM: Bedrock permissions align with service requirements
The added Amazon Bedrock permissions are read-only operations focused on retrieving information about agents, models, and knowledge bases. This is consistent with the support role's need to troubleshoot AI/ML workloads.
589-600: LGTM: CodeConnections permissions maintain read-only access
The added CodeConnections permissions are appropriately scoped to read-only operations for viewing connections, hosts, and repository links.
828-844: LGTM: Deadline permissions follow least privilege
The added AWS Thinkbox Deadline permissions are read-only operations for viewing render farm resources and configurations, which is appropriate for support scenarios.
1061-1061: LGTM: EC2 permissions are properly scoped
The added EC2 permissions are read-only operations focused on:
- Snapshot tier status
- Subnet CIDR reservations
- IPAM-related operations
These additions maintain the principle of least privilege while enabling support for EC2 networking and storage features.
Also applies to: 1107-1107, 1136-1148
1199-1200: LGTM: EKS pod identity permissions are appropriate
The added EKS permissions for describing and listing pod identity associations are read-only operations necessary for troubleshooting pod identity issues in EKS clusters.
1251-1252: LGTM: EFS permissions maintain read-only access
The added EFS permissions for describing backup policy and replication configurations are appropriately scoped read-only operations.
1268-1270: LGTM: ELB trust store permissions follow service patterns
The added Elastic Load Balancing permissions for trust stores are read-only operations that align with the support role's need to troubleshoot TLS/SSL configurations.
1944-1945: LGTM: Launch Wizard permissions are properly scoped
The added Launch Wizard permissions for listing deployments and deployment events are read-only operations appropriate for deployment troubleshooting.
2357-2362: LGTM: OSIS permissions follow least privilege
The added OpenSearch Ingestion Service (OSIS) permissions are read-only operations for viewing pipelines and blueprints, maintaining the principle of least privilege.
2672-2678: LGTM: Route53 Profiles permissions are appropriate
The added Route53 Profiles permissions are read-only operations that allow viewing profiles and associations, which is necessary for DNS troubleshooting.
2929-2936: LGTM: Security Hub permissions maintain security posture
The added Security Hub permissions are read-only operations for viewing configuration policies and finding aggregators, appropriate for security monitoring support.
3432-3435: LGTM: Workspaces permissions follow service patterns
The added Workspaces permissions for describing application associations, workspace associations, pools, and pool sessions are read-only operations necessary for workspace troubleshooting.
3447-3453: LGTM: X-Ray permissions enable proper monitoring
The added X-Ray permissions are read-only operations that enhance the support role's ability to view traces, graphs, and statistics for application monitoring.
| "cloudTrail:GetChannel", | ||
| "cloudtrail:GetEventDataStore", | ||
| "cloudtrail:GetEventSelectors", | ||
| "cloudtrail:GetInsightSelectors", | ||
| "cloudtrail:GetTrailStatus", | ||
| "cloudTrail:ListChannels", |
There was a problem hiding this comment.
Fix case inconsistency in CloudTrail service names
The CloudTrail service name has inconsistent casing which should be standardized:
- "cloudTrail:GetChannel",
+ "cloudtrail:GetChannel",
- "cloudTrail:ListChannels",
+ "cloudtrail:ListChannels",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "cloudTrail:GetChannel", | |
| "cloudtrail:GetEventDataStore", | |
| "cloudtrail:GetEventSelectors", | |
| "cloudtrail:GetInsightSelectors", | |
| "cloudtrail:GetTrailStatus", | |
| "cloudTrail:ListChannels", | |
| "cloudtrail:GetChannel", | |
| "cloudtrail:GetEventDataStore", | |
| "cloudtrail:GetEventSelectors", | |
| "cloudtrail:GetInsightSelectors", | |
| "cloudtrail:GetTrailStatus", | |
| "cloudtrail:ListChannels", |
| "iotfleetwise:GetDecoderManifest", | ||
| "iotfleetwise:GetFleet", | ||
| "iotfleetwise:GetModelManifest", | ||
| "iotfleetwise:GetSignalCatalog", | ||
| "iotfleetwise:GetVehicle", | ||
| "iotfleetwise:ListDecoderManifestNetworkInterfaces", | ||
| "iotfleetwise:ListDecoderManifests", | ||
| "iotfleetwise:ListDecoderManifestSignals", | ||
| "iotfleetwise:ListFleets", | ||
| "iotfleetwise:ListModelManifestNodes", | ||
| "iotfleetwise:ListModelManifests", | ||
| "iotfleetwise:ListSignalCatalogNodes", | ||
| "iotfleetwise:ListSignalCatalogs", | ||
| "iotfleetwise:ListTagsForResource", | ||
| "iotfleetwise:ListVehicles", |
There was a problem hiding this comment.
💡 Codebase verification
Based on comparing the permissions across different policies, particularly the ReadOnlyAccess policy which typically includes all read operations, I can now provide a final response:
IoTFleetwise permissions in Config role are missing several read operations
The current permissions list is missing several read operations that are available in the service:
GetCampaignGetLoggingOptionsGetRegisterAccountStatusGetVehicleStatusListCampaignsListFleetsForVehicleListVehiclesInFleet
These operations are present in the ReadOnlyAccess policy but missing in the AWSConfigServiceRolePolicy, suggesting they might be relevant for AWS Config's resource inventory and configuration tracking capabilities.
🔗 Analysis chain
Verify IoTFleetwise permissions completeness
The IoTFleetwise permissions block appears comprehensive but should be verified against the service's latest API requirements.
Let me try to verify this by checking the policy file more thoroughly and comparing with other AWS service policies in the codebase.
Let me check the IoTFleetwise service role policy specifically, as it would be the most comprehensive policy for this service.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify completeness of IoTFleetwise permissions against AWS API
# Test: Compare listed permissions with AWS API operations
aws service-model-get --service-name iotfleetwise --docs-output text 2>/dev/null | grep -i "operation name" || \
echo "Note: This is a verification step. In a real environment, this would check against AWS API specifications."
Length of output: 320
Script:
#!/bin/bash
# Search for other IoTFleetwise permissions in policy files
rg -i "iotfleetwise:" docs/source/_static/managed-policies/
# Check if there are any other policy files that might contain IoTFleetwise permissions
fd -e json -e yaml . docs/source/_static/managed-policies/ --exec grep -l -i "iotfleetwise"
Length of output: 8081
Script:
#!/bin/bash
# Check the IoTFleetwise service role policy for complete list of permissions
cat docs/source/_static/managed-policies/AWSIoTFleetwiseServiceRolePolicy.json
Length of output: 398
udondan
force-pushed
the
update-aws-managed-policies
branch
6 times, most recently
from
da76aa4
to
5735b55
Compare
udondan
force-pushed
the
update-aws-managed-policies
branch
4 times, most recently
from
58a38c2
to
34b14b7
Compare
udondan
force-pushed
the
update-aws-managed-policies
branch
from
34b14b7
to
3bb8421
Compare
Updates AWS managed policies