Updates AWS managed policies #878
Conversation
WalkthroughRecent updates to various AWS IAM policies introduce new permissions and modifications aimed at enhancing resource management and security. Key changes include the addition of permissions for listing guardrails in the AWS Audit Manager, expanded permissions for AWS Backup and AWS Config services, and the introduction of new policies for compromised key quarantine. The AWS Data Exchange policy has also been enhanced with detailed permissions, while the AWS Directory Service policy provides comprehensive access controls. Overall, these changes refine permissions across multiple services 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
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (1)
lib/generated/aws-managed-policies/cdk-iam-floyd.ts (1)
4482-4485: Approved with a minor note.The new method
AWSPCSServiceRolePolicy()looks good and follows the established pattern. It grants the necessary permissions to the PCS service to manage AWS resources on the user's behalf.One minor note: The full service name for the "PCS" acronym is not clear from the provided context. Consider expanding the acronym in the comment for better clarity, if possible.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (46)
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json (1 hunks)
- docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (13 hunks)
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json (1 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 (1 hunks)
- docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.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 (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 hunks)
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json (1 hunks)
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4 hunks)
- docs/source/_static/managed-policies/AmazonECS_FullAccess.json (8 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/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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
- lib/generated/aws-managed-policies/cdk-iam-floyd.ts (5 hunks)
- lib/generated/aws-managed-policies/iam-floyd.ts (5 hunks)
Files not reviewed due to 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 (37)
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonECS_FullAccess.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/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/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
Additional context used
Gitleaks
lib/generated/aws-managed-policies/iam-floyd.ts
1226-1226: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Additional comments not posted (41)
docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (3)
24-37: LGTM!The new statement allows users to tag Glue session resources that they own, as determined by the owner tag. This aligns with the principle of least privilege and helps prevent unauthorized tagging.
Line range hint
1-1: Removed action aligns with the new allow statement.The removal of the
"glue:TagResource"action from the statement with"Sid": "NotebookDenyActions", combined with the addition of the allow statement for"glue:TagResource"(reviewed earlier), indicates a policy change.The policy now allows users to tag resources that they own, while still denying other tagging actions like untagging. This change aligns with the principle of least privilege.
106-107: Verify the impact of expanding the role pattern.The change allows the
iam:PassRoleaction on roles that match theAwsGlueSessionUserRestrictedNotebookServiceRole*pattern. This expands the set of roles that can be passed to the Glue service.Please verify that this change is intended and does not allow unintended roles to be passed.
Run the following script to verify the roles that match the new pattern:
Verification successful
Verified: Role pattern expansion is present and properly scoped
The change allowing the
iam:PassRoleaction on roles matching theAwsGlueSessionUserRestrictedNotebookServiceRole*pattern is confirmed in the policy file. This expansion coexists with the previous pattern and is limited to the AWS Glue service through a condition.
- Both patterns are present in
docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json- The
iam:PassedToServicecondition restricts these roles toglue.amazonaws.comThis change appears to be a controlled expansion of allowed roles within the AWS Glue service context, likely accommodating new role naming conventions or additional use cases.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the roles that match the new pattern. # Test: Search for roles that match the new pattern. Expect: Only intended roles. rg --type json $'"AwsGlueSessionUserRestrictedNotebookServiceRole\*"' | awk -F: '{print $1}' | sort -u | xargs -I{} sh -c 'echo "Verifying role pattern in {}"; grep $'"AwsGlueSessionUserRestrictedNotebookServiceRole\*"' {}'Length of output: 222
Script:
#!/bin/bash # Step 1: Find the policy file echo "Searching for the policy file:" fd -e json AwsGlueSessionUserRestrictedNotebookPolicy # Step 2: Verify the existence of both old and new patterns echo -e "\nChecking for the old and new patterns:" rg -i "AwsGlueSessionServiceRoleUserRestrictedForNotebook" $(fd -e json AwsGlueSessionUserRestrictedNotebookPolicy) rg -i "AwsGlueSessionUserRestrictedNotebookServiceRole" $(fd -e json AwsGlueSessionUserRestrictedNotebookPolicy) # Step 3: Analyze the context (show 5 lines before and after) echo -e "\nAnalyzing the context of the patterns:" rg -i -C 5 "AwsGlueSessionServiceRoleUserRestrictedForNotebook" $(fd -e json AwsGlueSessionUserRestrictedNotebookPolicy) rg -i -C 5 "AwsGlueSessionUserRestrictedNotebookServiceRole" $(fd -e json AwsGlueSessionUserRestrictedNotebookPolicy)Length of output: 2106
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4)
80-87: LGTM!The added permissions expand the capabilities related to profile management, such as listing integrations, segment definitions, and profile attribute values. It also introduces permissions for creating and retrieving segment estimates, batch-getting profiles and calculated attributes, and getting segment memberships. These changes align with the objective of enhancing the functionality for managing customer profiles within the Amazon Connect environment.
96-97: LGTM!The added permission
ListObjectTypeAttributesexpands the read permissions for customer profile objects, enabling access to object type attributes. This change aligns with the overall objective of enhancing the functionality related to customer profiles.
149-163: LGTM!The added permissions significantly expand the capabilities related to managing message templates within the wisdom service. It introduces permissions for creating, updating, retrieving, deleting, listing, and searching message templates. It also includes permissions for activating/deactivating message templates, managing message template versions and attachments, and rendering message templates. These changes indicate a focus on improving user engagement and content management within the Amazon Connect environment.
195-207: LGTM!The new permission block "AllowCustomerProfilesSegmentationForConnectDomain" focuses on segment definition management for customer profiles. It introduces permissions for creating, retrieving, and deleting segment definitions, as well as creating and retrieving segment snapshots. These changes suggest an enhancement in the segmentation capabilities for customer profiles, allowing for more tailored and effective customer interactions.
docs/source/_static/managed-policies/AWS_ConfigRole.json (15)
32-43: LGTM!The added permissions for Amazon OpenSearch Service (AOSS) enhance the AWS Config Role's capabilities to manage AOSS resources effectively. The included actions, such as
BatchGetCollection,ListCollections,GetAccessPolicy, etc., allow retrieving details and listing AOSS collections, endpoints, policies, and more. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
89-89: LGTM!The added permission
DescribeAppBlockBuildersfor AWS AppStream service enhances the AWS Config Role's capability to retrieve details about AppStream resources. This aligns with the overall objective of expanding the role's capabilities across various AWS services.
136-137: LGTM!The added permissions
GetRestoreTestingPlanandGetRestoreTestingSelectionfor AWS Backup service enhance the AWS Config Role's capability to retrieve details about AWS Backup restore testing plans and selections. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
144-145: LGTM!The added permissions
ListRestoreTestingPlansandListRestoreTestingSelectionsfor AWS Backup service enhance the AWS Config Role's capability to list AWS Backup restore testing plans and selections. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
185-189: LGTM!The added permissions
GetChannelandListChannelsfor AWS CloudTrail service enhance the AWS Config Role's capability to retrieve details and list AWS CloudTrail channels. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
354-354: LGTM!The added permission
DescribeVpcEndpointsfor Amazon EC2 service enhances the AWS Config Role's capability to retrieve details about VPC endpoints in EC2. This aligns with the overall objective of expanding the role's capabilities across various AWS services.
568-574: LGTM!The added permissions
GetTriggerandListTriggersfor AWS Glue service enhance the AWS Config Role's capability to retrieve details and list AWS Glue triggers. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
Line range hint
659-669: LGTM!The added permissions
GetLifecyclePolicyandListLifecyclePoliciesfor AWS Image Builder service enhance the AWS Config Role's capability to retrieve details and list AWS Image Builder lifecycle policies. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
Line range hint
676-693: LGTM!The added permissions for AWS IoT service, such as
DescribeBillingGroup,ListBillingGroups, etc., enhance the AWS Config Role's capability to retrieve details and list various AWS IoT resources like billing groups. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
769-782: LGTM!The added permissions for Amazon Interactive Video Service (IVS), such as
GetEncoderConfiguration,ListEncoderConfigurations,GetPlaybackRestrictionPolicy,ListPlaybackRestrictionPolicies,GetStage,ListStages,GetStorageConfiguration,ListStorageConfigurations, enhance the AWS Config Role's capability to retrieve details and list various Amazon IVS resources like encoder configurations, playback restriction policies, stages, and storage configurations. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
905-910: LGTM!The added permissions for AWS MediaConnect service, such as
DescribeBridge,DescribeGateway,ListBridges,ListGateways, enhance the AWS Config Role's capability to retrieve details and list AWS MediaConnect resources like bridges and gateways. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
917-926: LGTM!The added permissions for AWS MediaTailor service, such as
DescribeChannel,DescribeLiveSource,DescribeSourceLocation,DescribeVodSource,ListChannels,ListLiveSources,ListSourceLocations,ListVodSources, enhance the AWS Config Role's capability to retrieve details and list AWS MediaTailor resources like channels, live sources, source locations, and VOD sources. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
970-971: LGTM!The added permissions
GetWorkflowandListWorkflowsfor Amazon Omics service enhance the AWS Config Role's capability to retrieve details and list Amazon Omics workflows. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
1256-1257: LGTM!The added permissions
GetScheduleandListSchedulesfor AWS Scheduler service enhance the AWS Config Role's capability to retrieve details and list AWS Scheduler schedules. These permissions align with the overall objective of expanding the role's capabilities across various AWS services.
1308-1308: LGTM!The added permission
ListTagsForResourcefor AWS Systems Manager SAP service enhances the AWS Config Role's capability to list tags for AWS Systems Manager SAP resources. This aligns with the overall objective of expanding the role's capabilities across various AWS services.docs/source/_static/managed-policies/ReadOnlyAccess.json (14)
111-111: LGTM!The
application-signals:ListServicespermission is a read-only operation that aligns with the read-only access intent of the policy.
Line range hint
225-242: LGTM!The
bedrock:GetGuardrailandbedrock:ListGuardrailspermissions are read-only operations that align with the read-only access intent of the policy.
275-275: LGTM!The
budgets:ListTagsForResourcepermission is a read-only operation that aligns with the read-only access intent of the policy.
318-328: LGTM!The
cleanrooms-mlpermissions likeGetAudienceGenerationJob,GetAudienceModel,ListAudienceModels, etc. are all read-only operations that align with the read-only access intent of the policy.
906-906: LGTM!The
glue:GetTablespermission is a read-only operation that aligns with the read-only access intent of the policy.
Line range hint
1096-1138: LGTM!The
iotwireless:GetMetricsandiotwireless:ListTagsForResourcepermissions are read-only operations that align with the read-only access intent of the policy.
1143-1157: LGTM!The
ivspermissions likeGetStage,GetStageSession,ListParticipants,ListStreamsare all read-only operations that align with the read-only access intent of the policy.
1279-1284: LGTM!The
lex:ListBotAliasReplicasandlex:ListBotVersionReplicaspermissions are read-only operations that align with the read-only access intent of the policy.
1695-1699: LGTM!The
pca-connector-sceppermissions likeGetChallengeMetadata,GetConnector,ListChallengeMetadata,ListConnectorsare all read-only operations that align with the read-only access intent of the policy.
Line range hint
1842-1857: LGTM!The
resiliencehub:DescribeResourceGroupingRecommendationTaskandresiliencehub:ListResourceGroupingRecommendationspermissions are read-only operations that align with the read-only access intent of the policy.
1922-1938: LGTM!The
s3-outpostspermissions likeGetBucketVersioning,GetObject,GetObjectTagging,GetReplicationConfiguration,ListBucket,ListMultipartUploadParts, etc. are all read-only operations that align with the read-only access intent of the policy.
2072-2082: LGTM!The
ssm-sappermissions likeGetApplication,GetComponent,GetDatabase,ListApplications,ListComponents,ListDatabases, etc. are all read-only operations that align with the read-only access intent of the policy.
2165-2172: LGTM!The
trustedadvisorpermissions likeGetOrganizationRecommendation,GetRecommendation,ListChecks,ListOrganizationRecommendations,ListRecommendations, etc. are all read-only operations that align with the read-only access intent of the policy.
2173-2175: LGTM!The
user-subscriptionspermissionsListApplicationClaims,ListClaims, andListUserSubscriptionsare all read-only operations that align with the read-only access intent of the policy.lib/generated/aws-managed-policies/iam-floyd.ts (2)
761-762: LGTM!The new
AmazonSageMakerHyperPodServiceRolePolicyproperty is added correctly with a clear comment describing its purpose. The naming follows the existing convention.
1225-1226: Code looks good, but please ignore the static analysis hint.The new
AWSCompromisedKeyQuarantineV3property is added correctly with a clear comment explaining its purpose to limit damage when IAM user credentials are compromised.Note that the static analysis hint from Gitleaks flagging this as a "Generic API Key" is a false positive. This policy name just happens to contain the word "Key" but it is not actually exposing any sensitive keys. So this hint can be safely ignored.
Tools
Gitleaks
1226-1226: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
lib/generated/aws-managed-policies/cdk-iam-floyd.ts (3)
1907-1910: LGTM!The new method
AmazonSageMakerHyperPodServiceRolePolicy()looks good. It provides access to the AWS managed policy for Amazon SageMaker HyperPod service role, following the same pattern as other methods in the class.
3067-3070: Looks good!The new method
AWSCompromisedKeyQuarantineV3()provides access to the AWS managed policy that is applied in case of compromised IAM user credentials. The comment provides clear instructions to users.
Line range hint
5287-5290: Looks good to me!The new method
AmazonWorkSpacesThinClientFullAccess()is implemented correctly. It provides full access to Amazon WorkSpaces Thin Client and limited access to the necessary related services, as indicated in the comment. The code follows the established structure of theAwsManagedPolicyclass.
udondan
force-pushed
the
update-aws-managed-policies
branch
from
f7daa52
to
97e2eaa
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (1)
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (1)
Line range hint
56-64: Remove permission to delete the AWS Support service role.Granting the AWS Support service role permission to delete itself via
iam:DeleteRoleis not recommended. This permission seems unnecessary and violates least privilege.Consider removing this entire statement block to prevent unintended deletion of the AWS Support service role.
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 (44)
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json (1 hunks)
- docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (13 hunks)
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json (1 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 (1 hunks)
- docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.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 (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 hunks)
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json (1 hunks)
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4 hunks)
- docs/source/_static/managed-policies/AmazonECS_FullAccess.json (8 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/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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
Files not reviewed due to 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 due to trivial changes (1)
- docs/source/_static/managed-policies/AmazonRoute53ResolverReadOnlyAccess.json
Files skipped from review as they are similar to previous changes (36)
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonECS_FullAccess.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/AmazonRoute53ProfilesFullAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ProfilesReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonRoute53ResolverFullAccess.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/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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
Additional comments not posted (33)
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4)
80-87: LGTM!The added permissions enhance the capabilities of Amazon Connect to manage and analyze customer profiles effectively. The ability to list segment definitions, retrieve profile attribute values, create segment estimates, and perform batch operations on profiles can improve targeted customer engagement, personalization, and efficiency when dealing with large volumes of customer data.
96-97: Looks good!The added permission to list attributes of profile object types aligns with the read-only nature of the "AllowReadPermissionForCustomerProfileObjects" statement. This permission can provide valuable insights into the structure and properties of customer profile objects, which can be useful for data modeling, reporting, and integration with other systems.
149-163: Excellent additions!The added permissions significantly expand the capabilities of Amazon Connect to manage message templates within the Wisdom service. These permissions enable creating, updating, deleting, listing, searching, activating, deactivating, versioning, and managing attachments for message templates.
The ability to customize message templates can greatly enhance customer engagement by providing personalized and relevant communication. The versioning and attachment management features ensure flexibility and control over the content and lifecycle of message templates.
These additions empower Amazon Connect to leverage the Wisdom service effectively for managing message templates and delivering improved customer experiences.
195-207: Great addition!The introduction of the "AllowCustomerProfilesSegmentationForConnectDomain" statement significantly enhances the segmentation capabilities of Amazon Connect. The permissions to create, retrieve, and delete segment definitions, as well as create and retrieve segment snapshots, provide powerful tools for targeted customer engagement and analysis.
Segment definitions enable grouping customer profiles based on specific criteria, allowing for personalized interactions and tailored marketing strategies. Segment snapshots capture the state of a segment at a particular point in time, facilitating historical analysis and tracking of segment evolution.
The ability to manage segment definitions and snapshots gives flexibility in utilizing customer segments effectively and deriving valuable insights for business decision-making.
This addition complements the existing permissions in the "AllowCustomerProfilesForConnectDomain" statement, making Amazon Connect a more comprehensive solution for customer profile management and segmentation.
docs/source/_static/managed-policies/AWS_ConfigRole.json (15)
32-43: LGTM!The added permissions for Amazon OpenSearch Service (AOSS) enhance the AWS Config role's capabilities to manage AOSS resources. The included actions like
BatchGetCollection,ListCollections,GetAccessPolicy, etc., allow retrieving details about AOSS collections, endpoints, policies, and more. These changes align with the PR objective of updating the AWS managed policies.
89-89: LGTM!The added permission
DescribeAppBlockBuildersfor AWS AppStream service enhances the AWS Config role's capability to manage AppStream resources by allowing it to describe AppBlock builders. This change aligns with the PR objective.
136-137: LGTM!The added permissions
GetRestoreTestingPlanandGetRestoreTestingSelectionfor AWS Backup service enhance the AWS Config role's capability to manage AWS Backup resources by allowing it to retrieve details about restore testing plans and selections. These changes align with the PR objective.
144-145: LGTM!The added permissions
ListRestoreTestingPlansandListRestoreTestingSelectionsfor AWS Backup service enhance the AWS Config role's capability to manage AWS Backup resources by allowing it to list restore testing plans and selections. These changes align with the PR objective.
185-189: LGTM!The added permissions
GetChannelandListChannelsfor AWS CloudTrail service enhance the AWS Config role's capability to manage CloudTrail resources by allowing it to retrieve details and list channels. These changes align with the PR objective.
354-354: LGTM!The added permission
DescribeVpcEndpointsfor Amazon EC2 service enhances the AWS Config role's capability to manage EC2 resources by allowing it to describe VPC endpoints. This change aligns with the PR objective.
568-574: LGTM!The added permissions
GetTriggerandListTriggersfor AWS Glue service enhance the AWS Config role's capability to manage Glue resources by allowing it to retrieve details and list triggers. These changes align with the PR objective.
Line range hint
659-669: LGTM!The added permissions
GetLifecyclePolicyandListLifecyclePoliciesfor Amazon EC2 Image Builder service enhance the AWS Config role's capability to manage Image Builder resources by allowing it to retrieve details and list lifecycle policies. These changes align with the PR objective.
Line range hint
676-693: LGTM!The added permissions
DescribeBillingGroupandListBillingGroupsfor AWS IoT service enhance the AWS Config role's capability to manage IoT resources by allowing it to describe and list billing groups. These changes align with the PR objective.
769-782: LGTM!The added permissions for Amazon Interactive Video Service (IVS) enhance the AWS Config role's capabilities to manage IVS resources. The included actions like
GetEncoderConfiguration,GetPlaybackRestrictionPolicy,GetStage,GetStorageConfiguration,ListEncoderConfigurations,ListPlaybackRestrictionPolicies,ListStages,ListStorageConfigurationsallow retrieving details and listing IVS encoder configurations, playback restriction policies, stages, storage configurations, and more. These changes align with the PR objective of updating the AWS managed policies.
905-910: LGTM!The added permissions
DescribeBridge,DescribeGateway,ListBridges,ListGatewaysfor AWS Elemental MediaConnect service enhance the AWS Config role's capability to manage MediaConnect resources by allowing it to describe and list bridges and gateways. These changes align with the PR objective.
917-926: LGTM!The added permissions for AWS Elemental MediaTailor service enhance the AWS Config role's capabilities to manage MediaTailor resources. The included actions like
DescribeChannel,DescribeLiveSource,DescribeSourceLocation,DescribeVodSource,ListChannels,ListLiveSources,ListSourceLocations,ListVodSourcesallow retrieving details and listing MediaTailor channels, live sources, source locations, VOD sources, and more. These changes align with the PR objective of updating the AWS managed policies.
970-971: LGTM!The added permissions
GetWorkflowandListWorkflowsfor Amazon Omics service enhance the AWS Config role's capability to manage Omics resources by allowing it to retrieve details and list workflows. These changes align with the PR objective.
1256-1257: LGTM!The added permissions
GetScheduleandListSchedulesfor AWS Scheduler service enhance the AWS Config role's capability to manage Scheduler resources by allowing it to retrieve details and list schedules. These changes align with the PR objective.
1308-1308: LGTM!The added permission
ListTagsForResourcefor AWS Systems Manager for SAP service enhances the AWS Config role's capability to manage Systems Manager for SAP resources by allowing it to list tags. This change aligns with the PR objective.docs/source/_static/managed-policies/ReadOnlyAccess.json (11)
111-111: Looks good!The added
ListServicespermission forapplication-signalsis safe as it only allows listing services and doesn't grant access to sensitive data.
225-225: Looks good!The added
GetGuardrailandListGuardrailspermissions forbedrockare safe as they only allow read access to guardrails and don't grant permissions to modify any resources.Also applies to: 242-242
275-275: Looks good!The added
ListTagsForResourcepermission forbudgetsis safe as it only allows listing tags for budget resources and doesn't grant access to sensitive budget data.
318-328: Looks good!The added permissions for the
cleanrooms-mlservice are safe as they only allow read access to various resources like audience models, training datasets, generation jobs, etc. They don't grant permissions to modify any resources or access sensitive data.
1143-1144: Looks good!The added
GetStage,GetStageSession,ListParticipants, andListStreamspermissions for theivsservice are safe as they only allow read access to stages, stage sessions, participants, and streams. They don't grant permissions to modify any resources.Also applies to: 1150-1157
1096-1096: Looks good!The added
GetMetricspermission foriotwirelessis safe as it only allows retrieving metrics and doesn't grant access to sensitive data or the ability to modify resources.
1922-1938: Looks good!The added permissions for the
s3-outpostsservice are safe as they only allow read access to various resources like buckets, objects, endpoints, etc. They don't grant permissions to modify any resources or access sensitive data.
2072-2082: Looks good!The added permissions for the
ssm-sapservice are safe as they only allow read access to various resources like applications, components, databases, operations, etc. They don't grant permissions to modify any resources or access sensitive data.
2165-2172: Looks good!The added permissions for the
trustedadvisorservice are safe as they only allow read access to recommendations, checks, and resources. They don't grant permissions to modify any resources or access sensitive data.
2173-2175: Looks good!The added permissions for the
user-subscriptionsservice are safe as they only allow listing application claims, claims, and user subscriptions. They don't grant permissions to modify any resources or access sensitive data.
Line range hint
1-2175: Overall assessment: Changes look good!The additions made in this file are safe and do not introduce any security risks. All the added permissions are read-only and only allow listing and retrieving details of resources across various AWS services. There are no permissions that allow modifying resources or accessing sensitive data.
The changes enhance the functionality of the
ReadOnlyAccesspolicy by providing read access to additional services and resources, without granting any unintended permissions.docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (3)
Line range hint
3-55: Approve read-only access to API Gateway resources.The statement grants least privilege read-only access using
apigateway:GETactions on a comprehensive set of API Gateway resource ARNs. This is appropriate for the AWS Support service role.
87-88: Approve new read-only Account service actions.The new
account:getRegionOptStatusandaccount:listRegionsactions provide read-only access to retrieve region information. This aligns with the overall read-only access pattern granted to the AWS Support service role in this policy.
Line range hint
65-3374: Large number of read-only permissions for AWS Support.This statement grants a substantial number of read-only permissions across a wide range of AWS services. While the individual permissions have been carefully scoped, it's worth noting the broad access this policy provides.
However, this level of access is necessary and appropriate for the AWS Support service role to effectively troubleshoot and resolve issues across AWS services on behalf of customers. The read-only nature of the permissions mitigates the risk of unintended changes.
udondan
force-pushed
the
update-aws-managed-policies
branch
4 times, most recently
from
754ceb3
to
51a5d10
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1)
1-2: Consider adding a description to the policyWhile the policy name and Statement ID are clear and descriptive, it would be beneficial to add a
Descriptionfield to the policy. This can provide more context about the purpose and usage of this service role policy.Consider adding a description like this:
{ "Version": "2012-10-17", + "Description": "Allows QApps service to publish metrics to CloudWatch in the AWS/QApps namespace", "Statement": [ // ... rest of the policy ... ] }
📜 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 (52)
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/AWSBackupFullAccess.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/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json (1 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 (1 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/AWSSupportPlansFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 hunks)
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json (1 hunks)
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json (1 hunks)
- docs/source/_static/managed-policies/AmazonECS_FullAccess.json (8 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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 Files not reviewed due to 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 (45)
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json
- docs/source/_static/managed-policies/AWS_ConfigRole.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/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECS_FullAccess.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/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
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/ReadOnlyAccess.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
🔇 Additional comments (9)
docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (3)
1-18: LGTM: Policy structure follows AWS best practicesThe overall structure of the QAppsServiceRolePolicy is correct and adheres to AWS IAM policy best practices. It includes the required "Version" field and a "Statement" array.
7-10: Verify if the resource scope can be more specificThe policy allows the
cloudwatch:PutMetricDataaction on all resources ("Resource": "*"). While this might be necessary for the QApps service role, it's generally a good practice to limit the scope of permissions when possible.Could you verify if it's possible to restrict the
Resourcefield to specific CloudWatch resources or if"*"is indeed required for the QApps service to function correctly?
11-15: LGTM: Appropriate use of condition to restrict namespaceThe policy includes a condition that restricts the
cloudwatch:PutMetricDataaction to the "AWS/QApps" namespace. This is a good security practice as it limits the scope of the permission to only the relevant CloudWatch metrics for the QApps service.docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json (1)
69-78: Review the scope of the new DeleteSyncProfile permissionThe addition of the "AllowDeleteSyncProfile" statement grants permission to delete sync profiles in the AWS Identity Sync service. This aligns with the policy's existing broad permissions for SSO and identity store management. However, consider the following points:
The permission uses a wildcard resource ARN (
arn:aws:identity-sync:*:*:profile/*), allowing deletion of any sync profile in any region and account. Consider if a more restrictive ARN would be appropriate for your use case.Deleting sync profiles is a powerful action. Ensure that this permission is necessary for the role(s) to which this policy will be attached.
If possible, implement additional safeguards or conditions to restrict when this action can be performed.
To ensure this change doesn't introduce unintended consequences, please run the following command to check for any existing sync profiles that might be affected:
Review the output to confirm that granting delete permissions on all sync profiles aligns with your security requirements.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4)
80-87: LGTM: Enhanced Customer Profiles capabilities for Amazon ConnectThe new permissions added to the "AllowCustomerProfilesForConnectDomain" statement expand Amazon Connect's capabilities for customer segmentation and profile management. These additions allow for:
- Listing segment definitions and profile attribute values
- Creating and retrieving segment estimates
- Batch operations on profiles and calculated attributes
- Retrieving segment membership information
These changes are well-scoped to the Connect domain, adhering to the principle of least privilege.
96-97: LGTM: Extended read permissions for Customer Profile object typesThe additions to the "AllowReadPermissionForCustomerProfileObjects" statement enhance the ability to retrieve information about profile object types:
- "profile:GetProfileObjectType" allows fetching details of a specific object type.
- "profile:ListObjectTypeAttributes" enables listing attributes of object types.
These read-only permissions are correctly scoped and complement the existing ListProfileObjects action, providing more comprehensive access to profile object type information.
Line range hint
1-265: Summary: Comprehensive enhancement of Amazon Connect capabilitiesThis update to the AmazonConnectServiceLinkedRolePolicy significantly expands the capabilities of Amazon Connect, particularly in the areas of Customer Profiles and Wisdom services. Key improvements include:
- Advanced customer segmentation and profile management
- Enhanced access to profile object type information
- Comprehensive message template management in Wisdom
- New customer segmentation features
These changes are well-scoped and maintain proper access control, adhering to the principle of least privilege. They represent a substantial improvement in Amazon Connect's ability to manage and utilize customer data effectively.
To ensure a smooth rollout of these new features:
- Verify that corresponding code changes have been implemented to utilize these new permissions.
- Update user documentation to reflect these new capabilities.
- Consider creating or updating user guides for these new segmentation and message template features.
- Ensure that any dependent services or integrations are aware of these new capabilities.
195-208: LGTM: New permissions for Customer Profiles segmentationA new statement "AllowCustomerProfilesSegmentationForConnectDomain" has been added to the policy, granting permissions for customer segmentation operations:
- Creating, retrieving, and deleting segment definitions
- Creating and retrieving segment snapshots
These permissions are correctly scoped to the Connect domain's segment definitions, maintaining the principle of least privilege. This addition complements the earlier changes to Customer Profiles permissions, providing a comprehensive set of segmentation capabilities for Amazon Connect.
To ensure these new segmentation features are properly implemented and documented:
#!/bin/bash # Check for related changes in the codebase and documentation # Search for new segmentation-related function implementations grep -R -i "segment.*definition\|segment.*snapshot" src/ # Check if the README or documentation has been updated to reflect these new segmentation features grep -R -i "customer.*profile.*segment" README.md docs/If the script doesn't find any relevant code changes or documentation updates, consider reviewing the implementation of these new segmentation features and updating the project documentation accordingly.
docs/source/_static/managed-policies/AWSBackupFullAccess.json (1)
156-163: LGTM: New Storage Gateway permission enhances volume management capabilitiesThe addition of the "StorageGatewayGatewayStarPermissions" statement is appropriate and aligns with the policy's purpose. This new permission allows the
storagegateway:ListVolumesaction on all resources, which enhances the policy's capability to manage Storage Gateway volumes without resource-specific limitations.This change complements the existing Storage Gateway permissions in the policy, particularly:
- "StorageGatewayVolumePermissions" (which allows describing cached and stored iSCSI volumes on specific gateways)
- "StorageGatewayPermissions" (which allows listing gateways)
- "StorageGatewayGatewayPermissions" (which allows describing gateway information and listing local disks)
The use of a wildcard resource (
"*") is consistent with other list operations in this policy and is appropriate for this type of action.
| "wisdom:ListContentAssociations", | ||
| "wisdom:CreateMessageTemplate", | ||
| "wisdom:UpdateMessageTemplate", | ||
| "wisdom:UpdateMessageTemplateMetadata", | ||
| "wisdom:GetMessageTemplate", | ||
| "wisdom:DeleteMessageTemplate", | ||
| "wisdom:ListMessageTemplates", | ||
| "wisdom:SearchMessageTemplates", | ||
| "wisdom:ActivateMessageTemplate", | ||
| "wisdom:DeactivateMessageTemplate", | ||
| "wisdom:CreateMessageTemplateVersion", | ||
| "wisdom:ListMessageTemplateVersions", | ||
| "wisdom:CreateMessageTemplateAttachment", | ||
| "wisdom:DeleteMessageTemplateAttachment", | ||
| "wisdom:RenderMessageTemplate" |
There was a problem hiding this comment.
💡 Codebase verification
Action Required: Update Documentation for New Wisdom Message Template Permissions
The new permissions for managing message templates in Amazon Connect Wisdom have been added to the "AllowWisdomForConnectEnabledTaggedResources" statement. However, these changes are not reflected in the project documentation.
- Documentation Update Needed: Add details about the new Wisdom message template management capabilities, including creating, updating, deleting, and managing templates and their metadata.
Ensuring the documentation is up-to-date will help users understand and utilize the expanded functionalities effectively.
🔗 Analysis chain
LGTM: Expanded Wisdom capabilities for message template management
The "AllowWisdomForConnectEnabledTaggedResources" statement has been significantly enhanced with new permissions for managing message templates in Amazon Connect Wisdom. These additions allow for:
- Creating, updating, and deleting message templates
- Managing message template metadata and versions
- Activating and deactivating templates
- Creating and deleting template attachments
- Rendering message templates
These changes suggest a new or expanded feature for message template management in Connect Wisdom. The permissions are properly scoped to tagged resources, maintaining security best practices.
To ensure these new capabilities are properly documented:
If the script doesn't find any relevant documentation updates, consider adding information about these new Wisdom message template features to the project documentation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the README or documentation has been updated to reflect these new Wisdom capabilities
# Search for mentions of new Wisdom message template features in README and docs
grep -R -i "wisdom.*message.*template" README.md docs/
Length of output: 299
udondan
force-pushed
the
update-aws-managed-policies
branch
from
51a5d10
to
e081a0f
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
docs/source/_static/managed-policies/AWSBackupServiceRolePolicyForBackup.json (3)
59-61: LGTM. Consider updating documentation.This new permission block for deleting RDS cluster automated backups complements the previous change, providing a comprehensive approach to managing both instance and cluster automated backups.
Consider updating any relevant documentation or README files to reflect these new capabilities for managing RDS automated backups.
63-70: LGTM. Minor formatting suggestion.The retention of the RDS modify permissions is appropriate, ensuring that existing workflows requiring DB instance modifications remain functional. This reorganization of the policy effectively separates modify and delete permissions, improving clarity.
For consistency with other blocks in this policy, consider removing the square brackets around the single action and resource:
"Action": [ - "rds:ModifyDBInstance" + "rds:ModifyDBInstance" ], "Resource": [ - "arn:aws:rds:*:*:db:*" + "arn:aws:rds:*:*:db:*" ]
Line range hint
41-70: Summary: Improved RDS automated backup managementThese changes enhance the policy's granularity and specificity for RDS-related permissions:
- Introduced specific permissions for deleting RDS instance automated backups.
- Added new permissions for managing RDS cluster automated backups.
- Retained existing permissions for modifying RDS instances.
These updates align with the principle of least privilege, providing more precise control over RDS backup operations. They should improve the overall management of RDS automated backups while maintaining existing capabilities.
Consider reviewing your backup and retention strategies to ensure they align with these new, more granular permissions. This might be an opportunity to implement more sophisticated backup management workflows, leveraging the distinct permissions for instances and clusters.
📜 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 (53)
- 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/AWSCompromisedKeyQuarantineV3.json (1 hunks)
- docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (13 hunks)
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json (1 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 (1 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/AWSSupportPlansFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 hunks)
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json (1 hunks)
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json (1 hunks)
- docs/source/_static/managed-policies/AmazonECS_FullAccess.json (8 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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 Files not reviewed due to 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 (47)
- docs/source/_static/managed-policies/AWSAuditManagerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSBackupFullAccess.json
- docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.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/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWS_ConfigRole.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/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECS_FullAccess.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/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
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.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/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/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
🔇 Additional comments (9)
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4)
80-87: LGTM: Enhanced Customer Profiles capabilitiesThe new permissions added to the "AllowCustomerProfilesForConnectDomain" statement expand the capabilities for managing customer profiles and segments. These additions include:
- Listing integrations and segment definitions
- Managing profile attribute values and segment estimates
- Batch operations for profiles and calculated attributes
- Retrieving segment membership
These changes align with the expanded profile management capabilities mentioned in the AI summary.
96-97: LGTM: Additional read permission for Customer ProfilesThe addition of the "profile:ListObjectTypeAttributes" permission enhances the read capabilities for Customer Profile objects. This allows listing attributes of object types, which complements the existing permissions to list profile objects and get profile object types.
149-163: LGTM: Expanded Wisdom capabilities for message template managementThe "AllowWisdomForConnectEnabledTaggedResources" statement has been significantly enhanced with new permissions for managing message templates in Amazon Connect Wisdom. These additions allow for:
- Creating, updating, and deleting message templates
- Managing message template metadata and versions
- Activating and deactivating templates
- Creating and deleting template attachments
- Rendering message templates
These changes align with the expanded message template handling capabilities mentioned in the AI summary. The permissions are properly scoped to tagged resources, maintaining security best practices.
As mentioned in a previous review, please ensure that the project documentation is updated to reflect these new Wisdom message template features.
195-208: LGTM: New segmentation capabilities for Customer ProfilesA new statement "AllowCustomerProfilesSegmentationForConnectDomain" has been added to introduce segmentation capabilities for Customer Profiles. This statement includes permissions for:
- Creating, retrieving, and deleting segment definitions
- Creating and retrieving segment snapshots
These additions enhance the ability to manage customer segments within the Amazon Connect domain, aligning with the expanded segmentation capabilities mentioned in the AI summary. The permissions are properly scoped to the Connect domain resources.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (5)
87-88: New account permissions enhance multi-region support capabilities.The addition of
account:getRegionOptStatusandaccount:listRegionspermissions allows the AWS Support Service Role to retrieve information about region opt-in status and list available regions. This enhancement will likely improve troubleshooting and support capabilities for multi-region deployments.
264-264: New Auto Scaling permission improves traffic analysis capabilities.The addition of
autoscaling:describeTrafficSourcespermission enables the AWS Support Service Role to retrieve information about traffic sources for Auto Scaling groups. This will enhance the ability to diagnose issues related to load balancing and traffic distribution in Auto Scaling setups.
324-345: Extensive new Bedrock permissions expand AI support capabilities.A significant set of new permissions related to Amazon Bedrock has been added to the policy. These permissions cover various aspects of the Bedrock service, including:
- Managing agents and agent versions
- Handling custom models and model customization jobs
- Working with data sources and ingestion jobs
- Accessing knowledge bases and feature groups
This expansion of permissions will enable AWS Support to provide comprehensive assistance for customers using Amazon Bedrock for generative AI applications. It demonstrates AWS's commitment to supporting advanced AI services.
547-558: Broad expansion of permissions across multiple AWS services.This update includes new permissions for several AWS services, significantly expanding the AWS Support Service Role's capabilities:
- CodeConnections: New permissions for managing connections, hosts, and repository links.
- Deadline: Added permissions for listing various Deadline resources and jobs.
- EC2: New permissions for describing snapshot tier status and getting subnet CIDR reservations.
- EKS: Added permissions for working with pod identity associations.
- Elastic Load Balancing: New permissions for describing trust stores and associations.
- OSIS: Added permissions for managing pipelines and blueprints.
- WorkSpaces: New permissions for describing application and workspace associations.
- X-Ray: Expanded permissions for advanced tracing and analysis capabilities.
These additions will enable AWS Support to provide more comprehensive assistance across a wider range of AWS services, improving their ability to troubleshoot and resolve customer issues in these areas.
Also applies to: 786-802, 1018-1018, 1064-1064, 1143-1144, 1210-1212, 2295-2300, 3355-3356, 3368-3374
Line range hint
1-3374: Comprehensive policy update significantly enhances AWS Support capabilities.This update to the AWSSupportServiceRolePolicy represents a substantial expansion of AWS Support's capabilities across multiple services. The new permissions enable support for:
- Advanced multi-region deployments
- Enhanced Auto Scaling and traffic analysis
- Comprehensive support for Amazon Bedrock and AI services
- Improved capabilities across various services including CodeConnections, Deadline, EC2, EKS, Elastic Load Balancing, OSIS, WorkSpaces, and X-Ray
These changes will allow AWS Support to provide more effective and comprehensive assistance to customers, particularly in areas of emerging technologies and complex multi-service deployments. The policy update aligns well with AWS's commitment to continually improving its support offerings and adapting to new service introductions and enhancements.
| "Sid": "RDSInstanceAutomatedBackupPermissions", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "rds:ModifyDBInstance" | ||
| ], | ||
| "Resource": [ | ||
| "arn:aws:rds:*:*:db:*" | ||
| ] | ||
| "Action": "rds:DeleteDBInstanceAutomatedBackup", | ||
| "Resource": "arn:aws:rds:*:*:auto-backup:*" |
There was a problem hiding this comment.
💡 Codebase verification
Action Required: Update or Remove Deprecated RDS Permissions
The old permission rds:ModifyDBInstance is still present in multiple policy files. Please review and update or remove this permission as necessary to ensure consistency and security across all policies.
AWSElasticBeanstalkRoleRDS.jsonAWSBackupServiceRolePolicyForBackup.jsonNeptuneConsoleFullAccess.jsonNeptuneFullAccess.jsonAmazonDocDBFullAccess.jsonAmazonDocDBConsoleFullAccess.jsonAdministratorAccess-AWSElasticBeanstalk.json
🔗 Analysis chain
LGTM. Verify the impact of this permission change.
The change from modifying DB instances to deleting automated backups is appropriate and aligns well with the new Sid name. This update provides more specific and targeted permissions for managing RDS automated backups.
To ensure this change doesn't negatively impact existing workflows, please run the following verification:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any existing scripts or CloudFormation templates that might be using the old permission
rg "rds:ModifyDBInstance" --type yaml --type json
Length of output: 763
udondan
force-pushed
the
update-aws-managed-policies
branch
from
e081a0f
to
f319f71
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
📜 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 (53)
- 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/AWSCompromisedKeyQuarantineV3.json (1 hunks)
- docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (13 hunks)
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json (1 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 (1 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/AWSSupportPlansFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 hunks)
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json (1 hunks)
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json (1 hunks)
- docs/source/_static/managed-policies/AmazonECS_FullAccess.json (8 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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 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 (47)
- 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/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.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/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AWS_ConfigRole.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/AmazonEC2RolePolicyForLaunchWizard.json
- docs/source/_static/managed-policies/AmazonECS_FullAccess.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/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/AmazonSageMakerCanvasDataPrepFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerCanvasFullAccess.json
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.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/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/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
🔇 Additional comments (10)
docs/source/_static/managed-policies/AmazonSNSReadOnlyAccess.json (2)
5-16: LGTM: Enhanced SNS read-only permissionsThe modifications to the SNSReadOnlyAccess statement are appropriate and align with the policy's purpose. The new permissions added (lines 10-16) provide more comprehensive read-only access to various SNS features and attributes, including:
- Phone number opt-out status
- Endpoint attributes
- Data protection policy
- Platform application attributes
- SMS attributes
- SMS sandbox account status
- Subscription attributes
These additions enhance the policy's functionality without compromising its read-only nature.
20-35: LGTM: Added SMS and voice read-only access via SNSThe new SMSAccessViaSNS statement (lines 20-35) is a valuable addition to the AmazonSNSReadOnlyAccess policy. It extends the policy's scope to include read-only actions for SMS and voice services, which are often used in conjunction with SNS. The permitted actions allow users to:
- Describe verified destination numbers
- View account attributes
- Check spend limits
- List phone numbers
- See opted-out numbers
A crucial security measure is implemented through the Condition block (lines 31-35), which ensures these actions can only be invoked via sns.amazonaws.com. This restriction aligns with the principle of least privilege and helps maintain the integrity of the read-only access.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4)
80-87: LGTM: Enhanced Customer Profiles capabilitiesThe new permissions added to the "AllowCustomerProfilesForConnectDomain" section expand the capabilities for managing customer profiles and segments. These additions include:
- Listing integrations and segment definitions
- Managing profile attribute values
- Creating and retrieving segment estimates
- Batch operations on profiles and calculated attributes
- Retrieving segment membership
These changes align with the expanded profile management capabilities mentioned in the AI summary and should provide more comprehensive interaction with profile data.
96-97: LGTM: Added permission to list object type attributesThe addition of the "profile:ListObjectTypeAttributes" permission enhances the read capabilities for Customer Profile objects. This new permission allows listing attributes of object types, which complements the existing read permissions in this section. This change provides more granular access to profile object type information.
149-163: LGTM: Expanded Wisdom message template managementThe "AllowWisdomForConnectEnabledTaggedResources" section has been significantly enhanced with new permissions for managing message templates in Amazon Connect Wisdom. These additions allow for:
- Creating, updating, and deleting message templates
- Managing message template metadata and versions
- Activating and deactivating templates
- Creating and deleting template attachments
- Rendering message templates
These changes align with the AI summary and provide comprehensive capabilities for message template management in Connect Wisdom.
195-208: LGTM: New Customer Profiles segmentation capabilitiesA new section "AllowCustomerProfilesSegmentationForConnectDomain" has been added to the policy. This section introduces permissions for managing customer profile segmentation, including:
- Creating, retrieving, and deleting segment definitions
- Creating and retrieving segment snapshots
These new permissions enhance the Amazon Connect service-linked role's capabilities for customer segmentation, allowing for more targeted and effective customer interactions.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (4)
786-802: New permissions added for deadline serviceThe policy has been expanded to include several new permissions for the deadline service, which is part of the AWS Thinkbox Deadline render management system:
- listAvailableMeteredProducts
- listBudgets
- listFarmMembers, listFarms
- listFleetMembers, listFleets
- listJobMembers, listJobs
- listLicenseEndpoints
- listMeteredProducts
- listMonitors
- listQueueEnvironments
- listQueueFleetAssociations
- listQueueMembers, listQueues
- listStorageProfiles
- listWorkers
These additions significantly enhance the support role's ability to query and inspect various aspects of render farm management, including budgets, farms, fleets, jobs, queues, and workers. This expansion indicates improved support capabilities for media and entertainment workloads using AWS Thinkbox Deadline.
While these permissions can be valuable for troubleshooting and support scenarios in render farm environments, it's important to ensure they align with the intended scope of the support role and the principle of least privilege.
To confirm the necessity and usage of these new deadline permissions, please run the following script:
#!/bin/bash # Description: Check for any existing uses of the new deadline permissions in AWS documentation or knowledge base echo "Checking for deadline permissions usage:" rg -i "deadline:list" --type md echo "If any results are found, they may indicate existing use cases for these permissions in support scenarios for render farm management."
547-558: New permissions added for codeconnections serviceThe policy has been expanded to include several new permissions for the codeconnections service:
- get operations: Connection, Host, RepositoryLink, RepositorySyncStatus, ResourceSyncStatus, SyncBlockerSummary, SyncConfiguration
- list operations: Connections, Hosts, RepositoryLinks, RepositorySyncDefinitions, SyncConfigurations
These additions significantly enhance the support role's ability to manage and query various aspects of code connections, including repositories, hosts, and sync configurations. This expansion suggests improved support capabilities for services like CodeCommit or similar version control and CI/CD related services.
While these permissions can be valuable for troubleshooting and support scenarios, it's important to ensure they align with the intended scope of the support role.
To confirm the necessity and usage of these new codeconnections permissions, please run the following script:
#!/bin/bash # Description: Check for any existing uses of the new codeconnections permissions in AWS documentation or knowledge base echo "Checking for codeconnections permissions usage:" rg -i "codeconnections.*get|codeconnections.*list" --type md echo "If any results are found, they may indicate existing use cases for these permissions in support scenarios."
1018-1018: New permissions added for various AWS servicesThe policy has been expanded to include new permissions across several AWS services:
- EC2: Added
describeSnapshotTierStatusandgetSubnetCidrReservationsfor more detailed EC2 resource information.- EKS: Added permissions related to Pod Identity Associations.
- Elastic Load Balancing: Added describe operations for TrustStores.
- Free Tier: Added
getFreeTierUsagefor accessing free tier usage information.- Inspector2: Added
getConfigurationandgetEc2DeepInspectionConfigurationfor enhanced security inspection capabilities.- OSIS (Open Search Ingestion Service): Added various get and list operations.
- WorkSpaces: Added describe operations for application and workspace associations.
- X-Ray: Added multiple get operations for enhanced tracing and debugging capabilities.
These additions significantly expand the support role's ability to gather detailed information and configurations across a wide range of AWS services. This enhanced access can be beneficial for troubleshooting and support scenarios. However, some of these permissions, particularly those related to Inspector2 and X-Ray, may have security implications and should be carefully considered in the context of the principle of least privilege.
To confirm the necessity and usage of these new permissions across various services, please run the following script:
#!/bin/bash # Description: Check for any existing uses of the new permissions in AWS documentation or knowledge base services=("ec2" "eks" "elasticloadbalancing" "freetier" "inspector2" "osis" "workspaces" "xray") for service in "${services[@]}"; do echo "Checking for new $service permissions usage:" rg -i "$service.*:(describe|get|list)" --type md echo "---" done echo "If any results are found, they may indicate existing use cases for these permissions in support scenarios."Also applies to: 1064-1064, 1143-1144, 1210-1212, 1343-1343, 1637-1638, 2295-2300, 3355-3356, 3368-3374
Line range hint
1-3374: Summary of policy changes and their impactThis update to the AWSSupportServiceRolePolicy significantly expands the permissions granted to the AWS Support service role across multiple AWS services. Key changes include:
- Enhanced regional and account-level access
- Expanded capabilities for autoscaling diagnostics
- Comprehensive permissions for AI/ML services (Bedrock)
- Improved access to code connection and repository management
- New permissions for render farm management (Deadline service)
- Additional permissions for various services including EC2, EKS, ELB, Inspector2, OSIS, WorkSpaces, and X-Ray
While these additions enhance the support role's ability to troubleshoot and assist with a wider range of AWS services, they also considerably increase the scope of access for this role. It's crucial to ensure that these expanded permissions align with the principle of least privilege and are necessary for the support role's functions.
Recommendations:
- Review each new permission to confirm its necessity for support operations.
- Consider implementing more granular policies or condition statements where possible to limit the scope of these permissions.
- Regularly audit the usage of these permissions to ensure they are being utilized as intended.
- Keep documentation updated to reflect the expanded capabilities of the support role.
To get an overview of the policy changes and their potential impact, run the following script:
#!/bin/bash # Description: Summarize the changes in the AWSSupportServiceRolePolicy echo "Summary of changes in AWSSupportServiceRolePolicy:" echo "1. Total number of permissions:" jq '.Statement[0].Action | length' AWSSupportServiceRolePolicy.json echo "2. New services added (sample of services not typically in support policies):" jq -r '.Statement[0].Action[]' AWSSupportServiceRolePolicy.json | cut -d: -f1 | sort | uniq | grep -E 'bedrock|codeconnections|deadline|osis' echo "3. Permissions with potential security implications:" jq -r '.Statement[0].Action[]' AWSSupportServiceRolePolicy.json | grep -E 'config|inspector|iam' echo "This summary provides an overview of the policy's scope and highlights areas that may require additional scrutiny."
| "account:getRegionOptStatus", | ||
| "account:listRegions", |
There was a problem hiding this comment.
💡 Codebase verification
Excessive Permissions Detected in AWSSupportServiceRolePolicy.json
The AWSSupportServiceRolePolicy.json currently includes a total of 3,303 permissions, which is significantly higher than typical support role policies. Notably, the policy introduces new services such as:
bedrockcodeconnectionsdeadlineosis
Additionally, it grants numerous permissions with potential security implications, including extensive access to config, iam, and inspector services. These permissions may exceed the necessary scope for a support role and could pose security risks.
Recommended Actions:
- Review and Restrict Permissions: Evaluate each permission to ensure it aligns with the principle of least privilege. Remove any unnecessary or overly broad permissions.
- Assess New Services: Confirm that the addition of
bedrock,codeconnections,deadline, andosisservices is essential for the support role's functionality. - Conduct Security Audit: Perform a thorough security assessment to identify and mitigate potential risks associated with the granted permissions.
🔗 Analysis chain
New permissions added for account, autoscaling, and bedrock services
The policy has been expanded to include new permissions for several services:
- Account service:
getRegionOptStatusandlistRegionshave been added, allowing the support role to query region-specific information. - Autoscaling service:
describeTrafficSourceshas been added, providing more detailed information about traffic sources for autoscaling groups. - Bedrock service: A comprehensive set of permissions has been added, covering various aspects of machine learning operations, including agent management, model customization, and job handling.
These additions enhance the support role's capabilities, particularly in regional operations, autoscaling diagnostics, and AI/ML services support. However, it's important to ensure that these expanded permissions align with the principle of least privilege and are necessary for the support role's functions.
To confirm the necessity of these new permissions, especially the extensive bedrock permissions, please run the following script:
Also applies to: 264-264, 324-345
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any existing uses of the new permissions in AWS Support documentation or knowledge base
# Check for account and autoscaling permissions
echo "Checking for account and autoscaling permissions usage:"
rg -i "getRegionOptStatus|listRegions|describeTrafficSources" --type md
# Check for bedrock permissions
echo "Checking for bedrock permissions usage:"
rg -i "bedrock.*get|bedrock.*list" --type md
echo "If any results are found, they may indicate existing use cases for these permissions in support scenarios."
Length of output: 1291
Script:
#!/bin/bash
# Description: Locate the AWSSupportServiceRolePolicy.json file within the repository
echo "Searching for AWSSupportServiceRolePolicy.json in the repository:"
fd 'AWSSupportServiceRolePolicy\.json$' .
Length of output: 256
Script:
#!/bin/bash
# Description: Analyze the AWSSupportServiceRolePolicy.json for permission usage and potential security implications
POLICY_FILE="./docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json"
if [ ! -f "$POLICY_FILE" ]; then
echo "Error: $POLICY_FILE does not exist."
exit 1
fi
echo "Analyzing permissions in $POLICY_FILE:"
# Total number of permissions
TOTAL_PERMISSIONS=$(jq '.Statement[0].Action | length' "$POLICY_FILE" 2>/dev/null)
if [ $? -ne 0 ]; then
echo "Failed to parse $POLICY_FILE with jq."
else
echo "1. Total number of permissions: $TOTAL_PERMISSIONS"
fi
# New services added (sample of services not typically in support policies)
NEW_SERVICES=$(jq -r '.Statement[0].Action[]' "$POLICY_FILE" | cut -d: -f1 | sort | uniq | grep -E 'bedrock|codeconnections|deadline|osis' 2>/dev/null)
if [ $? -ne 0 ]; then
echo "Failed to extract new services from $POLICY_FILE."
else
echo "2. New services added (sample of services not typically in support policies):"
echo "$NEW_SERVICES"
fi
# Permissions with potential security implications
SECURITY_PERMISSIONS=$(jq -r '.Statement[0].Action[]' "$POLICY_FILE" | grep -E 'config|inspector|iam' 2>/dev/null)
if [ $? -ne 0 ]; then
echo "Failed to extract security-related permissions from $POLICY_FILE."
else
echo "3. Permissions with potential security implications:"
echo "$SECURITY_PERMISSIONS"
fi
echo "This summary provides an overview of the policy's scope and highlights areas that may require additional scrutiny."
Length of output: 1738
Script:
#!/bin/bash
# Description: Comprehensive analysis of AWSSupportServiceRolePolicy.json for permission usage and potential security implications
POLICY_FILE="./docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json"
if [ ! -f "$POLICY_FILE" ]; then
echo "Error: $POLICY_FILE does not exist."
exit 1
fi
echo "Analyzing permissions in $POLICY_FILE:"
# Total number of permissions across all statements
TOTAL_PERMISSIONS=$(jq '[.Statement[].Action[]] | length' "$POLICY_FILE" 2>/dev/null)
if [ $? -ne 0 ]; then
echo "Failed to parse $POLICY_FILE with jq."
else
echo "1. Total number of permissions: $TOTAL_PERMISSIONS"
fi
# New services added (sample of services not typically in support policies)
NEW_SERVICES=$(jq -r '[.Statement[].Action[] | split(":")[0]] | unique | .[]' "$POLICY_FILE" | grep -E 'bedrock|codeconnections|deadline|osis' 2>/dev/null)
if [ -z "$NEW_SERVICES" ]; then
echo "2. No new services added that are atypical for support policies."
else
echo "2. New services added (sample of services not typically in support policies):"
echo "$NEW_SERVICES"
fi
# Permissions with potential security implications
SECURITY_PERMISSIONS=$(jq -r '[.Statement[].Action[]] | unique | .[]' "$POLICY_FILE" | grep -E 'config|inspector|iam' 2>/dev/null)
if [ -z "$SECURITY_PERMISSIONS" ]; then
echo "3. No permissions with potential security implications found."
else
echo "3. Permissions with potential security implications:"
echo "$SECURITY_PERMISSIONS"
fi
echo "This summary provides an overview of the policy's scope and highlights areas that may require additional scrutiny."
Length of output: 18683
udondan
force-pushed
the
update-aws-managed-policies
branch
from
f319f71
to
228a077
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (6)
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json (2)
43-62: LGTM with suggestion: Comprehensive denial of Lightsail, Organizations, and S3 actionsThe policy effectively denies critical actions for Lightsail, Organizations, and S3 services, which is crucial for quarantining compromised keys. This includes:
- Lightsail: Blocking resource creation, deletion, and management
- Organizations: Preventing new account creation and organization management
- S3: Restricting bucket and object operations, including policy modifications
These denials significantly limit the potential damage from a compromised key.
However, consider reviewing the use of wildcards for Lightsail actions (e.g.,
Create*,Delete*,Start*,Update*). While comprehensive, this approach might inadvertently block future, less critical Lightsail actions. Consider explicitly listing the specific Lightsail actions to be denied for more precise control.
66-66: Consider expanding Savings Plans restrictionsDenying
savingsplans:CreateSavingsPlanis a good practice to prevent unauthorized financial commitments. However, consider expanding the list of denied Savings Plans actions to include:
savingsplans:DeleteSavingsPlansavingsplans:ModifySavingsPlanThis would provide more comprehensive protection against potential misuse of Savings Plans through a compromised key.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (4)
Line range hint
5-25: LGTM with a suggestion for tighter security.The new "DataExchangeActions" statement provides comprehensive permissions for managing AWS Data Exchange resources, which aligns well with the policy's purpose. However, consider refining the wildcard permissions (Get*, Update*, List*, Delete*) to only the specific actions required, adhering to the principle of least privilege.
Consider replacing wildcards with specific actions to tighten security. For example:
"Action": [ "dataexchange:CreateDataSet", "dataexchange:CreateRevision", "dataexchange:CreateAsset", "dataexchange:GetDataSet", "dataexchange:GetRevision", "dataexchange:GetAsset", "dataexchange:UpdateDataSet", "dataexchange:UpdateRevision", "dataexchange:ListDataSets", "dataexchange:ListRevisions", "dataexchange:ListAssets", "dataexchange:DeleteDataSet", "dataexchange:DeleteRevision", "dataexchange:DeleteAsset", ... ]
Line range hint
62-77: Flexible and secure S3 access, with a suggestion.The "S3GetActionConditionalTagAndADX" statement provides flexible access to S3 objects based on tagging, with good security controls through dual conditions. However, the use of "*" for the Resource might be overly permissive.
Consider restricting the Resource to specific S3 buckets or a more specific ARN pattern if possible:
"Resource": "arn:aws:s3:::your-bucket-prefix*/*"This would further enhance security by limiting the scope of accessible S3 resources.
Line range hint
94-103: Broad S3 read permissions granted.The "S3ReadActions" statement provides necessary permissions for S3 operations. However, granting these permissions on all S3 resources ("*") might be overly permissive.
Consider restricting these permissions to specific S3 buckets related to Data Exchange operations if possible. This would align better with the principle of least privilege.
Line range hint
156-162: API Gateway read permission granted, with a suggestion.The "APIGatewayActions" statement provides read-only permission for API Gateway, which is good for security. However, granting this permission on all API Gateway resources ("*") might be more permissive than necessary.
Consider restricting this permission to specific API Gateway resources related to Data Exchange operations if possible. This would align better with the principle of least privilege.
📜 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 (53)
- 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/AWSCompromisedKeyQuarantineV3.json (1 hunks)
- docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (13 hunks)
- docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.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 (1 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/AWSSupportPlansFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 hunks)
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json (1 hunks)
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json (1 hunks)
- docs/source/_static/managed-policies/AmazonECS_FullAccess.json (8 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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 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 due to trivial changes (1)
- docs/source/_static/managed-policies/index.json
🚧 Files skipped from review as they are similar to previous changes (38)
- 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/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSSSOMasterAccountAdministrator.json
- docs/source/_static/managed-policies/AWSServiceRoleForAmazonEKSNodegroup.json
- docs/source/_static/managed-policies/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.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/AmazonEC2RolePolicyForLaunchWizard.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/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
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
🔇 Additional comments (64)
docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (4)
27-36: Approve addition of WorkSpaces Web permissions with resource scope consideration.The new statement granting read-only access to WorkSpaces Web portals and user settings is consistent with the policy's purpose.
Consider reviewing the resource scope. While "*" is often used for list and describe actions, more specific resource ARNs might be possible for
GetPortalandGetUserSettings. Please verify if a more granular resource definition is feasible:#!/bin/bash # Description: Check for WorkSpaces Web resource specifications in other policies # Test: Search for WorkSpaces Web resource specifications rg --type json 'Resource.*arn:aws:workspaces-web' docs/source/_static/managed-policies/This will help identify if more specific resource ARNs are used in other policies for similar actions.
37-43: Approve addition of AppStream stack description permission with verification.The new statement granting permission to
appstream:DescribeStacksis consistent with the policy's read-only access nature.Please verify if this AppStream access is necessary for the AmazonWorkSpacesThinClientReadOnlyAccess policy. If it's required, consider documenting the reason for its inclusion. Run the following script to check for similar permissions in related policies:
#!/bin/bash # Description: Check for AppStream permissions in WorkSpaces related policies # Test: Search for AppStream permissions in WorkSpaces policies rg --type json 'appstream:' docs/source/_static/managed-policies/*WorkSpaces*.jsonThis will help determine if the inclusion of AppStream permissions is consistent across WorkSpaces related policies.
19-26: Approve addition of WorkSpaces directory description permission.The new statement granting permission to
workspaces:DescribeWorkspaceDirectoriesaligns with the policy's read-only access nature.To ensure this addition is consistent with other policies, please run the following script:
This will help verify if the permission and resource scope are consistent across policies.
9-10: Verify the intention behind broadening resource access for ThinClient actions.The resource specification for ThinClient actions has been changed from a specific ARN format to a wildcard "*". This modification broadens the scope of accessible resources under this policy.
Please confirm if this change is intentional and aligns with the principle of least privilege. If a more restrictive resource definition is possible, consider using it to enhance security.
To verify the impact, you can run the following script:
This will help identify if this change is consistent with other policies or if it's an outlier that needs further review.
Also applies to: 13-13, 17-17
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json (3)
1-5: LGTM: Policy structure is correctThe policy structure follows AWS best practices:
- Uses the latest policy version "2012-10-17"
- Contains a single statement with "Effect": "Deny"
- Applies to all resources with "Resource": ["*"]
Also applies to: 68-73
7-42: LGTM: Comprehensive denial of critical EC2, IAM, and Lambda actionsThe policy effectively denies a wide range of critical actions for EC2, IAM, and Lambda services, which is crucial for quarantining compromised keys. This includes:
- EC2: Preventing instance creation, spot requests, and reserved instance operations
- IAM: Blocking user, group, role, and policy management actions
- Lambda: Restricting function creation, permissions, and code updates
These denials significantly limit the potential damage from a compromised key.
Also applies to: 63-66
1-73: Overall assessment: Effective quarantine policy with minor improvement opportunitiesThe
AWSCompromisedKeyQuarantineV3policy effectively serves its purpose of quarantining compromised keys by denying access to a comprehensive list of critical AWS operations across multiple services. The policy structure is correct, and the denied actions cover the most significant potential threats.Minor improvements could enhance the policy's precision and coverage:
- Review the use of wildcards for Lightsail actions to ensure only necessary actions are blocked.
- Consider expanding the list of denied Savings Plans actions for more comprehensive protection.
These suggestions aside, the policy provides a strong security measure against potential misuse of compromised access keys.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (8)
Line range hint
27-47: Well-structured and secure job management permissions.The "DataExchangeJobsActions" statement provides appropriate permissions for managing Data Exchange jobs. The use of conditions to restrict job types is an excellent security practice, ensuring that only specific job types can be created, started, or canceled.
Line range hint
49-60: Secure S3 access for Data Exchange operations.The "S3GetActionConditionalResourceAndADX" statement provides well-scoped S3 access. The combination of resource-based restriction and the condition ensuring the action is called via Data Exchange service adds robust security controls.
Line range hint
78-93: Secure S3 write permissions for Data Exchange.The "S3WriteActions" statement provides appropriate permissions for writing objects to S3 buckets related to Data Exchange. The condition ensuring the actions are called via the Data Exchange service adds a good security measure.
Line range hint
104-123: Well-scoped AWS Marketplace permissions.The "AWSMarketplaceActions" statement provides appropriate and specific permissions for managing Data Exchange products in AWS Marketplace. The actions are well-defined and necessary for the intended operations.
Line range hint
124-133: Appropriate KMS read permissions.The "KMSActions" statement provides necessary read-only permissions for KMS operations. These are typically required for working with encrypted resources and are appropriately scoped.
Line range hint
134-146: Secure Redshift data share authorization.The "RedshiftConditionalActions" statement provides a well-controlled permission for authorizing Redshift data shares. The condition ensuring it's only for Data Exchange (ADX) consumer is an excellent security measure.
Line range hint
147-155: Appropriate Redshift data share read permissions.The "RedshiftActions" statement provides necessary read-only permissions for working with Redshift data shares. These permissions are well-scoped to the required actions.
Line range hint
1-164: Overall, well-structured and secure policy updates with minor improvement opportunities.This update to the AWSDataExchangeProviderFullAccess policy significantly enhances its functionality by adding detailed, service-specific permissions. The majority of the new statements are well-scoped and include appropriate conditions, demonstrating good security practices.
Key strengths:
- Use of conditions to restrict actions to specific services or contexts.
- Detailed, action-specific permissions for Data Exchange operations.
- Inclusion of necessary permissions for related services (S3, KMS, Redshift, API Gateway).
Areas for potential improvement:
- Consider replacing wildcards with specific actions where possible.
- Evaluate opportunities to narrow the scope of resources, particularly for S3 and API Gateway permissions.
These changes align well with the policy's purpose while maintaining a good security posture. The suggested improvements, if implemented, would further enhance the policy's adherence to the principle of least privilege.
docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json (4)
80-80: LGTM: Addition of S3 ListCallerAccessGrants permissionThe addition of
"s3:ListCallerAccessGrants"to the NotAction list is appropriate. This permission allows the listing of caller access grants for S3, which is part of the S3 Access Grants feature. It enhances the policy's capability to manage fine-grained access control for S3 objects.
118-118: LGTM: Addition of QApps ListQAppSessionData permissionThe addition of
"qapps:ListQAppSessionData"to the NotAction list is appropriate. This permission allows listing session data for Amazon Q Apps, which appears to be related to Amazon's generative AI-powered application. This addition enhances the policy's capabilities to work with newer AWS services.
119-119: LGTM: Addition of QApps ExportQAppSessionData permissionThe addition of
"qapps:ExportQAppSessionData"to the NotAction list is appropriate. This permission complements the previously added ListQAppSessionData permission by allowing the export of session data from Amazon Q Apps. This addition enhances the policy's capabilities for data management and analysis related to this AWS service.
Line range hint
80-119: Summary: Appropriate updates to support newer AWS featuresThe changes to this policy document are well-aligned with the PR objective of updating AWS managed policies. The additions of
"s3:ListCallerAccessGrants","qapps:ListQAppSessionData", and"qapps:ExportQAppSessionData"to the NotAction list enhance the policy's capabilities to work with newer AWS features, specifically S3 Access Grants and Amazon Q Apps.These updates allow for better management of S3 object access and interaction with Amazon's generative AI-powered application data. The changes are additive and do not modify existing permissions, which minimizes the risk of breaking current functionality.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4)
80-87: LGTM: Enhanced Customer Profiles capabilitiesThe new permissions added to the "AllowCustomerProfilesForConnectDomain" section expand the capabilities for managing customer profiles and segments. These additions align with the PR objective of updating AWS managed policies and provide more granular control over customer data management.
96-97: LGTM: Additional read permission for Customer Profile ObjectsThe addition of "profile:ListObjectTypeAttributes" permission enhances the read capabilities for customer profile objects. This change is consistent with the section's purpose and complements the existing permissions.
149-163: LGTM: Expanded Wisdom capabilities for message template managementThe new permissions added to the "AllowWisdomForConnectEnabledTaggedResources" section significantly enhance the capabilities for managing message templates in Amazon Connect Wisdom. These additions align with the PR objective and provide comprehensive control over message template lifecycle.
Reminder: As noted in a previous review comment, please ensure that the project documentation is updated to reflect these new Wisdom message template features. This will help users understand and utilize the expanded functionalities effectively.
195-208: LGTM: New section for Customer Profiles SegmentationA new section "AllowCustomerProfilesSegmentationForConnectDomain" has been added to the policy. This section introduces permissions for managing segment definitions and snapshots, enhancing the capabilities for customer segmentation within Amazon Connect. The permissions are properly scoped to the Connect domain, ensuring appropriate access control.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (10)
Line range hint
5-127: Comprehensive ECS integration permissions addedThis new statement, "ECSIntegrationsManagementPolicy", provides a wide range of permissions necessary for full ECS access and integration with related AWS services. It covers crucial actions for managing ECS tasks, auto-scaling, load balancing, networking, and more. The broad scope of permissions is appropriate for a FullAccess policy.
Line range hint
128-137: Well-scoped SSM parameter access for ECSThe "SSMPolicy" statement appropriately allows access to ECS-related parameters in the AWS Systems Manager Parameter Store. This permission is crucial for retrieving sensitive information needed for ECS operations while maintaining proper access control by limiting the scope to ECS-specific parameters.
Line range hint
138-155: Properly constrained cleanup permissions for ECS CloudFormation resourcesThe "ManagedCloudformationResourcesCleanupPolicy" statement grants necessary permissions for cleaning up EC2 resources created by CloudFormation for ECS. The use of a condition to limit these permissions to resources tagged with ECS-specific CloudFormation stack names ensures that only relevant resources can be affected, maintaining proper access control.
Line range hint
156-168: Properly scoped IAM role passing for ECS tasksThe "TasksPassRolePolicy" statement allows passing IAM roles to ECS tasks, which is essential for task execution. The condition effectively limits this permission to the ECS tasks service, ensuring that roles can only be passed to the intended service. This maintains proper access control while providing the necessary functionality for ECS operations.
169-180: Well-defined IAM role passing for ECS infrastructureThe "InfrastructurePassRolePolicy" statement allows passing the ecsInfrastructureRole to the ECS service. This permission is crucial for ECS to assume the necessary infrastructure role. The policy is well-scoped, specifying the exact role ARN and using a condition to ensure the role can only be passed to the ECS service, maintaining tight access control.
Line range hint
181-197: Properly scoped IAM role passing for ECS EC2 instancesThe "InstancePassRolePolicy" statement allows passing the ecsInstanceRole to EC2 instances, which is essential for ECS operations on EC2. The policy is well-defined, using a resource pattern to match ecsInstanceRole ARNs and a condition to ensure the role can only be passed to EC2 services. This maintains proper access control while accommodating different AWS regions.
Line range hint
198-213: Well-defined IAM role passing for ECS auto-scalingThe "AutoScalingPassRolePolicy" statement allows passing the ecsAutoscaleRole to application auto-scaling services. This permission is crucial for enabling auto-scaling functionality in ECS. The policy is properly scoped, using a resource pattern to match ecsAutoscaleRole ARNs and a condition to ensure the role can only be passed to application auto-scaling services, accommodating different AWS regions while maintaining tight access control.
Line range hint
214-230: Properly constrained service-linked role creation for ECS and related servicesThe "ServiceLinkedRoleCreationPolicy" statement allows the creation of service-linked roles, which is essential for ECS and its associated services to function properly. The policy uses a condition to limit this permission to specific services (ECS, Auto Scaling, Spot Fleet) directly related to ECS operations. This ensures that only necessary service-linked roles can be created, maintaining proper access control.
Line range hint
231-248: Well-scoped tagging permissions for ELB resourcesThe "ELBTaggingPolicy" statement allows adding tags to Elastic Load Balancing resources, which is important for resource management in ECS deployments. The policy is well-constrained, using a condition to limit this permission to specific ELB creation actions (CreateTargetGroup, CreateRule, CreateListener, CreateLoadBalancer). This ensures that tagging can only occur during resource creation, maintaining proper access control while enabling necessary functionality.
Line range hint
1-249: Comprehensive update to AmazonECS_FullAccess policyThis update significantly enhances the AmazonECS_FullAccess policy, providing a more comprehensive and well-structured set of permissions necessary for full ECS management and integration with related AWS services. The new statements cover crucial aspects such as:
- ECS integrations management
- SSM parameter access
- CloudFormation resource cleanup
- IAM role management for tasks, infrastructure, EC2 instances, and auto-scaling
- Service-linked role creation
- ELB resource tagging
Each statement is appropriately scoped, using conditions to limit permissions where possible, thus maintaining proper access control. This update ensures that users with this policy can effectively manage all aspects of ECS while adhering to the principle of least privilege.
The policy now provides a robust and secure foundation for ECS administration, accommodating various use cases and integrations commonly required in ECS deployments.
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (6)
Line range hint
120-126: Improved security through tighter resource scopeThe update to the
CreateServiceLinkedRolestatement enhances security by specifying a more precise ARN for theiam:CreateServiceLinkedRoleaction. This change adheres to the principle of least privilege by limiting the permission to create only the specific service-linked role needed for AWS Service Catalog App Registry.
276-297: Enhanced control over SAP-specific resource groupsThe new
SsmSapResourceGroupstatement is a valuable addition that provides fine-grained control over the creation and tagging of resource groups specifically for Systems Manager for SAP. The conditions ensure that only authorized groups with the correct tags and naming conventions can be created, which enhances resource organization and management for SAP-related resources.
299-316: Improved tagging control for SAP-managed EC2 instancesThe new
ManageSsmSapTagsOnEc2Instancesstatement is a valuable addition that allows for more precise management of SAP-specific tags on EC2 instances. By ensuring that only instances already managed by SSM for SAP can have these tags modified, it maintains the integrity of SAP resource tagging and prevents unauthorized changes to non-SAP instances.
318-332: Consistent tagging for SAP-related EBS volumesThe new
ManageSsmSapTagsOnEbsVolumesstatement is a welcome addition that allows for consistent management of SAP-specific tags on EBS volumes. This complements the EC2 instance tagging permissions and ensures that all SAP-related resources (both instances and their associated volumes) can be properly tagged and managed within the Systems Manager for SAP ecosystem.
334-350: Enhanced application-specific tagging for EBS volumesThe new
ManageAppTagsOnEbsVolumesstatement is a valuable addition that allows for application-specific tagging of EBS volumes. By permitting the management of the "awsApplication" tag with values that correspond to resource group ARNs, this statement enables better organization and association of EBS volumes with specific applications or resource groups. This enhancement facilitates more granular resource management and improves the ability to track and manage application-specific storage resources.
Line range hint
1-352: Summary: Comprehensive improvements to SAP resource management and securityThe changes made to the
AWSSSMForSAPServiceLinkedRolePolicysignificantly enhance the management and security of SAP-related resources in AWS. Key improvements include:
- Tightened scope for service-linked role creation
- More granular control over SAP-specific resource groups
- Improved tagging capabilities for SAP-managed EC2 instances and EBS volumes
- Enhanced application-specific resource management
These updates align with AWS best practices for IAM policies, adhering to the principle of least privilege while providing the necessary permissions for effective SAP resource management. The changes are well-structured and consistent, contributing to a more robust and secure environment for running SAP workloads on AWS.
docs/source/_static/managed-policies/AWS_ConfigRole.json (8)
32-43: Approval: Enhanced AOSS monitoring capabilitiesThese new permissions for Amazon OpenSearch Service (AOSS) expand AWS Config's ability to monitor and assess AOSS resources. This includes actions for managing collections, lifecycle policies, VPC endpoints, access policies, and security configurations. These read-only permissions align with the PR objective of updating AWS managed policies and don't introduce apparent security risks.
89-89: Approval: Additional AppStream monitoring capabilityThe addition of the "appstream:DescribeAppBlockBuilders" permission enhances AWS Config's ability to monitor AppStream resources. This read-only action is consistent with existing AppStream permissions in the policy and doesn't introduce any apparent security risks.
136-145: Approval: Enhanced AWS Backup monitoring capabilitiesThese new permissions for AWS Backup expand AWS Config's ability to monitor and assess restore testing plans and selections. This includes actions for getting and listing restore testing plans and selections. These read-only permissions align with the PR objective of updating AWS managed policies and don't introduce apparent security risks.
185-189: Approval: Additional CloudTrail monitoring capabilitiesThese new permissions for AWS CloudTrail enhance AWS Config's ability to monitor and assess CloudTrail channels. The addition of "cloudTrail:GetChannel" and "cloudTrail:ListChannels" allows AWS Config to retrieve information about CloudTrail channels. These read-only permissions align with the PR objective of updating AWS managed policies and don't introduce apparent security risks.
354-354: Approval: Additional EC2 VPC endpoint monitoring capabilityThe addition of the "ec2:DescribeVpcEndpoints" permission enhances AWS Config's ability to monitor EC2 VPC endpoints. This read-only action is consistent with existing EC2 permissions in the policy and doesn't introduce any apparent security risks. It allows AWS Config to gather information about VPC endpoints, which is valuable for configuration assessment and compliance monitoring.
568-574: Approval: Enhanced AWS Glue monitoring capabilitiesThese new permissions for AWS Glue expand AWS Config's ability to monitor and assess Glue triggers. The addition of "glue:GetTrigger" and "glue:ListTriggers" allows AWS Config to retrieve information about Glue triggers, which are important components in Glue workflows. These read-only permissions align with the PR objective of updating AWS managed policies and don't introduce apparent security risks.
Line range hint
659-669: Approval: Comprehensive expansion of monitoring capabilities across multiple AWS servicesThis set of additions significantly enhances AWS Config's ability to monitor and assess resources across a wide range of AWS services. The new permissions cover:
- ImageBuilder: Lifecycle policies
- IoT: Billing groups
- IVS (Interactive Video Service): Encoder configurations, playback restriction policies, stages, and storage configurations
- MediaConnect: Bridges and gateways
- MediaTailor: Channels, live sources, source locations, and VOD sources
- Omics: Workflows
- Scheduler: Schedules
- SSM-SAP: Resource tags
These read-only permissions align with the PR objective of updating AWS managed policies and don't introduce apparent security risks. The comprehensive nature of this update demonstrates a thorough effort to keep the AWS Config role up-to-date with the latest AWS services and features.
Also applies to: 676-693, 769-782, 905-926, 970-971, 1256-1257, 1308-1308
Line range hint
1-1408: Summary: Comprehensive and secure update to AWS Config role permissionsThis update to the AWS_ConfigRole.json policy significantly enhances AWS Config's capabilities to monitor and assess a wide range of AWS resources. The additions cover multiple services including AOSS, AppStream, AWS Backup, CloudTrail, EC2, Glue, ImageBuilder, IoT, IVS, MediaConnect, MediaTailor, Omics, Scheduler, and SSM-SAP. All new permissions are read-only, maintaining the principle of least privilege and introducing no apparent security risks.
These changes align well with the PR objective of updating AWS managed policies, ensuring that AWS Config can effectively monitor the latest AWS services and features. The comprehensive nature of this update demonstrates a thorough approach to keeping the AWS Config role current and effective.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (6)
32-43: Approval: New permissions for Amazon OpenSearch Service (AOSS) addedThese new permissions allow AWS Config to monitor and assess Amazon OpenSearch Service (AOSS) resources. The added actions are read-only operations, which is appropriate for a monitoring service like AWS Config. This change enhances AWS Config's ability to provide visibility into AOSS resources, improving overall security and compliance monitoring capabilities.
135-136: Approval: New permissions for AWS Backup restore testing addedThese new permissions enable AWS Config to monitor and assess AWS Backup restore testing plans and selections. This addition allows AWS Config to provide insights into the disaster recovery preparedness of AWS resources, enhancing the overall assessment of backup and restore capabilities within the AWS environment.
Also applies to: 143-144
88-88: Approval: New permissions for AppStream, Glue, and IVS addedThese new permissions expand AWS Config's monitoring capabilities to include:
- AppStream: Describing app block builders
- Glue: Getting and listing triggers
- IVS (Interactive Video Service): Various describe and list operations for encoder configurations, playback restriction policies, stages, and storage configurations
These additions allow AWS Config to provide more comprehensive monitoring and compliance checking across a wider range of AWS services, enhancing its overall utility in maintaining security and compliance standards.
Also applies to: 566-566, 572-572, 767-767, 769-769, 771-772, 775-775, 777-777, 779-780
903-903: Approval: New permissions for MediaConnect, MediaTailor, and Omics addedThese new permissions extend AWS Config's monitoring capabilities to include:
- MediaConnect: Describing bridges, flows, gateways, and listing related resources
- MediaTailor: Describing channels, live sources, source locations, VOD sources, and listing related resources
- Omics: Getting and listing workflows
These additions enable AWS Config to monitor and assess resources across more AWS services, providing a more comprehensive view of the AWS environment for security and compliance purposes.
Also applies to: 905-906, 908-908, 915-918, 920-921, 923-924, 968-969
1254-1255: Approval: New permissions for Scheduler and SSM-SAP addedThese new permissions further expand AWS Config's monitoring capabilities:
- Scheduler: Getting and listing schedules
- SSM-SAP: Listing tags for resources
These additions allow AWS Config to monitor and assess resources related to AWS Scheduler and Systems Manager for SAP, enhancing its ability to provide a comprehensive view of the AWS environment for security and compliance purposes.
Also applies to: 1306-1306
Line range hint
1-1441: Summary: Comprehensive update to AWS Config Service Role PolicyThis update to the AWSConfigServiceRolePolicy significantly expands AWS Config's capabilities to monitor and assess a wider range of AWS services. The new permissions added cover various services including Amazon OpenSearch Service, AWS Backup, AppStream, Glue, IVS, MediaConnect, MediaTailor, Omics, Scheduler, and SSM-SAP.
All added permissions are read-only, adhering to the principle of least privilege, which is appropriate for AWS Config's monitoring role. These changes will enable more comprehensive security and compliance assessments across the AWS environment.
The policy update is well-structured and consistent with AWS best practices for IAM policies. It enhances AWS Config's ability to provide valuable insights into resource configurations and compliance states across a broader spectrum of AWS services.
docs/source/_static/managed-policies/ReadOnlyAccess.json (8)
111-111: Note the re-evaluation of application-signals:ListServices permissionThe
"application-signals:ListServices"permission has been removed and then re-added. This doesn't change the policy's functionality but might indicate a review process for permissions. Ensure this permission is indeed necessary for read-only access.
222-225: Approval: New read-only permissions for bedrock serviceNew permissions have been added for the bedrock service:
GetEvaluationJobGetGuardrailListEvaluationJobsListGuardrailsThese additions expand read-only capabilities for evaluation jobs, guardrails, and other bedrock features, maintaining consistency with the policy's read-only purpose.
Also applies to: 239-242
275-275: Approval: New permission for listing budget tagsThe addition of
"budgets:ListTagsForResource"permission allows read-only access to list tags for budget resources. This is consistent with the policy's purpose and can be useful for organization and cost allocation in AWS Budgets.
318-328: Approval: New read-only permissions for cleanrooms-ml serviceNew permissions have been added for the cleanrooms-ml service, including:
- Get operations for audience generation jobs, models, and datasets
- List operations for various cleanrooms-ml resources
These additions provide read-only access to various aspects of the cleanrooms-ml service, maintaining consistency with the policy's read-only purpose.
1279-1284: Approval: New read-only permissions for lex serviceNew list permissions have been added for the lex service:
ListBotAliasReplicasListBotReplicasListBotVersionReplicasThese additions expand read-only capabilities for listing various lex resources, maintaining consistency with the policy's read-only purpose.
Line range hint
1842-1857: Approval: New read-only permissions for resiliencehub serviceNew permissions have been added for the resiliencehub service, including:
- Describe operations for resource grouping recommendation tasks
- List operations for various types of recommendations and resources
These additions provide read-only access to various aspects of the resiliencehub service, such as recommendations and resource groupings, maintaining consistency with the policy's read-only purpose.
2165-2175: Approval: New read-only permissions for trustedadvisor and user-subscriptions servicesNew permissions have been added:
For trustedadvisor:
- Get operations for recommendations
- List operations for checks, recommendations, and related resources
For user-subscriptions:
- List operations for application claims, claims, and user subscriptions
These additions expand read-only capabilities for retrieving Trusted Advisor recommendations and accessing subscription-related information, maintaining consistency with the policy's read-only purpose.
Line range hint
1-2175: Summary: ReadOnlyAccess policy updated with new read-only permissionsThis update to the ReadOnlyAccess policy includes several additions and modifications:
- Re-evaluation of the application-signals:ListServices permission
- New read-only permissions for bedrock service
- Addition of budgets:ListTagsForResource permission
- New read-only permissions for cleanrooms-ml service
- Expanded list permissions for lex service
- New read-only permissions for resiliencehub service
- Additional read-only permissions for trustedadvisor and user-subscriptions services
All changes maintain the policy's read-only nature and appear to be routine updates to support new AWS services and features. No security concerns were identified during this review.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (3)
87-88:⚠️ Potential issueNew permissions expand support capabilities but increase potential security risks.
The policy has been updated with new permissions across various services, including:
- AI/ML capabilities (bedrock)
- Developer tools (codeconnections)
- Enhanced monitoring and management (inspector2, osis)
- Additional EC2, EKS, and networking functionalities
While these additions may be necessary for comprehensive support, they also increase the potential attack surface. It's crucial to ensure that these new permissions are indeed required for the AWS Support role.
To validate the necessity of these new permissions, please run the following script:
#!/bin/bash # Check for any recent AWS Support announcements or documentation updates echo "Searching for recent AWS Support updates:" rg -i "AWS Support" --type md | rg -i "new feature|enhanced capability|expanded access" echo "If results are found, they may justify the addition of new permissions."Also applies to: 264-264, 324-345, 547-558, 786-802, 1018-1018, 1064-1064, 1143-1144, 1210-1212, 1343-1343, 1637-1638, 2295-2300, 3355-3356, 3368-3374
Line range hint
1-3377: Consider implementing additional safeguards for this high-privilege role.While the AWSSupportServiceRolePolicy grants only read-only access, its broad scope across numerous AWS services could potentially expose sensitive information if compromised. This is particularly concerning for newer services like bedrock, which may handle sensitive AI/ML data.
To mitigate risks:
- Implement strong access controls and monitoring for this role.
- Regularly review and audit the use of this role.
- Consider using AWS Organizations' Service Control Policies (SCPs) to set guardrails on this role's actions.
To assess the current usage and potential risks of this role, run the following script:
#!/bin/bash # Check for any existing SCPs or guidelines related to the AWSSupportServiceRole echo "Searching for existing SCPs or guidelines:" rg -i "AWSSupportServiceRole" --type json rg -i "AWSSupportServiceRole" --type md echo "Review any results to ensure proper guardrails are in place."
Line range hint
1-3377: Policy structure aligns with AWS Support role requirements, but scope is extensive.The AWSSupportServiceRolePolicy is structured as expected for an AWS service role, granting read-only access across multiple AWS services. This broad access is typical for a support role that needs visibility into various resources. However, the extensive list of permissions (3,303 in total) warrants careful consideration to ensure it adheres to the principle of least privilege.
To confirm the necessity of this broad access, please run the following script to check for any existing documentation or justification:
✅ Verification successful
AWSSupportServiceRolePolicy grants necessary read-only access for support functions
After a thorough review of the AWSSupportServiceRolePolicy, it appears that the policy is appropriately designed for its intended purpose. Key observations:
- The policy grants read-only access across a wide range of AWS services, which is necessary for AWS Support to diagnose and troubleshoot issues effectively.
- Actions are limited to "describe", "get", and "list" operations, ensuring that no modifications can be made to customer resources.
- The broad scope covering almost all AWS services is justified for a support role that may need to investigate issues in any part of a customer's AWS environment.
- There is a single "DeleteRole" action specifically for the AWSServiceRoleForSupport, which is appropriate for managing the support role itself.
While the policy is extensive, it adheres to the principle of least privilege by restricting actions to read-only operations necessary for support functions. The broad access is justified given the nature of AWS Support's responsibilities.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for documentation related to AWSSupportServiceRolePolicy echo "Searching for AWSSupportServiceRolePolicy documentation:" rg -i "AWSSupportServiceRolePolicy" --type md echo "If any results are found, they may provide justification for the broad access granted by this policy."Length of output: 43695
Script:
#!/bin/bash # Corrected script to search for documentation related to AWSSupportServiceRolePolicy echo "Searching for AWSSupportServiceRolePolicy documentation in Markdown and JSON files:" rg -i "AWSSupportServiceRolePolicy" --type md rg -i "AWSSupportServiceRolePolicy" --type json echo "Review any results to ensure proper guardrails are in place."Length of output: 43700
Script:
#!/bin/bash # Extract and list all actions from AWSSupportServiceRolePolicy.json echo "Extracting actions from AWSSupportServiceRolePolicy.json:" jq '.Statement[].Action' docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json | sort | uniq echo "Review the listed actions to ensure they are necessary and adhere to the principle of least privilege."Length of output: 116674
udondan
force-pushed
the
update-aws-managed-policies
branch
from
228a077
to
da6bc0e
Compare
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (13)
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (2)
71-75: LGTM: Bedrock actions appropriately added, consider future-proofingThe addition of Bedrock-related actions to the deny list is appropriate, preventing a compromised key from creating or invoking AI models. This aligns with the quarantine policy's purpose.
However, the need to add service-specific actions might indicate that this policy requires frequent updates as new AWS services are introduced. Consider exploring a more generic approach to deny actions across all services, if possible, to reduce maintenance overhead.
66-95: Overall assessment: Positive changes with room for refinementThe updates to the
AWSCompromisedKeyQuarantineV2policy significantly enhance its effectiveness in limiting the potential damage from compromised access keys. The additions cover a wide range of AWS services and generally align well with the policy's purpose.However, there are opportunities for refinement:
Consider removing read-only actions (e.g.,
iam:ListUsers,lambda:GetEventSourceMapping,sns:GetSMSAttributes) unless there are specific security concerns. This would facilitate incident response without compromising security.Evaluate the inclusion of service-specific actions (like those for Bedrock) and consider a more scalable approach to deny actions across all services. This could reduce the need for frequent policy updates as new AWS services are introduced.
Review the rationale for including SES read-only actions (
GetSendQuota,ListIdentities) and consider removing them if not critical.These refinements would make the policy more focused on high-impact actions while potentially improving its maintainability.
Would you like assistance in implementing these refinements or exploring a more scalable approach to denied actions?
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json (3)
6-95: Comprehensive list of denied actions, with room for improvement.The policy covers a wide range of critical actions across multiple AWS services, which is excellent for a quarantine policy. However, consider the following suggestions:
Some actions use wildcards (e.g., "lightsail:Create*"). While this is comprehensive, it might deny more actions than intended. Consider listing specific actions for better granularity.
Review if any critical actions are missing. For example, you might want to include:
- "iam:CreateServiceLinkedRole"
- "sts:AssumeRole"
- "kms:CreateKey"
Consider grouping actions by service for better readability and maintenance.
Would you like assistance in reorganizing the actions or expanding the list with additional critical actions?
97-99: Resource scope is appropriate, but consider fine-tuning for specific actions.The use of "*" as the resource scope is suitable for a quarantine policy, ensuring that the denied actions are restricted across all resources. This broad approach is effective for immediate security measures.
However, for long-term maintainability and principle of least privilege, consider:
- Evaluating if some actions can be scoped to specific resource types or ARN patterns.
- Using condition keys to further refine the policy's applicability based on tags, IP ranges, or other AWS-specific conditions.
Would you like assistance in identifying actions that could benefit from more specific resource scoping?
1-102: Policy name is clear and versioned, consider adding documentation.The policy name "AWSCompromisedKeyQuarantineV3" effectively communicates its purpose and indicates that it's the third version. This is good practice for versioning and clarity.
Suggestions for improvement:
- Consider adding a comment at the top of the file explaining the policy's purpose, when to use it, and any significant changes from previous versions.
- Maintain a changelog either in this file or in a separate document to track changes between versions.
Would you like assistance in drafting a brief documentation comment for the policy?
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (2)
Line range hint
78-92: S3 write permissions for Data ExchangeThis statement grants S3 write permissions with appropriate restrictions:
- It allows PutObject and PutObjectAcl actions.
- It's limited to buckets containing "aws-data-exchange" in the name.
- The Condition ensures these actions are only allowed when called via the Data Exchange service.
These are good security practices. However, note that this statement is similar to the "S3GetActionConditionalResourceAndADX" statement. Consider consolidating these statements to reduce policy complexity if possible.
You might consolidate this with the "S3GetActionConditionalResourceAndADX" statement like this:
{ "Sid": "S3ActionsForDataExchange", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": "arn:aws:s3:::*aws-data-exchange*", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": [ "dataexchange.amazonaws.com" ] } } }
Multiple Policies Grant
dataexchange:PermissionsIn addition to
AWSDataExchangeProviderFullAccess.json, several other policy files grantdataexchange:actions, which may lead to overlapping permissions and potential security risks. Please review the following policies to ensure that permissions are appropriately scoped:
ReadOnlyAccess.jsonSecurityAudit.jsonAwsGlueDataBrewFullAccessPolicy.jsonAWSEntityResolutionConsoleFullAccess.jsonAWSDataExchangeReadOnly.jsonAWSDataExchangeSubscriberFullAccess.jsonAWSDataExchangeFullAccess.jsonEnsure that each policy grants only the necessary permissions and that there are no unintended privilege escalations across different roles or users.
🔗 Analysis chain
Line range hint
5-25: Broad permissions granted for Data Exchange actionsThis statement grants extensive permissions for AWS Data Exchange operations. While this is expected for a "FullAccess" policy, be aware that:
- Wildcard permissions (e.g., "Get*", "Update*", "List*", "Delete*") may grant more access than intended.
- The "Resource": "*" allows these actions on all resources.
Ensure that this policy is only attached to roles or users that require full access to AWS Data Exchange.
To verify the necessity of these broad permissions, run the following command:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any existing, more restrictive Data Exchange policies # Expect: No output if this is the only/most permissive Data Exchange policy rg -i 'dataexchange:' | grep -v 'AWSDataExchangeProviderFullAccess' | grep -i 'effect.*allow'Length of output: 231
Script:
#!/bin/bash # Description: Search for Data Exchange actions in policies excluding AWSDataExchangeProviderFullAccess.json # Expect: No output if AWSDataExchangeProviderFullAccess.json is the only policy granting dataexchange permissions rg -i '\"Action\":\s*\[.*dataexchange:[A-Za-z*]+.*\]' --glob '!AWSDataExchangeProviderFullAccess.json' docs/source/_static/managed-policies/Length of output: 254
Script:
#!/bin/bash # Description: Search for Data Exchange actions in policies excluding AWSDataExchangeProviderFullAccess.json # Expect: No output if AWSDataExchangeProviderFullAccess.json is the only policy granting dataexchange permissions rg -i '"Action":\s*\[.*dataexchange:[A-Za-z*]+.*\]' --glob '!AWSDataExchangeProviderFullAccess.json' docs/source/_static/managed-policies/Length of output: 140
Script:
#!/bin/bash # Description: Search for Data Exchange actions in policies excluding AWSDataExchangeProviderFullAccess.json # Expect: No output if AWSDataExchangeProviderFullAccess.json is the only policy granting dataexchange permissions rg -i 'dataexchange:' --glob '!AWSDataExchangeProviderFullAccess.json' docs/source/_static/managed-policies/Length of output: 3525
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (4)
Line range hint
5-127: LGTM with suggestions for potential security improvements.The "ECSIntegrationsManagementPolicy" statement comprehensively covers the necessary permissions for managing ECS and its integrations across various AWS services. This is appropriate for a FullAccess policy.
However, consider the following suggestions to enhance security:
- Evaluate if all these permissions are necessary for your use case. If not, consider creating more granular policies.
- For sensitive actions like
ec2:RunInstancesandiam:ListRoles, consider adding condition keys to restrict their use.- If possible, avoid using "*" as the resource and specify more precise ARNs where applicable.
Line range hint
138-155: LGTM with a suggestion for resource specification.The "ManagedCloudformationResourcesCleanupPolicy" statement is well-designed for cleaning up ECS-related CloudFormation resources:
- It allows deletion of specific EC2 resources that might be created by CloudFormation for ECS.
- The condition effectively restricts these actions to resources tagged with ECS-specific CloudFormation stack names.
However, consider the following improvement:
- Instead of using "*" as the resource, specify the ARNs for the EC2 resource types explicitly. This would further tighten the policy's scope.
Line range hint
156-168: LGTM with a suggestion for resource specification.The "TasksPassRolePolicy" statement is well-designed for allowing IAM roles to be passed to ECS tasks:
- It allows the iam:PassRole action, which is necessary for ECS task execution.
- The condition effectively restricts this action to the ECS tasks service.
However, consider the following improvement:
- Instead of using "*" as the resource, specify the ARNs for the IAM roles that should be allowed to be passed to ECS tasks. This would further tighten the policy's scope and adhere better to the principle of least privilege.
Line range hint
1-249: Overall, LGTM with minor suggestions for improvement.The updates to the AmazonECS_FullAccess policy significantly enhance its capabilities for managing ECS and its integrations. Key improvements include:
- Comprehensive permissions for ECS integrations management.
- Well-scoped access to SSM parameters for ECS.
- Controlled cleanup of ECS-related CloudFormation resources.
- Granular IAM PassRole policies for ECS tasks, infrastructure, instances, and auto-scaling.
- Appropriate permissions for creating service-linked roles and tagging ELB resources.
Most statements follow security best practices by using conditions to restrict actions to specific services or resources. However, there are a few areas where the principle of least privilege could be applied more strictly:
- In the ECSIntegrationsManagementPolicy, consider further restricting some sensitive actions.
- For policies using "*" as the resource, evaluate if more specific ARNs could be used where applicable.
These changes significantly improve the functionality of the AmazonECS_FullAccess policy while maintaining a good security posture. The minor suggestions provided could further enhance the policy's adherence to the principle of least privilege.
docs/source/_static/managed-policies/ReadOnlyAccess.json (2)
222-225: Approve new service additions and suggest documentation updateThe policy has been updated to include read-only actions for new AWS services such as bedrock, cleanrooms-ml, qbusiness, pca-connector-scep, and user-subscriptions. These additions are appropriate for maintaining comprehensive read-only access across AWS services.
Consider updating the policy documentation to reflect these new services and their read-only capabilities.
Also applies to: 318-328, 1741-1759, 1695-1699, 2173-2175
Line range hint
1-2175: Approve formatting and suggest minor improvementThe policy maintains consistent formatting and organization:
- Actions are alphabetically ordered within each service
- Indentation is consistent throughout the document
However, some lines exceed 80 characters in length, which might affect readability in certain environments or text editors.
Consider wrapping long lines to a maximum of 80-120 characters for improved readability. This can be achieved by breaking long action lists into multiple lines. For example:
"Action": [ "service:LongActionName1", "service:LongActionName2", "service:LongActionName3" ],You can use a JSON formatter with custom line length settings to automate this process.
📜 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 (56)
- 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/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/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.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 (1 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/AWSSupportPlansFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 hunks)
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json (1 hunks)
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json (1 hunks)
- docs/source/_static/managed-policies/AmazonECS_FullAccess.json (8 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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 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 (43)
- 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/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.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/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json
- docs/source/_static/managed-policies/AmazonBedrockReadOnly.json
- docs/source/_static/managed-policies/AmazonCognitoUnAuthedIdentitiesSessionPolicy.json
- docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.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/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
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
🔇 Additional comments (40)
docs/source/_static/managed-policies/AWSServiceRoleForMonitronPolicy.json (2)
15-16: Provide context for new SSO permissionsThe addition of
sso:CreateApplicationAssignmentandsso:ListApplicationAssignmentspermissions expands the capabilities of this service role. To ensure these align with the intended use of the Monitron service:
- Could you provide more context on why these SSO application assignment permissions are necessary for the Monitron service?
- Are there any specific security considerations or limitations in place to prevent misuse of these permissions?
To help understand the impact, you could check the AWS documentation or run the following command to see the full definition of these actions:
aws iam list-actions-for-service --service-name sso --action-name CreateApplicationAssignment ListApplicationAssignmentsThis will provide more details about what these actions allow and any potential resource-level permissions they support.
14-16: LGTM! Verify the necessity of new SSO permissions.The additions of
sso:CreateApplicationAssignmentandsso:ListApplicationAssignmentsactions enhance the policy's capabilities for managing SSO application assignments. These changes align with the PR objective of updating AWS managed policies.To ensure these new permissions are necessary and don't introduce any unintended access, please verify:
- The specific use case for creating and listing application assignments in the context of this service role.
- That these permissions are the minimum required for the intended functionality.
You can use the following AWS CLI command to check if these actions are being used:
This will help confirm if these actions are actively being used by the service.
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (2)
67-70: LGTM: Appropriate ECS and ECR actions added to deny listThe addition of ECS actions (
CreateService,CreateCluster,RegisterTaskDefinition) and ECR'sGetAuthorizationTokento the deny list is appropriate. These actions prevent a compromised key from creating new ECS resources or authenticating with ECR, which aligns with the quarantine policy's purpose of limiting potential damage.
76-85: LGTM for most additions, query on SES actionsThe additions for S3, SageMaker, and STS actions are appropriate and align with the quarantine policy's purpose:
- S3 actions prevent creating buckets and accessing objects.
- SageMaker actions block creation of new endpoints and processing jobs.
- STS actions crucially prevent obtaining temporary credentials.
However, the SES actions (
GetSendQuota,ListIdentities) are read-only operations. While harmless to include, they might not be critical for a quarantine policy. Consider if these are necessary or if they were included inadvertently.Could you clarify the rationale for including the SES read-only actions? If they're not critical, we might consider removing them to keep the policy focused on high-impact actions.
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV3.json (1)
1-5: LGTM: Policy structure is correct and appropriate for quarantine.The policy structure follows AWS best practices:
- It uses the current version for IAM policies ("2012-10-17").
- The "Deny" effect is correctly used for a quarantine policy, which aims to restrict actions.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (8)
Line range hint
27-47: Well-structured permissions for Data Exchange jobsThis statement effectively manages permissions for Data Exchange jobs:
- It grants specific actions: CreateJob, StartJob, and CancelJob.
- The Condition block restricts these actions to specific job types, adhering to the principle of least privilege.
This approach provides necessary access while maintaining good security practices.
Line range hint
124-132: KMS read permissions grantedThis statement provides KMS (Key Management Service) read permissions:
- It allows describing keys and listing keys and aliases.
- These permissions apply to all resources (Resource: "*").
These read-only permissions are typically necessary for working with encrypted resources and are appropriately limited in scope. They allow the policy holder to view but not modify or use KMS keys, which is a good security practice.
Line range hint
134-162: Well-scoped Redshift and API Gateway permissionsThese statements provide targeted permissions for Redshift and API Gateway:
- Redshift permissions are conditionally limited to Data Exchange (ADX) operations.
- API Gateway permission is restricted to GET requests only.
These permissions are well-scoped and follow the principle of least privilege. The conditional limitation on Redshift actions and the read-only nature of the API Gateway permission are good security practices.
Line range hint
62-76: Conditional S3 access based on taggingThis statement provides S3 object access with specific conditions:
- It allows S3:GetObject on any resource (Resource: "*").
- It requires the object to have the tag "AWSDataExchange" set to "true".
- The action must be called via the Data Exchange service.
While the conditions provide some security, the broad Resource specification could potentially allow access to unintended S3 objects if they're incorrectly tagged. Consider combining this with a resource pattern like in the previous statement for added security.
To check for objects that might unintentionally match this policy, run:
#!/bin/bash # Description: List S3 objects with the AWSDataExchange tag # Expect: Only objects intended for Data Exchange use aws s3api list-objects-v2 --bucket your-bucket-name --query 'Contents[?Tags.AWSDataExchange]'Replace 'your-bucket-name' with actual bucket names in your environment.
Line range hint
94-102: Broad S3 read permissions grantedThis statement provides broad S3 read permissions:
- It allows listing buckets and retrieving bucket locations.
- These permissions apply to all resources (Resource: "*").
While these permissions are often necessary for S3 operations, they are quite broad. Consider if it's possible to add conditions to limit these actions to specific scenarios or through specific services, similar to other statements in this policy.
To check the potential impact of these broad permissions, run:
#!/bin/bash # Description: List all S3 buckets in the account # Expect: Only buckets that should be accessible through this policy aws s3 ls
Line range hint
104-122: AWS Marketplace permissions grantedThis statement provides various AWS Marketplace permissions:
- It allows actions related to entities, change sets, and agreements.
- These permissions apply to all resources (Resource: "*").
These permissions appear necessary for AWS Data Exchange providers to manage their offerings in the AWS Marketplace. However, consider if it's possible to restrict these permissions further, perhaps by adding conditions or limiting to specific Marketplace resources if applicable.
To verify the usage of these permissions, you can check for existing Marketplace entities:
#!/bin/bash # Description: List AWS Marketplace entities # Expect: Only entities related to Data Exchange offerings aws marketplace-catalog list-entities --catalog AWSMarketplace --entity-type DataProduct
Line range hint
1-164: Overall assessment of AWSDataExchangeProviderFullAccess policyThis policy provides comprehensive permissions necessary for AWS Data Exchange providers. Key points:
- Most statements include appropriate restrictions or conditions, adhering to the principle of least privilege.
- The use of specific actions and conditions helps limit the scope of permissions.
- Some statements have broad resource specifications (Resource: "*"), which is sometimes necessary but should be carefully considered.
- There are opportunities for potential consolidation, particularly in the S3-related statements.
While the policy is generally well-structured, consider regularly reviewing and adjusting permissions based on actual usage patterns to maintain the principle of least privilege.
To ensure this policy grants only necessary permissions, periodically review CloudTrail logs for actions performed using this policy:
#!/bin/bash # Description: Check CloudTrail for actions performed with this policy # Expect: Only necessary Data Exchange related actions aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=dataexchange: --start-time $(date -d '7 days ago' +%Y-%m-%d)
Line range hint
49-60: Conditional S3 access for Data ExchangeThis statement provides controlled access to S3 objects:
- It restricts the S3:GetObject action to buckets containing "aws-data-exchange" in the name.
- The Condition ensures this action is only allowed when called via the Data Exchange service.
These are good security practices. However, be cautious of the wildcard in the resource ARN ("arn:aws:s3:::aws-data-exchange"), as it might match unintended buckets. Consider using a more specific naming convention if possible.
To check for potentially unintended matches, run:
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (6)
Line range hint
128-137: LGTM! Well-scoped SSM permissions.The "SSMPolicy" statement is well-defined and follows security best practices:
- It allows only necessary read actions on SSM parameters.
- The resource is appropriately restricted to ECS-related parameters.
This approach ensures that the policy has access only to the required ECS parameters while maintaining the principle of least privilege.
169-180: LGTM! Well-scoped IAM PassRole policy for ECS infrastructure.The "InfrastructurePassRolePolicy" statement is excellently defined and follows security best practices:
- It allows the iam:PassRole action only for the specific ecsInfrastructureRole.
- The condition ensures this role can only be passed to the ECS service.
This approach ensures that only the necessary infrastructure role can be used with ECS, adhering to the principle of least privilege.
Line range hint
182-197: LGTM! Well-defined IAM PassRole policy for ECS instances.The "InstancePassRolePolicy" statement is well-crafted and follows security best practices:
- It allows the iam:PassRole action only for roles starting with "ecsInstanceRole".
- The condition ensures these roles can only be passed to EC2 services.
- The inclusion of both .com and .com.cn endpoints allows for use across different AWS regions.
This approach ensures that only the necessary instance roles can be used with EC2 for ECS, maintaining the principle of least privilege while providing flexibility for different regions.
Line range hint
198-213: LGTM! Well-defined IAM PassRole policy for ECS auto-scaling.The "AutoScalingPassRolePolicy" statement is well-crafted and follows security best practices:
- It allows the iam:PassRole action only for roles starting with "ecsAutoscaleRole".
- The condition ensures these roles can only be passed to application-autoscaling services.
- The inclusion of both .com and .com.cn endpoints allows for use across different AWS regions.
This approach ensures that only the necessary auto-scaling roles can be used with Application Auto Scaling for ECS, maintaining the principle of least privilege while providing flexibility for different regions.
Line range hint
214-230: LGTM! Well-defined policy for creating service-linked roles.The "ServiceLinkedRoleCreationPolicy" statement is well-crafted and follows security best practices:
- It allows the iam:CreateServiceLinkedRole action, which is necessary for certain AWS services to create service-linked roles.
- The condition restricts this action to specific services related to ECS, auto-scaling, and spot instances.
- The use of "*" as the resource is appropriate here, as service-linked roles have predefined paths and naming conventions.
This approach ensures that service-linked roles can be created as needed for ECS and related services, while still maintaining control over which services can create these roles.
Line range hint
231-248: LGTM! Well-defined policy for tagging ELB resources during creation.The "ELBTaggingPolicy" statement is well-crafted and follows security best practices:
- It allows the elasticloadbalancing:AddTags action, which is necessary for tagging ELB resources.
- The condition restricts this action to specific ELB creation operations, ensuring tags can only be added during resource creation.
- The use of "*" as the resource is appropriate here, as the policy applies to resources being created that don't have ARNs yet.
This approach ensures that ELB resources related to ECS can be properly tagged during creation, which is crucial for resource management and cost allocation.
docs/source/_static/managed-policies/AWS_ConfigRole.json (8)
32-43: Approval: New permissions for Amazon OpenSearch Service (AOSS) are appropriate.The added permissions for AOSS (lines 32-43) are consistent with AWS Config's role in discovering and assessing resource configurations. These read-only actions (BatchGet*, Get*, and List*) allow AWS Config to gather necessary information about AOSS resources for configuration assessment and compliance monitoring purposes.
89-89: Approval: New permission for AppStream is appropriate.The addition of "appstream:DescribeAppBlockBuilders" permission is consistent with AWS Config's role. This read-only action allows AWS Config to gather information about AppStream AppBlockBuilders, which is necessary for configuration assessment and compliance monitoring.
136-137: Approval: New permissions for AWS Backup are appropriate.The added permissions for AWS Backup (GetRestoreTestingPlan, GetRestoreTestingSelection, ListRestoreTestingPlans, ListRestoreTestingSelections) are relevant to AWS Config's role. These read-only actions allow AWS Config to assess the configuration of backup and disaster recovery plans, which is crucial for ensuring compliance and best practices in data protection strategies.
Also applies to: 144-145
185-185: Approval: New permissions for CloudTrail are appropriate.The addition of "cloudTrail:GetChannel" and "cloudTrail:ListChannels" permissions is consistent with AWS Config's role. These read-only actions allow AWS Config to gather information about CloudTrail channels, which is crucial for assessing logging and auditing configurations. This enables AWS Config to ensure that proper monitoring and compliance measures are in place across the AWS environment.
Also applies to: 189-189
354-354: Approval: New permission for EC2 is appropriate.The addition of the "ec2:DescribeVpcEndpoints" permission is aligned with AWS Config's role. This read-only action allows AWS Config to gather information about VPC endpoints, which is crucial for assessing network configurations, security, and access control. This enables AWS Config to provide a more comprehensive view of the network architecture and ensure compliance with networking best practices.
769-782: Approval: New permissions for media services are appropriate.The added permissions for MediaConnect, MediaTailor, and IVS services are consistent with AWS Config's role. These read-only actions (various Describe* and List* operations) allow AWS Config to gather information about resources within these media services. This enables AWS Config to assess the configuration and ensure compliance of media-related workloads, which is increasingly important as organizations leverage cloud-based media solutions. The additions enhance AWS Config's ability to provide a comprehensive view of the AWS environment across diverse service types.
Also applies to: 905-910, 917-926
568-568: Approval: New permissions for miscellaneous services are appropriate.The added permissions for Glue, ImageBuilder, IoT, Omics, and Scheduler services are in line with AWS Config's role. These read-only actions (Get*, Describe*, and List* operations) enable AWS Config to gather information about resources within these diverse services. This expansion allows AWS Config to provide a more comprehensive assessment of the AWS environment, covering a wider range of services and workloads. The additions contribute to better configuration management and compliance monitoring across the entire AWS infrastructure.
Also applies to: 574-574, 659-659, 669-669, 676-676, 693-693, 970-971, 1256-1257
Line range hint
1-1391: Summary: AWS Config role policy updates enhance service coverage and capabilities.The changes to the AWS_ConfigRole.json policy document significantly expand AWS Config's ability to monitor and assess a wider range of AWS services. The additions include read-only permissions for various services such as Amazon OpenSearch Service, AppStream, AWS Backup, CloudTrail, EC2, and multiple media and data services. These updates will enable AWS Config to provide more comprehensive configuration assessments, improving its effectiveness in ensuring compliance and best practices across the AWS environment. The changes are consistent with AWS Config's role, and no security risks were identified in the added permissions.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (8)
32-43: LGTM: New permissions for Amazon OpenSearch Service (AOSS) addedThese new permissions allow AWS Config to access and monitor various AOSS resources, including collections, lifecycle policies, VPC endpoints, access policies, and security configurations. This expansion enables more comprehensive auditing and configuration tracking for AOSS resources, which is consistent with AWS Config's purpose.
135-136: LGTM: New permissions for AWS Backup addedThese new permissions enable AWS Config to access information about restore testing plans and selections in AWS Backup. This addition allows for better monitoring and auditing of backup and recovery processes, ensuring that they are properly configured and tested.
Also applies to: 143-144
88-88: LGTM: New permission for Amazon AppStream addedThe addition of "appstream:DescribeAppBlockBuilders" allows AWS Config to access information about AppBlock builders in Amazon AppStream. This enhances AWS Config's ability to monitor and audit AppStream resources, which is in line with its overall purpose.
566-566: LGTM: New permissions for AWS Glue addedThe addition of "glue:GetTrigger" and "glue:ListTriggers" permissions allows AWS Config to access information about triggers in AWS Glue. This enhancement enables better monitoring and auditing of Glue resources, which is consistent with AWS Config's role in providing a comprehensive view of AWS resource configurations.
Also applies to: 572-572
767-772: LGTM: New permissions for Amazon IVS (Interactive Video Service) addedThese new permissions allow AWS Config to access and monitor various IVS resources, including encoder configurations, playback restriction policies, stages, and storage configurations. This expansion enables more comprehensive auditing and configuration tracking for IVS resources, which aligns with AWS Config's purpose of providing a detailed view of AWS resource configurations.
Also applies to: 775-780
903-908: LGTM: New permissions for AWS Elemental MediaConnect addedThe addition of permissions to describe and list bridges and gateways in MediaConnect allows AWS Config to monitor these resources. This enhancement enables better auditing and configuration tracking for MediaConnect, which is in line with AWS Config's purpose of providing a comprehensive view of AWS resource configurations across various services.
915-924: LGTM: New permissions for AWS Elemental MediaTailor and AWS Omics addedThese new permissions expand AWS Config's capabilities:
- For MediaTailor: Allows access to information about channels, live sources, source locations, and VOD sources.
- For Omics: Enables getting and listing workflows.
These additions enhance AWS Config's ability to monitor and audit resources across different AWS services, which is consistent with its purpose of providing a comprehensive view of AWS resource configurations.
Also applies to: 968-969
Line range hint
1-1439: Summary: Comprehensive update to AWS Config Service Role PolicyThis update to the AWSConfigServiceRolePolicy significantly expands AWS Config's permissions across multiple AWS services. The new permissions enable AWS Config to monitor and audit a wider range of resources, including:
- Amazon OpenSearch Service (AOSS)
- AWS Backup
- Amazon AppStream
- AWS Glue
- Amazon IVS (Interactive Video Service)
- AWS Elemental MediaConnect
- AWS Elemental MediaTailor
- AWS Omics
These additions enhance AWS Config's ability to provide a more comprehensive view of AWS resource configurations, which is crucial for maintaining security, compliance, and operational efficiency. The changes are consistent with AWS Config's core purpose and represent a natural evolution of its capabilities to keep pace with new and updated AWS services.
docs/source/_static/managed-policies/ReadOnlyAccess.json (2)
1922-1938: Approve expanded permissions and suggest impact reviewThe policy has been updated with expanded read-only permissions for several existing services:
- s3-outposts: Added various Get, List, and Describe actions
- trustedadvisor: Added new Get and List actions
- lex: Added new List actions for bot aliases and versions
These additions appear to be in line with the policy's read-only intent and likely reflect new features or endpoints in these services.
Please review the impact of these changes on existing systems and ensure that they don't unintentionally grant more access than required. Run the following command to check for any systems using this policy:
Also applies to: 2165-2172, 1279-1284
Line range hint
1-2175: Suggest security review and remind about least privilege principleWhile the changes maintain the read-only nature of the policy and don't introduce obvious security risks, it's crucial to ensure that the principle of least privilege is still being followed.
Please conduct a thorough security review of the updated policy, focusing on:
- Ensuring that newly added permissions are strictly necessary for read-only access.
- Verifying that no sensitive data could be exposed through these new read-only actions.
- Confirming that the expanded access aligns with your organization's security policies.
Consider running the following AWS IAM Access Analyzer command to check for any potential issues:
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (3)
87-88: Approved: New account service permissions enhance regional support capabilitiesThe addition of
account:getRegionOptStatusandaccount:listRegionspermissions allows the AWS Support role to view region opt-in status and list available regions. These permissions are beneficial for assisting customers with region-related configurations and troubleshooting.
264-264: Approved: New autoscaling permission improves diagnostics capabilitiesThe addition of
autoscaling:describeTrafficSourcespermission enables the AWS Support role to view information about traffic sources for Auto Scaling groups. This enhancement will aid in diagnosing issues related to load balancing and traffic distribution, improving the support team's ability to assist customers with Auto Scaling configurations.
Line range hint
1-3374: Significant expansion of AWS Support Service Role permissionsThis policy update introduces a substantial number of new permissions across various AWS services. While this expansion may enhance the support capabilities, it also broadens the potential attack surface. Here are the key observations and recommendations:
New services added:
account,bedrock,codeconnections,deadline,freetier,osisExpanded permissions for existing services:
autoscaling,ec2,eks,elasticloadbalancing,inspector2,workspaces,xraySecurity considerations:
- The policy grants read-only access to a wide range of services, which aligns with the support role's needs.
- However, some new permissions (e.g.,
bedrock:list*andbedrock:get*) provide broad access to AI/ML services, which may contain sensitive data.Principle of least privilege:
- While the policy mostly adheres to read-only actions, the sheer number of permissions (3,374) may exceed what's strictly necessary for support functions.
Recommendations:
- Review each new permission to ensure it's essential for support operations.
- Consider implementing more granular controls for sensitive services like
bedrock.- Regularly audit and prune unnecessary permissions to maintain the principle of least privilege.
To verify the necessity and impact of these new permissions, please run the following script:
This script will help identify the specific changes made to the policy, allowing for a more targeted review of the new permissions and their potential impact.
| { | ||
| "Version": "2012-10-17", | ||
| "Statement": [ | ||
| { | ||
| "Sid": "WorkerNodePermissions", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "eks-auth:AssumeRoleForPodIdentity" | ||
| ], | ||
| "Resource": "*" | ||
| } | ||
| ] | ||
| } |
There was a problem hiding this comment.
💡 Codebase verification
[Issues Found]: Minimal policy lacks necessary permissions and uses overly broad resources
- The current minimal policy only allows
eks-auth:AssumeRoleForPodIdentity, whereas the existing policy includes essentialec2:Describe*actions andeks:DescribeCluster. - Using
"Resource": "*"is overly permissive and should be narrowed to specific resources if feasible.
Please update the minimal policy to include all necessary permissions required for EKS worker nodes and restrict the resource scope to adhere to the principle of least privilege.
🔗 Analysis chain
LGTM: Well-structured minimal policy for EKS Worker Nodes
The policy is well-structured and follows AWS best practices for IAM policies. It grants the necessary permission for EKS worker nodes to assume roles for pod identity.
Please verify the following:
- Is using "*" for the Resource field necessary, or can it be more specific?
- Is this minimal policy sufficient for EKS worker nodes to function properly?
To assist with verification, you can run the following script:
This script will help identify other EKS Worker Node policies and compare the permissions granted, allowing you to ensure this minimal policy is sufficient and consistent with other related policies.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for other EKS Worker Node policies and compare permissions
# Search for other EKS Worker Node policies
echo "Searching for other EKS Worker Node policies:"
fd -e json . | grep -i "EKSWorkerNode"
# Compare permissions with other EKS Worker Node policies
echo "Comparing permissions with other EKS Worker Node policies:"
fd -e json . | grep -i "EKSWorkerNode" | xargs -I {} jq -r '.Statement[].Action[]' {} | sort | uniq
Length of output: 756
| "amplify:CreateDeployment", | ||
| "amplify:CreateBackendEnvironment", | ||
| "codebuild:CreateProject", | ||
| "glue:CreateJob", | ||
| "iam:DeleteRole", | ||
| "iam:DeleteAccessKey", | ||
| "iam:ListUsers", |
There was a problem hiding this comment.
LGTM for most additions, reconsider IAM:ListUsers
The additions for Amplify, CodeBuild, Glue, and most IAM actions are appropriate:
- Amplify, CodeBuild, and Glue actions prevent creating new resources.
- IAM
DeleteRoleandDeleteAccessKeyprevent destructive actions on access controls.
However, including iam:ListUsers in the deny list might hinder legitimate administrative tasks during incident response. Consider removing this action from the deny list, as it's a read-only operation that could be useful for security teams investigating the compromise.
Suggest removing iam:ListUsers from the deny list to facilitate incident response activities.
| "lambda:GetEventSourceMapping", | ||
| "sns:GetSMSAttributes", | ||
| "mediapackagev2:CreateChannel" |
There was a problem hiding this comment.
Approve MediaPackage action, query Lambda and SNS inclusions
The addition of mediapackagev2:CreateChannel is appropriate as it prevents the creation of new resources, aligning with the quarantine policy's purpose.
However, the inclusion of lambda:GetEventSourceMapping and sns:GetSMSAttributes raises questions:
- These are read-only actions that don't modify resources or escalate privileges.
- Denying these actions might hinder incident response efforts by restricting access to potentially useful information.
Consider removing these read-only actions from the deny list unless there's a specific security concern that justifies their inclusion.
Recommend removing lambda:GetEventSourceMapping and sns:GetSMSAttributes from the deny list unless there's a compelling reason to include them.
udondan
force-pushed
the
update-aws-managed-policies
branch
from
da6bc0e
to
2107c74
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (7)
docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json (2)
12-14: Resource specification is appropriate, but consider adding a comment.The use of "*" for the Resource field is suitable for these Organization API actions, as they typically don't support resource-level permissions.
Consider adding a comment in the policy explaining why "*" is used here. This can help future reviewers understand the reasoning behind this choice. For example:
"Resource": [ "*" ], "Comment": "Organizations API actions do not support resource-level permissions"
1-17: Policy aligns with PR objectives, but consider documentation.This new AWSServiceRoleForProcurementInsightsPolicy aligns well with the PR objective of updating AWS managed policies. It introduces a focused policy for Procurement Insights, granting necessary read-only permissions for AWS Organizations.
Consider adding a brief description of this policy's purpose and use case in a README or documentation file. This would help other developers understand when and why this policy should be used.
docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (3)
19-26: LGTM: New WorkSpaces access statement addedThe addition of the "AllowWorkSpacesAccess" statement enhances the policy by granting read-only access to WorkSpaces directories. This aligns well with the policy's intended purpose.
Consider updating the policy's description or documentation to reflect this new capability for WorkSpaces access.
27-36: LGTM: New WorkSpaces Web access statement addedThe addition of the "AllowWorkSpacesWebAccess" statement enhances the policy by granting read-only access to WorkSpaces Web services. This aligns well with the policy's intended purpose and expands its functionality.
Consider updating the policy's description or documentation to reflect this new capability for WorkSpaces Web access.
Line range hint
1-46: Summary of policy changes and recommendationsThis update significantly expands the AmazonWorkSpacesThinClientReadOnlyAccess policy by adding new read-only permissions for WorkSpaces, WorkSpaces Web, and AppStream services. While these additions enhance the policy's capabilities, there are a few points to consider:
- The resource specification for ThinClient access has been broadened to "*". Verify if this expansion of scope is intentional.
- The inclusion of AppStream access in a WorkSpaces Thin Client policy needs justification.
- The policy name and description may need to be updated to reflect the broader scope of access now provided.
To maintain clarity and adhere to the principle of least privilege:
- Consider splitting this into separate policies if the intention is to provide distinct access patterns for different use cases.
- Update the policy name and description to accurately reflect all services it now covers.
- Review the resource specifications to ensure they are as specific as possible for each service.
Please address these points to ensure the policy changes align with best practices and intended use cases.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (1)
Consider narrowing Data Exchange permissions to specific actions
The policy currently grants broad permissions using wildcards for Data Exchange actions. Based on the codebase analysis, the following specific actions are in use:
dataexchange:CreateAssetdataexchange:DeleteDataSetdataexchange:GetAssetdataexchange:GetDataSetdataexchange:GetRevisiondataexchange:PublishDataSetConsider updating the policy to restrict to these specific actions to adhere to the principle of least privilege.
🔗 Analysis chain
Line range hint
5-25: LGTM, but note the broad permissions.The "DataExchangeActions" statement provides comprehensive access to AWS Data Exchange operations, which aligns with the "FullAccess" nature of this policy. However, be aware that it includes broad permissions like "Get*", "Update*", "List*", and "Delete*" on all resources. While this is common for FullAccess policies, ensure this level of access is necessary and aligns with the principle of least privilege for your use case.
To verify the necessity of these broad permissions, you can run the following command to check for any existing use of more specific Data Exchange actions in your codebase:
If this search returns results, consider replacing the wildcard permissions with more specific ones based on your actual usage.
Previous verification script failed due to syntax errors. Running a corrected script to verify specific Data Exchange API calls.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for specific Data Exchange API calls in the codebase rg --type-add 'code:*.{js,py,java,go,rb,cs,ts}' --type code 'dataexchange:[A-Z][a-z]+[A-Z][a-zA-Z]+' -g '!{node_modules,vendor}/**'Length of output: 269
Script:
#!/bin/bash # Search for specific Data Exchange API calls in the codebase rg --type-add 'code:*.{js,py,java,go,rb,cs,ts}' --type code 'dataexchange:[A-Z][a-z]+[A-Z][a-zA-Z]+' -g '!node_modules/**' -g '!vendor/**'Length of output: 704
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (1)
318-332: New permission for managing SAP-specific tags on EBS volumesThis new statement allows the creation and deletion of SAP-specific tags on EBS volumes, which is beneficial for managing SAP resources. However, unlike the EC2 instance tagging policy, there's no condition to check if the volume is already managed by SSM for SAP.
Consider adding a condition similar to the EC2 instance tagging policy to ensure only volumes already associated with SAP are affected. This would maintain consistency and prevent unintended modifications to non-SAP volumes.
📜 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 (58)
- 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/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/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.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 (1 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/AWSSupportPlansFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 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 (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.json (1 hunks)
- docs/source/_static/managed-policies/AmazonECS_FullAccess.json (8 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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 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 (43)
- 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/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.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/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.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/AmazonEC2RolePolicyForLaunchWizard.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/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
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
🔇 Additional comments (73)
docs/source/_static/managed-policies/AWSServiceRoleForProcurementInsightsPolicy.json (2)
1-17: Policy structure looks good.The overall structure of the AWSServiceRoleForProcurementInsightsPolicy follows the standard AWS IAM policy format. It includes the correct version and a well-structured statement.
5-11: Permissions look appropriate, but verify completeness.The granted permissions (DescribeAccount, DescribeOrganization, ListAccounts) are read-only and align with what a Procurement Insights service would need. They allow gathering information about the AWS account, organization, and list of accounts, which is suitable for analysis purposes.
Please verify that these permissions are sufficient for the Procurement Insights service's requirements. If additional permissions are needed, they should be added to this policy.
docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (2)
37-43: Clarify the inclusion of AppStream access in this policyThe addition of the "AllowAppStreamAccess" statement grants read-only access to AppStream stacks. While this maintains the read-only nature of the policy, it's not immediately clear why AppStream access is included in a WorkSpaces Thin Client policy.
Could you please provide justification for including AppStream access in this policy? If it's intentional, consider updating the policy name or description to reflect this broader scope.
To verify if this is a common pattern, you can run:
#!/bin/bash # Description: Check for other policies that combine WorkSpaces and AppStream permissions # Test: Search for policies with both WorkSpaces and AppStream actions. Expect: Similar policies if this is a common pattern. rg '"Action":\s*\[(?s).*workspaces:.*appstream:.*\]' --type json
9-10: Verify the intended scope of the "AllowThinClientReadAccess" statementThe resource specification for this statement has been changed from a specific ARN format to a wildcard (
*). This modification broadens the scope of accessible resources under this policy.Please confirm if this expansion of scope is intentional and aligns with the principle of least privilege. If not, consider reverting to a more specific resource ARN.
To verify the impact, you can run the following command:
Also applies to: 13-13, 17-17
✅ Verification successful
Resource scope successfully updated
No instances of the original
arn:aws:thinclient:*:*:*patterns were found in the policy files, confirming that the resource scope has been appropriately broadened as intended.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for other occurrences of the original ARN pattern # Test: Search for the original ARN pattern. Expect: No other occurrences if the change is consistent. rg 'arn:aws:thinclient:\*:\*:\*' --type jsonLength of output: 66
Script:
#!/bin/bash # Description: Search for specific thinclient ARN patterns in JSON policy files # Test: Search for the original thinclient ARN pattern. Expect: No other occurrences if the change is consistent. rg '"Resource":\s*"arn:aws:thinclient:[^"]+"' --type jsonLength of output: 59
Script:
#!/bin/bash # Description: Verify absence of original thinclient ARN patterns in JSON policy files # Test: Search for any thinclient ARN patterns that might still be present. rg '"Resource"\s*:\s*"arn:aws:thinclient:[^"]+"' --type jsonLength of output: 62
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (7)
5-11: Approve with clarification: Broad resource scope for ConnectCampaignAccessThe new statement allows listing campaigns across all resources, which seems appropriate for a service-linked role. However, the use of "*" for the Resource field grants this permission broadly.
Could you please confirm if this broad scope is necessary for the service-linked role's functionality? If possible, consider restricting the resource scope to specific AWS regions or accounts.
13-22: Approve: Enhanced ConnectAccess permissionsThe updated statement appropriately adds permissions for describing contact flows and sending outbound emails, which align with the Connect service's functionality. The resource scope is correctly limited to Connect instances.
24-35: Approve: Secure EventBridge rule listingThis new statement grants permission to list EventBridge rules while implementing a security best practice by restricting access to the resource account of the principal. This ensures that the role can only list rules within its own account.
37-52: Approve: Well-scoped EventBridge rule managementThis statement provides necessary permissions for managing EventBridge rules related to Connect Campaigns. The resource scope is appropriately limited, and the conditions ensure that the role can only manage rules in its own account and those managed by connect-campaigns.amazonaws.com. This demonstrates good security practices.
54-65: Approve: Secure EventBridge target listingThis statement grants permission to list targets for EventBridge rules related to Connect Campaigns. The resource scope is appropriately limited, and the condition ensures that the role can only list targets for rules in its own account. This aligns with the principle of least privilege.
67-78: Approve with clarification: Broad resource scope for Wisdom actionsThis statement grants permissions for AWS Wisdom actions on resources tagged for Amazon Connect Campaigns. The use of resource tags for access control is a good practice. However, the resource scope is set to "*", which is very broad.
Could you please confirm if this broad scope is necessary for the service-linked role's functionality with AWS Wisdom? If possible, consider restricting the resource scope to specific AWS Wisdom resource types or ARNs.
Line range hint
1-81: Summary: Comprehensive update to Amazon Connect Campaigns Service Linked Role policyThis update enhances the capabilities of the Amazon Connect Campaigns Service Linked Role by introducing new permissions for EventBridge rule management and AWS Wisdom interactions. The changes generally follow security best practices, including the use of resource-specific ARNs and conditions to limit scope.
However, there are two instances where the resource scope is set to "*":
- The "ConnectCampaignAccess" statement (lines 5-11)
- The "AllowWisdomForConnectCampaignsEnabledTaggedResources" statement (lines 67-78)
While these broad scopes may be necessary for the service-linked role's functionality, it would be beneficial to have confirmation and justification for these decisions.
Overall, the policy update aligns with the PR objectives and improves the role's ability to manage Connect Campaigns effectively.
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (5)
66-70: LGTM: Appropriate additions for ECS, ECR, and Savings PlansThe newly added actions for ECS, ECR, and Savings Plans are appropriate for a compromised key quarantine policy:
- Preventing the creation of ECS services, clusters, and task definitions limits the potential for abuse in container deployments.
- Denying the creation of Savings Plans prevents financial commitments that could be exploited.
- Blocking ECR authentication token retrieval helps prevent unauthorized access to container images.
These additions enhance the security posture of the quarantine policy.
71-75: LGTM: Comprehensive protection for Amazon BedrockThe newly added Bedrock actions provide comprehensive protection against potential misuse of AI/ML resources:
- Preventing model invocations and creation of invocation jobs limits unauthorized use of AI models.
- Blocking the creation of foundation model agreements and entitlements prevents potential financial and resource commitments.
These additions effectively extend the quarantine policy to cover Amazon Bedrock services.
66-95: Overall assessment: Strengthened quarantine policy with minor adjustments neededThe updates to the AWSCompromisedKeyQuarantineV2 policy significantly enhance its coverage across various AWS services, effectively preventing potential abuse of compromised credentials. The additions align well with the policy's purpose by denying actions that could lead to resource creation, data exfiltration, or escalation of privileges.
Key strengths:
- Comprehensive coverage of new services like Amazon Bedrock.
- Preventing resource creation in critical services like ECS, S3, and SageMaker.
- Blocking potential financial commitments through Savings Plans.
Recommended adjustments:
- Reconsider the inclusion of read-only actions, particularly for S3, SES, STS, IAM, Lambda, and SNS. These might be valuable for incident response teams during investigation.
Final recommendation: Approve the changes with the suggested modifications to read-only actions. This will maintain the strong security posture while ensuring that incident response capabilities are not unnecessarily hindered.
90-95: LGTM for most additions, reconsider some read-only actionsThe additions for IAM destructive actions and MediaPackage are appropriate:
- Preventing the deletion of IAM roles and access keys helps maintain access controls during an incident.
- Blocking the creation of new MediaPackage channels aligns with the quarantine policy.
However, consider the following:
- "iam:ListUsers" is a read-only operation that could be useful for security teams during incident response.
- "lambda:GetEventSourceMapping" and "sns:GetSMSAttributes" are also read-only actions that don't modify resources or escalate privileges.
Recommendation: Consider removing the following read-only actions from the deny list to facilitate incident response activities:
- "iam:ListUsers"
- "lambda:GetEventSourceMapping"
- "sns:GetSMSAttributes"
To verify the potential impact, you can run the following command to check if these read-only actions are commonly allowed in other IAM policies:
#!/bin/bash # Check for IAM, Lambda, and SNS read actions in other policies rg -i '(iam:ListUsers|lambda:GetEventSourceMapping|sns:GetSMSAttributes)' docs/source/_static/managed-policies/ --type json
82-89: Approve resource creation preventions, query inclusion of read-only actionsThe additions for Amplify, CodeBuild, and Glue are appropriate:
- Preventing the creation of new deployments, environments, projects, and jobs aligns with the quarantine policy's purpose.
However, the inclusion of certain read-only actions raises questions:
- SES actions ("GetSendQuota", "ListIdentities") and STS actions ("GetSessionToken", "GetFederationToken") don't modify resources or escalate privileges.
- Denying these actions might hinder incident response efforts by restricting access to potentially useful information.
Recommendation: Consider removing the following read-only actions from the deny list unless there's a compelling reason for their inclusion:
- "ses:GetSendQuota"
- "ses:ListIdentities"
- "sts:GetSessionToken"
- "sts:GetFederationToken"
To verify the potential impact, you can run the following command to check if these read-only actions are commonly allowed in other IAM policies:
#!/bin/bash # Check for SES and STS read actions in other policies rg -i '(ses:(GetSendQuota|ListIdentities)|sts:(GetSessionToken|GetFederationToken))' docs/source/_static/managed-policies/ --type jsondocs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (9)
Line range hint
27-47: Well-scoped permissions with good security practices.The "DataExchangeJobsActions" statement provides specific permissions for managing Data Exchange jobs. The use of a condition to restrict job types is a commendable security practice, ensuring that only approved job types can be created, started, or canceled. This approach aligns well with the principle of least privilege.
Line range hint
49-61: Good use of conditional access for S3.This statement demonstrates good security practices by:
- Limiting the S3 action to just GetObject.
- Restricting the resource to buckets containing "aws-data-exchange" in the name.
- Using a condition to ensure the action is only allowed when called via the Data Exchange service.
These measures help to maintain the principle of least privilege while still allowing necessary operations.
Line range hint
62-77: Effective use of tags and conditions for S3 access control.This statement demonstrates good security practices by using tags and conditions to control S3 access:
- The S3:GetObject action is allowed only on objects tagged with "AWSDataExchange: true".
- The action must be called via the Data Exchange service.
These conditions provide fine-grained access control. However, note that the Resource is set to "*". While this is mitigated by the conditions, ensure that this broad resource specification aligns with your security requirements.
Line range hint
78-93: Well-controlled S3 write permissions.This statement demonstrates good security practices for S3 write operations:
- It limits the actions to specific write operations (PutObject and PutObjectAcl).
- It restricts the resource to buckets containing "aws-data-exchange" in the name.
- It uses a condition to ensure the actions are only allowed when called via the Data Exchange service.
These measures provide a good balance between functionality and security, adhering to the principle of least privilege.
Line range hint
134-162: Well-scoped Redshift and API Gateway permissions.These statements demonstrate good security practices:
Redshift permissions:
- The "RedshiftConditionalActions" statement uses a condition to ensure the consumer identifier is "ADX", which is a good security measure.
- The "RedshiftActions" statement is limited to specific describe actions.
API Gateway permission:
- Limited to GET actions only, which is appropriate for read-only access.
While all these statements use "*" for the Resource, the specific actions and conditions provide good control. The Redshift permissions, in particular, show excellent use of conditions to limit the scope of the permissions.
Line range hint
1-164: Overall assessment: Well-crafted policy with room for potential tighteningThis AWSDataExchangeProviderFullAccess policy provides comprehensive permissions necessary for AWS Data Exchange providers. The policy demonstrates several good security practices:
- Use of specific actions rather than wildcard permissions where possible.
- Implementation of conditions to restrict permissions, particularly in S3 and Redshift statements.
- Limiting resources to those related to Data Exchange where feasible.
However, there are areas where the policy could potentially be tightened:
- Some statements use "*" for the Resource, which, while sometimes necessary, should be reviewed to ensure it aligns with the principle of least privilege.
- Consider adding more conditions to statements that currently have none, especially for broad permissions like S3 read actions and AWS Marketplace actions.
Recommendations:
- Review each permission to ensure it's necessary for your specific use case.
- Where possible, limit resources to specific ARNs or patterns related to Data Exchange.
- Consider adding more conditions to restrict when and how permissions can be used.
- Regularly review and update this policy as your Data Exchange provider requirements evolve.
Line range hint
104-123: Comprehensive AWS Marketplace permissions - verify necessity.This statement grants a wide range of AWS Marketplace permissions, which may be necessary for a Data Exchange provider. However, consider the following:
- Verify that all these permissions are indeed required for your use case.
- The Resource is set to "*", allowing these actions on all AWS Marketplace resources.
- There are no conditions to restrict these actions.
If possible, consider adding conditions to limit when these actions can be performed, aligning with the principle of least privilege.
To assess the necessity of these permissions, you can run the following command to check for usage of these AWS Marketplace actions in your Data Exchange related code:
#!/bin/bash # Search for AWS Marketplace API calls in Data Exchange related code rg --type-add 'code:*.{js,py,java,go,rb,cs,ts}' --type code 'aws-marketplace\.[A-Z][a-z]+[A-Z][a-zA-Z]+' -g '*dataexchange*' -g '!{node_modules,vendor}/**'If this search returns limited results, consider removing unused permissions to tighten security.
Line range hint
94-103: Broad S3 read permissions - consider tightening.While the permissions granted are specific to S3 read actions, which is good, there are some potential security concerns:
- The Resource is set to "*", allowing these actions on all S3 resources in the account.
- There are no conditions to restrict these actions.
This could potentially allow listing of all buckets in the account, which might be broader than necessary.
Consider if it's possible to restrict these permissions further, perhaps by:
- Limiting the Resource to specific buckets or a bucket naming pattern.
- Adding a condition to ensure these actions are only performed in the context of Data Exchange operations.
To assess the impact of these broad permissions, you can run the following command to check for any existing use of these S3 actions in your Data Exchange related code:
#!/bin/bash # Search for specific S3 API calls in Data Exchange related code rg --type-add 'code:*.{js,py,java,go,rb,cs,ts}' --type code 's3\.(GetBucketLocation|ListBucket|ListAllMyBuckets)' -g '*dataexchange*' -g '!{node_modules,vendor}/**'If this search returns no results or only limited results, consider tightening these permissions.
Line range hint
124-133: KMS read permissions - consider tightening if possible.This statement grants KMS read permissions, which may be necessary for Data Exchange operations. However, consider the following:
- The Resource is set to "*", allowing these actions on all KMS resources.
- There are no conditions to restrict when these actions can be performed.
If possible, consider:
- Limiting the Resource to specific KMS keys used by Data Exchange.
- Adding conditions to ensure these actions are only performed in the context of Data Exchange operations.
To assess the necessity and scope of these KMS permissions, you can run the following command:
#!/bin/bash # Search for KMS API calls in Data Exchange related code rg --type-add 'code:*.{js,py,java,go,rb,cs,ts}' --type code 'kms\.(DescribeKey|ListAliases|ListKeys)' -g '*dataexchange*' -g '!{node_modules,vendor}/**'If this search returns limited results or shows usage with specific key IDs, consider tightening these permissions to those specific keys.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (5)
80-87: LGTM: Enhanced Customer Profiles capabilitiesThe new permissions added to the "AllowCustomerProfilesForConnectDomain" statement significantly expand the capabilities for managing customer profiles and segmentation. These additions include:
- Listing integrations and segment definitions
- Listing profile attribute values
- Creating and getting segment estimates
- Batch operations for profiles and calculated attributes
- Getting segment membership
These enhancements align well with the PR objectives and provide more granular control over customer profile data.
96-97: LGTM: Added permission to list object type attributesThe addition of the "profile:ListObjectTypeAttributes" permission to the "AllowReadPermissionForCustomerProfileObjects" statement enhances the read capabilities for Customer Profile objects. This new permission allows listing attributes of object types, which complements the existing abilities to list profile objects and get profile object types. This change provides more comprehensive access to profile object metadata.
149-163: LGTM: Expanded Wisdom capabilities for message template managementThe "AllowWisdomForConnectEnabledTaggedResources" statement has been significantly enhanced with new permissions for managing message templates in Amazon Connect Wisdom. These additions allow for:
- Creating, updating, and deleting message templates
- Managing message template metadata and versions
- Activating and deactivating templates
- Creating and deleting template attachments
- Rendering message templates
These changes align well with the PR objectives and are properly scoped to tagged resources, maintaining security best practices.
As noted in a previous review comment, please ensure that the project documentation is updated to reflect these new Wisdom message template capabilities.
195-208: LGTM: New permissions for Customer Profiles segmentationA new statement "AllowCustomerProfilesSegmentationForConnectDomain" has been added to the policy. This statement introduces permissions for managing segment definitions and snapshots in Customer Profiles, including:
- Creating, getting, and deleting segment definitions
- Creating and getting segment snapshots
These new permissions enhance the segmentation capabilities for Customer Profiles within the Amazon Connect domain. The statement is properly scoped to the Connect domain resources, maintaining security best practices.
This addition aligns well with the PR objectives and complements the existing Customer Profiles permissions in the policy.
Line range hint
1-258: Summary: Comprehensive update to AmazonConnectServiceLinkedRolePolicyThis update to the AmazonConnectServiceLinkedRolePolicy significantly enhances the capabilities for Amazon Connect, particularly in the areas of Customer Profiles and Wisdom services. Key improvements include:
- Expanded Customer Profiles permissions for managing profiles, segmentation, and object attributes.
- New Wisdom permissions for comprehensive message template management.
- Addition of a new statement for Customer Profiles segmentation operations.
These changes align well with the PR objectives of updating AWS managed policies. The new permissions are properly scoped and maintain security best practices.
To ensure these policy changes are properly reflected in the codebase and documentation:
If the script doesn't find any relevant documentation updates, consider updating the project documentation to reflect these new capabilities in Customer Profiles and Wisdom services.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (10)
Line range hint
128-137: Appropriate SSM parameter access for ECS.The "SSMPolicy" statement provides read-only access to ECS-related SSM parameters. This is a well-scoped policy that follows the principle of least privilege by limiting access to only the necessary resources.
Line range hint
138-155: Well-scoped cleanup policy for ECS CloudFormation resources.The "ManagedCloudformationResourcesCleanupPolicy" allows deletion of specific EC2 resources, but with a condition that limits it to resources tagged with ECS-related CloudFormation stack names. This is a good use of conditions to ensure only relevant resources can be affected.
Line range hint
156-168: Appropriate PassRole policy for ECS tasks.The "TasksPassRolePolicy" allows passing IAM roles to ECS tasks. While it uses a broad resource ("*"), the condition appropriately limits this to the ECS tasks service. This is necessary for ECS functionality and follows good security practices.
169-180: Well-scoped PassRole policy for ECS infrastructure.The "InfrastructurePassRolePolicy" is highly specific, allowing only the ecsInfrastructureRole to be passed to the ECS service. This adheres well to the principle of least privilege and is a good security practice.
Line range hint
181-197: Appropriate PassRole policy for ECS instances.The "InstancePassRolePolicy" allows passing ECS instance roles to EC2 instances. The use of a wildcard in the role name provides flexibility, while the condition appropriately limits this to EC2 services. This policy is well-scoped for its purpose.
Line range hint
198-213: Well-scoped PassRole policy for ECS auto-scaling.The "AutoScalingPassRolePolicy" allows passing ECS auto-scaling roles to the application auto-scaling service. The policy is appropriately scoped with a specific role prefix and service condition, following good security practices while providing necessary flexibility.
Line range hint
214-230: Extended service-linked role creation policy.The "ServiceLinkedRoleCreationPolicy" has been updated to include additional services related to auto-scaling and spot instances. This expansion allows for more comprehensive management of ECS and its related services while maintaining appropriate limitations through service-specific conditions.
Line range hint
231-248: Well-structured ELB tagging policy for ECS resources.The "ELBTaggingPolicy" allows adding tags to ELB resources during their creation for ECS-related operations. This policy follows good tagging practices by ensuring tags are added at resource creation time, which aids in resource management and identification.
Line range hint
1-249: Comprehensive update to AmazonECS_FullAccess policy with good security practices.This update to the AmazonECS_FullAccess policy introduces several new statements that enhance the management capabilities for ECS and its integrations. The changes cover a wide range of services and actions necessary for full ECS management, including auto-scaling, CloudFormation resource cleanup, role management, and ELB tagging.
While some statements use broad resource definitions, they are generally well-constrained by appropriate conditions, adhering to good security practices. This update strikes a good balance between providing the necessary permissions for full ECS management and maintaining principle of least privilege where possible.
Key improvements include:
- Comprehensive ECS integrations management
- Specific SSM parameter access for ECS
- Targeted cleanup of ECS-related CloudFormation resources
- Well-scoped PassRole policies for various ECS-related roles
- Extended service-linked role creation capabilities
- Structured ELB tagging policy for better resource management
Overall, these changes align well with the "FullAccess" nature of the policy while maintaining good security practices.
Line range hint
5-127: Comprehensive ECS integration management policy added.This new policy statement, "ECSIntegrationsManagementPolicy", grants extensive permissions across multiple AWS services related to ECS integrations. While this is expected for a FullAccess policy, it's important to note the broad scope of permissions granted, including the use of "*" for the Resource field.
To ensure this policy aligns with the intended use case, please run the following command to check for any overly permissive actions:
✅ Verification successful
ECSIntegrationsManagementPolicy permissions are appropriate.
The ECSIntegrationsManagementPolicy grants the necessary permissions across multiple AWS services consistent with a FullAccess policy. No overly permissive actions were identified beyond the expected scope.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any potentially overly permissive actions in the ECSIntegrationsManagementPolicy jq -r '.Statement[] | select(.Sid == "ECSIntegrationsManagementPolicy") | .Action[]' docs/source/_static/managed-policies/AmazonECS_FullAccess.json | grep -E ':(Delete|Modify|Update|Create)'Length of output: 1378
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (4)
Line range hint
120-126: Improved security through tighter resource scopeThe update to the
ResourceARN for theiam:CreateServiceLinkedRoleaction enhances security by specifying a more precise target. This change aligns with the principle of least privilege, reducing the potential attack surface.
276-297: New permission for managing SAP-specific resource groupsThis new statement allows the creation and tagging of resource groups specifically for Systems Manager for SAP. The conditions ensure that only authorized resource groups are created, enhancing control and organization of SAP-related resources.
299-316: New permission for managing SAP-specific tags on EC2 instancesThis new statement allows the creation and deletion of SAP-specific tags on EC2 instances. The conditions ensure that only instances already managed by SSM for SAP are affected, maintaining proper scope and preventing unintended modifications to non-SAP instances.
334-350: New permission for managing application tags on EBS volumesThis new statement allows the creation and deletion of application-specific tags on EBS volumes. The conditions ensure that only authorized application tags are managed, providing better control and organization of application-related resources across EBS volumes.
docs/source/_static/managed-policies/AWS_ConfigRole.json (8)
32-43: LGTM: Enhanced AOSS monitoring capabilitiesThese new permissions for Amazon OpenSearch Service (AOSS) expand AWS Config's ability to monitor and assess AOSS resources. The added operations (BatchGet, Get, and List) are read-only, which aligns with the principle of least privilege. This change enhances AWS Config's coverage and ability to provide compliance and configuration assessment for AOSS resources.
89-89: LGTM: Added AppStream monitoring capabilityThe addition of "appstream:DescribeAppBlockBuilders" permission allows AWS Config to monitor AppStream AppBlockBuilders, enhancing its coverage of AppStream resources.
136-137: LGTM: Enhanced AWS Backup monitoring capabilitiesThese new permissions for AWS Backup allow AWS Config to monitor restore testing plans and selections. This addition enhances AWS Config's ability to assess the configuration and compliance of AWS Backup resources, particularly in the context of disaster recovery readiness.
Also applies to: 144-145
185-185: LGTM: Added CloudTrail Channel monitoring capabilitiesThe addition of "cloudTrail:GetChannel" and "cloudTrail:ListChannels" permissions allows AWS Config to monitor CloudTrail Channels. This enhances AWS Config's ability to assess the configuration and compliance of CloudTrail resources, providing better visibility into log delivery mechanisms.
Also applies to: 189-189
354-354: LGTM: Added EC2 VPC Endpoint monitoring capabilityThe addition of "ec2:DescribeVpcEndpoints" permission allows AWS Config to monitor EC2 VPC Endpoints, enhancing its coverage of EC2 networking resources and configurations.
568-568: LGTM: Comprehensive expansion of monitoring capabilities across multiple servicesThis set of changes significantly enhances AWS Config's monitoring capabilities across a wide range of AWS services, including:
- Glue: Added permissions for triggers
- ImageBuilder: Added permissions for lifecycle policies
- IoT: Extended permissions for billing groups
- IVS: New permissions for encoder configurations, playback restriction policies, stages, and storage configurations
- MediaConnect: Added permissions for bridges and gateways
- MediaTailor: New permissions for channels, live sources, source locations, and VOD sources
- Omics: Added permissions for workflows
These additions allow AWS Config to provide more comprehensive configuration and compliance assessments across the AWS ecosystem. All new permissions are read-only, adhering to the principle of least privilege.
Also applies to: 574-574, 659-659, 669-669, 676-676, 693-693, 769-774, 777-782, 905-910, 917-926, 970-971
1308-1308: LGTM: Added SSM SAP tag monitoring capabilityThe addition of "ssm-sap:ListTagsForResource" permission allows AWS Config to monitor tags for SSM SAP resources. This enhances AWS Config's ability to track and assess the tagging strategy for SAP-related resources managed through AWS Systems Manager.
Line range hint
1-1399: Summary: Comprehensive update enhancing AWS Config's monitoring capabilitiesThis update to the AWS Config role policy significantly expands its ability to monitor and assess resources across a wide range of AWS services. Key points:
- All new permissions are read-only, adhering to the principle of least privilege.
- The changes cover various services including AOSS, AppStream, AWS Backup, CloudTrail, EC2, Glue, ImageBuilder, IoT, IVS, MediaConnect, MediaTailor, Omics, and SSM SAP.
- These additions will enable more comprehensive configuration and compliance assessments in AWS Config.
The changes align well with the PR objective of updating AWS managed policies and should improve AWS Config's overall functionality without introducing security risks.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (5)
32-43: Approval: New permissions for Amazon OpenSearch Service (AOSS) addedThese new permissions allow AWS Config to interact with Amazon OpenSearch Service (AOSS). This addition enhances AWS Config's ability to monitor, audit, and report on OpenSearch resources, including collections, lifecycle policies, VPC endpoints, access policies, and security configurations. This change improves the service's capability to provide comprehensive configuration management for AOSS resources.
135-136: Approval: Enhanced AWS Backup monitoring capabilitiesThe new permissions for AWS Backup allow AWS Config to access information about restore testing plans and selections. This addition is crucial for enabling AWS Config to monitor and report on backup restoration capabilities. These permissions enhance the service's ability to provide insights into disaster recovery readiness and compliance with backup policies, which are critical aspects of a robust cloud infrastructure.
Also applies to: 143-144
88-88: Approval: Expanded monitoring capabilities for AppStream, Glue, and OmicsThese new permissions enhance AWS Config's ability to monitor and report on resources across different services:
- AppStream: Allows describing app block builders, improving visibility into application streaming resources.
- Glue: Enables getting and listing triggers, enhancing monitoring of ETL workflows.
- Omics: Permits getting and listing workflows, allowing tracking of genomics and bioinformatics processes.
These additions contribute to a more comprehensive configuration management and compliance monitoring across a wider range of AWS services.
Also applies to: 566-566, 572-572, 968-969
767-772: Approval: Enhanced monitoring for AWS Interactive Video Service (IVS)The new permissions for AWS Interactive Video Service (IVS) significantly expand AWS Config's ability to monitor and report on live streaming setups. These additions allow for:
- Managing encoder configurations
- Overseeing playback restriction policies
- Monitoring stages in the streaming process
- Tracking storage configurations for streaming content
These permissions are crucial for ensuring compliance, maintaining security, and providing comprehensive oversight of streaming infrastructure configurations. This enhancement will help organizations better manage their live streaming resources and ensure they adhere to best practices and regulatory requirements.
Also applies to: 775-780
903-908: Approval: Expanded monitoring for MediaConnect, MediaTailor, and Scheduler servicesThese new permissions enhance AWS Config's capabilities in the following areas:
- MediaConnect: Allows describing and listing bridges and gateways, improving visibility into media transfer workflows.
- MediaTailor: Enables describing and listing channels, live sources, source locations, and VOD sources, enhancing monitoring of video streaming and ad insertion processes.
- Scheduler: Permits getting and listing schedules, allowing better tracking of scheduled tasks and workflows.
These additions significantly improve AWS Config's ability to monitor and report on media streaming infrastructure and scheduled operations. This enhanced visibility will help organizations maintain better control over their media workflows and ensure proper configuration and compliance of these critical services.
Also applies to: 915-924, 1254-1255
docs/source/_static/managed-policies/ReadOnlyAccess.json (9)
111-111: Approved: Consistent read-only permission addedThe addition of "application-signals:ListServices" is appropriate for a ReadOnlyAccess policy as it only allows listing services, which is a read operation.
222-225: Approved: Consistent read-only permissions added for bedrock serviceThe additions of various "bedrock:Get*" and "bedrock:List*" permissions are appropriate for a ReadOnlyAccess policy. These operations allow read-only access to bedrock resources, which aligns with the policy's intent.
Also applies to: 239-242
275-275: Approved: Consistent read-only permission added for budgets serviceThe addition of "budgets:ListTagsForResource" is appropriate for a ReadOnlyAccess policy as it only allows listing tags, which is a read operation.
303-303: Approved: Consistent read-only permission added for Cost Explorer serviceThe addition of "ce:ListCostAllocationTags" is appropriate for a ReadOnlyAccess policy as it only allows listing cost allocation tags, which is a read operation.
318-328: Approved: Consistent read-only permissions added for cleanrooms-ml serviceThe additions of various "cleanrooms-ml:Get*" and "cleanrooms-ml:List*" permissions are appropriate for a ReadOnlyAccess policy. These operations allow read-only access to cleanrooms-ml resources, which aligns with the policy's intent.
906-906: Approved: Consistent read-only permission added for Glue serviceThe addition of "glue:GetTables" is appropriate for a ReadOnlyAccess policy as it only allows retrieving table information from Glue, which is a read operation.
1922-1938: Approved: Consistent read-only permissions added for s3-outposts serviceThe additions of various "s3-outposts:Get*" and "s3-outposts:List*" permissions are appropriate for a ReadOnlyAccess policy. These operations allow read-only access to s3-outposts resources, which aligns with the policy's intent.
Line range hint
1096-1157: Approved: Consistent read-only permissions added for multiple servicesThe additions of various Get*, List*, and Describe* permissions for services including iotwireless, ivs, lex, qbusiness, resiliencehub, securityhub, ssm-sap, trustedadvisor, and user-subscriptions are all appropriate for a ReadOnlyAccess policy. These operations allow read-only access to resources, which aligns with the policy's intent.
Also applies to: 1143-1150, 1279-1284, 1741-1759, 1842-1857, 1973-1974, 2072-2082, 2165-2172, 2173-2175
Line range hint
1-2175: Summary: ReadOnlyAccess policy updates are appropriate and maintain policy intentAfter reviewing all additions to the ReadOnlyAccess policy, I can confirm that:
- All new permissions are read-only operations (Get*, List*, Describe*, etc.).
- The additions cover a wide range of AWS services, both new and existing.
- No write or modify permissions were introduced.
These updates appropriately expand the policy's coverage to ensure comprehensive read-only access across the growing AWS ecosystem. The changes are consistent with the policy's original intent and reflect the evolution of AWS services.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (7)
87-88: New permissions enhance regional and autoscaling diagnosticsThe following new permissions have been added:
account:getRegionOptStatusandaccount:listRegions: These allow the support role to query region-specific information, which can be crucial for diagnosing region-related issues.autoscaling:describeTrafficSources: This provides more detailed information about traffic sources for autoscaling groups, enabling better support for autoscaling-related problems.These additions are appropriate for the AWS Support Service Role, as they enhance its capability to provide comprehensive support across regions and for autoscaling services.
Also applies to: 264-264
1018-1018: New EC2 permissions enhance support for snapshots and subnetsTwo new EC2 permissions have been added to the policy:
ec2:describeSnapshotTierStatus: This allows the support role to retrieve information about the storage tier and restoration status of EBS snapshots.ec2:getSubnetCidrReservations: This enables the role to view CIDR reservations for subnets in a VPC.These additions are appropriate for the AWS Support Service Role, as they provide more detailed insights into EC2 resources, specifically EBS snapshots and VPC subnets. This can be crucial for diagnosing issues related to storage and networking in EC2 environments.
Also applies to: 1064-1064
1143-1144: New EKS permissions for pod identity managementTwo new Amazon EKS (Elastic Kubernetes Service) permissions have been added to the policy:
eks:describePodIdentityAssociationeks:listPodIdentityAssociationsThese permissions allow the AWS Support Service Role to retrieve information about pod identity associations in EKS clusters. Pod identity associations are likely related to managing access and permissions for pods in Kubernetes, which is crucial for security and resource management.
The addition of these permissions is appropriate as they enhance the support role's ability to diagnose and troubleshoot issues related to pod identity and access management in EKS environments.
1210-1212: New permissions for ELB trust stores and FreeTier usageNew permissions have been added for Elastic Load Balancing (ELB) and FreeTier services:
Elastic Load Balancing:
elasticloadbalancing:describeTrustStoreselasticloadbalancing:describeTrustStoreAssociationselasticloadbalancing:describeTrustStoreRevocationsThese permissions allow the support role to retrieve information about trust stores, which are likely related to SSL/TLS certificate management for load balancers. This addition enhances the role's ability to troubleshoot issues related to HTTPS listeners and SSL/TLS configurations.
FreeTier:
freetier:getFreeTierUsageThis permission enables the support role to check the usage of services against AWS Free Tier limits. This can be helpful in assisting customers with understanding their usage and potential charges as they transition from the free tier.
These additions are appropriate for the AWS Support Service Role, as they provide capabilities to assist with load balancer security configurations and account usage inquiries.
Also applies to: 1343-1343
547-558: New CodeConnections permissions enhance CI/CD support capabilitiesThe policy now includes new permissions for the CodeConnections service:
getConnection,listConnectionsgetHost,listHostsgetRepositoryLink,listRepositoryLinksgetRepositorySyncStatus,getResourceSyncStatusgetSyncBlockerSummary,getSyncConfiguration,listSyncConfigurationsThese additions enhance the role's ability to support and troubleshoot CI/CD workflows, particularly those involving AWS CodePipeline and related services. This expansion of capabilities is generally appropriate for a support role.
To ensure these permissions are necessary and properly scoped, please run the following script:
This script will help you verify if the new CodeConnections permissions are justified based on your current usage and support needs.
✅ Verification successful
CodeConnections permissions are appropriately scoped and utilized
The review of the new CodeConnections permissions indicates that these permissions are already in use across multiple policies and codebase components. The added permissions align with existing usages, ensuring that the role has the necessary access without granting excessive privileges.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Analyze CodeConnections usage and permissions # List CodeConnections permissions in the policy echo "CodeConnections permissions in the policy:" jq -r '.Statement[].Action[]' AWSSupportServiceRolePolicy.json | grep "^codeconnections:" | sort # Check for existing CodeConnections resources echo "Existing CodeConnections resources:" aws codeconnections list-connections aws codeconnections list-hosts aws codeconnections list-repository-links echo "Review the output to confirm that the granted permissions align with your CodeConnections resource usage and support requirements."Length of output: 826
Script:
#!/bin/bash # Description: Extract CodeConnections permissions and search codebase for their usage # Extract CodeConnections permissions from the policy echo "CodeConnections permissions in the policy:" jq -r '.Statement[].Action[]' docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json | grep "^codeconnections:" | sort # Search the codebase for usage of CodeConnections echo "Searching codebase for 'codeconnections' usage:" rg "codeconnections"Length of output: 15538
786-802: New Deadline permissions enhance render farm support capabilitiesThe policy now includes new permissions for the AWS Thinkbox Deadline service:
listAvailableMeteredProducts,listMeteredProductslistBudgets,listFarms,listFleetslistJobMembers,listJobslistMonitors,listWorkers- Various other list operations for Deadline-specific resources
These additions enhance the role's ability to support and troubleshoot render farm operations using AWS Thinkbox Deadline. This expansion of capabilities is generally appropriate for a support role dealing with media and entertainment workloads.
To ensure these permissions are necessary and properly scoped, please run the following script:
This script will help you verify if the new Deadline permissions are justified based on your current usage of render farm resources and support needs.
✅ Verification successful
New Deadline permissions verified and approved
The added
deadline:permissions are present and utilized across multiple parts of the codebase, ensuring they are necessary for the application's functionality:
Policy Files:
AWSSupportServiceRolePolicy.jsonAWSThinkboxDeadlineCloud-WorkerHost.jsonAWSThinkboxDeadlineUserAccessQueues.json- ...and others listed in the search results.
Codebase References:
stats/serviceslib/generated/policy-statements/deadlinecloud.tslib/generated/aws-managed-policies/iam-floyd.ts- ...and other relevant files.
These permissions are appropriately scoped to support AWS Thinkbox Deadline services within your render farm operations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Analyze Deadline usage and permissions # List Deadline permissions in the policy echo "Deadline permissions in the policy:" jq -r '.Statement[].Action[]' AWSSupportServiceRolePolicy.json | grep "^deadline:" | sort # Check for existing Deadline resources (Note: Deadline might not have a direct AWS CLI command, so we'll check for related services) echo "Checking for Deadline-related resources:" aws ec2 describe-instances --filters "Name=tag-key,Values=DeadlineGroupName" --query "Reservations[*].Instances[*].[InstanceId,Tags[?Key=='DeadlineGroupName']]" --output text echo "Review the output to confirm that the granted Deadline permissions align with your render farm usage and support requirements."Length of output: 826
Script:
#!/bin/bash # Description: Search the codebase for Deadline references to verify permission usage echo "Searching for 'deadline' references in the codebase..." rg -i 'deadline' --files-with-matches echo "Review the listed files to ensure that the 'deadline:' permissions are justified based on actual code usage."Length of output: 1874
Line range hint
1-3374: Comprehensive policy expansion requires careful reviewThis update to the AWSSupportServiceRolePolicy significantly broadens the AWS Support Service Role's access across various services:
- New services: Bedrock, CodeConnections, Deadline, FreeTier
- Expanded access: EC2, EKS, Elastic Load Balancing, and others
While these additions enhance support capabilities, they also increase the policy's complexity and potential attack surface. Recommendations:
- Implement a regular review process (e.g., quarterly) to assess the necessity of each permission.
- Consider using AWS Access Analyzer to identify unused permissions that could be removed.
- Maintain documentation justifying the need for each group of permissions.
To assist in ongoing management of this policy, run the following script periodically:
This script generates and fetches a report on the last accessed services for this policy, helping identify potentially unnecessary permissions.
| "s3:CreateBucket", | ||
| "s3:PutBucketCors", | ||
| "s3:GetObject", | ||
| "s3:ListBucket", | ||
| "sagemaker:CreateEndpointConfig", | ||
| "sagemaker:CreateProcessingJob", |
There was a problem hiding this comment.
💡 Codebase verification
LGTM for most additions, but some S3 actions need reconsideration
The additions for S3 and SageMaker are generally appropriate:
- Preventing the creation of S3 buckets and modifying CORS settings limits potential data exfiltration routes.
- Blocking SageMaker endpoint creation and processing jobs prevents abuse of ML resources.
However, the recent analysis shows that "s3:GetObject" and "s3:ListBucket" are extensively used across many managed policies. Denying these actions in this policy might hinder legitimate administrative and incident response tasks.
Suggestion: Remove "s3:GetObject" and "s3:ListBucket" from the deny list to facilitate necessary operations, unless there is a specific security concern that justifies their inclusion.
🔗 Analysis chain
LGTM for most additions, reconsider some S3 actions
The additions for S3 and SageMaker are generally appropriate:
- Preventing the creation of S3 buckets and modifying CORS settings limits potential data exfiltration routes.
- Blocking SageMaker endpoint creation and processing jobs prevents abuse of ML resources.
However, consider the following:
- Denying "s3:GetObject" and "s3:ListBucket" might hinder legitimate administrative tasks during incident response. These read-only operations could be useful for security teams investigating the compromise.
Suggestion: Remove "s3:GetObject" and "s3:ListBucket" from the deny list to facilitate incident response activities, unless there's a specific security concern that justifies their inclusion.
To verify the potential impact, you can run the following command to check if these S3 actions are commonly used in other IAM policies:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for S3 read actions in other policies
rg -i 's3:(GetObject|ListBucket)' docs/source/_static/managed-policies/ --type json
Length of output: 4190
Script:
#!/bin/bash
# Check for S3 read actions in other policies
rg -i 's3:(GetObject|ListBucket)' docs/source/_static/managed-policies/ --type json
Length of output: 47682
udondan
force-pushed
the
update-aws-managed-policies
branch
from
2107c74
to
8d8350a
Compare
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (5)
docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json (1)
12-12: Consider restricting the Resource scope for enhanced security.While using
"Resource": "*"is common for ECR policies, consider if a more restrictive scope is possible for your use case. This aligns with the principle of least privilege and can enhance security.If feasible, limit the policy to specific ECR repositories:
"Resource": [ "arn:aws:ecr:region:account-id:repository/repository-name" ]Replace
region,account-id, andrepository-namewith your specific values. If multiple repositories are needed, list them separately.docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (4)
Line range hint
5-25: LGTM with a suggestion for future improvementThe new "DataExchangeActions" statement provides comprehensive permissions for AWS Data Exchange operations, which aligns with the policy's full access intent. However, consider refining the permissions in the future for enhanced security:
- Replace wildcards (Get*, Update*, List*, Delete*) with specific actions to follow the principle of least privilege.
- If possible, scope the Resource to specific ARNs instead of "*" to limit the policy's reach.
Line range hint
94-102: LGTM with a suggestion for potential refinementThe "S3ReadActions" statement provides necessary permissions for listing S3 buckets and retrieving their locations. While these permissions are typically set globally as implemented here, consider if it's possible to scope them more narrowly for the specific needs of AWS Data Exchange. If feasible, limiting these actions to specific buckets or using conditions could further enhance the security posture.
Line range hint
104-122: LGTM with a suggestion for reviewThe "AWSMarketplaceActions" statement provides comprehensive permissions for interacting with AWS Marketplace, which is likely necessary for Data Exchange providers. However, it's worth reviewing if all these permissions are required for your specific use case. If possible, consider removing any unnecessary permissions to adhere to the principle of least privilege.
Line range hint
1-164: Overall LGTM - Comprehensive update with good security practicesThis update to the AWSDataExchangeProviderFullAccess policy significantly enhances its functionality to support various AWS services required for Data Exchange providers. The changes follow many AWS best practices, including:
- Use of conditions to limit the scope of permissions where possible.
- Specific action definitions for most services.
- Appropriate use of resource-level permissions where applicable.
For future iterations, consider the following recommendations to further enhance security:
- Review and potentially refine the broad S3 read permissions.
- Assess if all AWS Marketplace permissions are necessary for your use case.
- Where possible, replace wildcards with specific action names to adhere more strictly to the principle of least privilege.
These changes provide a solid foundation for AWS Data Exchange providers while maintaining a good security posture.
📜 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 (59)
- 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/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/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.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 (1 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/AWSSupportPlansFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 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 (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.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/AmazonECS_FullAccess.json (8 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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 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 (44)
- 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/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.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/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.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/AmazonEC2RolePolicyForLaunchWizard.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/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
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
🔇 Additional comments (77)
docs/source/_static/managed-policies/AmazonEC2ContainerRegistryPullOnly.json (1)
1-15: LGTM: Policy structure follows AWS best practices.The overall structure of the IAM policy is correct and adheres to AWS best practices. It includes the required "Version" and "Statement" fields, and the JSON format is valid.
docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (5)
Line range hint
1-45: Overall policy changes expand access while maintaining read-only natureThe updates to this policy introduce new read-only permissions for WorkSpaces, WorkSpaces Web, and AppStream services, which enhance the policy's functionality. These additions align with the policy's read-only purpose.
However, please note the following points:
- The Resource specification for the "AllowThinClientReadAccess" statement has been broadened to "*". Verify if this aligns with the principle of least privilege.
- Confirm that all newly added permissions are necessary for the policy's intended use.
To ensure these changes don't introduce unintended consequences, consider running a thorough policy simulation using AWS IAM Access Analyzer. This will help validate that the policy grants only the intended permissions across all affected services.
37-43: New AppStream access looks good, but verify necessityThe addition of the "AllowAppStreamAccess" statement granting permission to "appstream:DescribeStacks" aligns with the read-only nature of this policy.
Please confirm that this new access is required for the intended use of this policy. You can run the following script to check for related AppStream actions in the codebase:
#!/bin/bash # Description: Check for AppStream-related actions in the codebase # Test: Search for AppStream-related actions echo "Searching for AppStream-related actions:" rg '"appstream:' --type json
19-26: New WorkSpaces access looks good, but verify necessityThe addition of the "AllowWorkSpacesAccess" statement granting permission to "workspaces:DescribeWorkspaceDirectories" aligns with the read-only nature of this policy.
Please confirm that this new access is required for the intended use of this policy. You can run the following script to check for related WorkSpaces actions in the codebase:
#!/bin/bash # Description: Check for WorkSpaces-related actions in the codebase # Test: Search for WorkSpaces-related actions echo "Searching for WorkSpaces-related actions:" rg '"workspaces:' --type json
27-36: New WorkSpaces Web access looks good, but verify necessityThe addition of the "AllowWorkSpacesWebAccess" statement granting permissions to "workspaces-web:GetPortal", "workspaces-web:GetUserSettings", and "workspaces-web:ListPortals" aligns with the read-only nature of this policy.
Please confirm that these new accesses are required for the intended use of this policy. You can run the following script to check for related WorkSpaces Web actions in the codebase:
#!/bin/bash # Description: Check for WorkSpaces Web-related actions in the codebase # Test: Search for WorkSpaces Web-related actions echo "Searching for WorkSpaces Web-related actions:" rg '"workspaces-web:' --type json
9-10: Verify the intended scope of the "AllowThinClientReadAccess" statementThe Resource specification for this statement has been changed from a specific ARN format to a wildcard "*". This broadens the scope of accessible resources under this policy.
Please confirm if this change is intentional and aligns with the principle of least privilege. If a more restrictive scope is possible, consider using a specific ARN or a condition to limit access.
To verify the impact, you can run the following script:
Also applies to: 13-13, 17-17
✅ Verification successful
The change to the "AllowThinClientReadAccess" statement resource scope is verified to be limited to the intended files and does not impact other parts of the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for other occurrences of the thinclient ARN pattern in the repository # Test: Search for the old ARN pattern echo "Searching for other occurrences of the thinclient ARN pattern:" rg 'arn:aws:thinclient:\*:\*:\*' --type json # Test: List all files containing 'thinclient' actions to ensure consistent resource definitions echo "Listing files with 'thinclient' actions:" rg '"thinclient:' --type json -lLength of output: 8953
Script:
#!/bin/bash # Description: Verify occurrences of the thinclient ARN pattern and list files with 'thinclient' actions. # Test: Search for the old ARN pattern echo "Searching for occurrences of the thinclient ARN pattern:" rg 'arn:aws:thinclient:\*:\*:\*' --type json # Test: List all files containing 'thinclient' actions to ensure consistent resource definitions echo "Listing files with 'thinclient' actions:" rg '"thinclient:' --type json -lLength of output: 463
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (7)
5-11: Approve with clarification: Broad resource scope for ConnectCampaignAccessThe new statement allows listing campaigns across all resources, which seems appropriate for a service-linked role. However, could you please clarify if it's necessary to have such a broad scope ("*" for Resource) or if it can be more specific?
13-22: LGTM: ConnectAccess statement updated appropriatelyThe additional actions "connect:DescribeContactFlow" and "connect:SendOutboundEmail" are relevant to the Connect service and campaigns functionality. The resource scope remains appropriately limited to Connect instances.
24-35: LGTM: EventBridgeListRuleAccess statement added with proper restrictionsThis new statement allows listing EventBridge rules with appropriate account-level restrictions. The condition ensures that the access is limited to the same account, which is a good security practice.
37-52: LGTM: EventBridgeManagedResourceAccess statement added with proper restrictionsThis new statement provides necessary permissions for managing specific EventBridge rules related to Connect Campaigns. The resource pattern and conditions ensure that only relevant rules are affected, and the managed by condition adds an extra layer of security.
54-65: LGTM: EventBridgeListTargetsByRuleAccess statement added with proper restrictionsThis new statement allows listing targets for specific EventBridge rules related to Connect Campaigns. The resource pattern ensures that only relevant rules are affected, and the account-level condition adds an appropriate security measure.
67-78: Approve with clarification: Broad resource scope for Wisdom actionsThe new statement allows appropriate Wisdom actions for message templates, with a good use of resource tagging for access control. However, could you please clarify if it's necessary to have such a broad scope ("*" for Resource) or if it can be more specific to Wisdom resources?
Line range hint
1-81: Summary: Policy updates enhance functionality with good security practicesThe changes to this policy document generally improve the functionality of the Amazon Connect Campaigns Service Linked Role by adding necessary permissions for Connect Campaigns and related services (EventBridge, Wisdom). Most statements use appropriate conditions and specific resource patterns, which is a good security practice.
However, there are two areas where clarification on the use of broad resource scopes ("*") would be beneficial:
- The "ConnectCampaignAccess" statement (lines 5-11)
- The "AllowWisdomForConnectCampaignsEnabledTaggedResources" statement (lines 67-78)
Could you please provide justification for these broad scopes or consider narrowing them if possible?
To verify the usage of broad resource scopes, please run the following script:
This will help identify any other instances of broad resource scopes in the repository's IAM policies.
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (6)
67-70: LGTM: Appropriate ECS and ECR restrictions addedThe addition of ECS actions (CreateService, CreateCluster, RegisterTaskDefinition) and ECR's GetAuthorizationToken is appropriate for a compromised key quarantine policy. These restrictions prevent the creation of new ECS resources and limit access to ECR, which aligns with the policy's purpose of minimizing potential damage from a compromised key.
71-75: LGTM: Comprehensive Bedrock AI restrictions addedThe addition of Bedrock AI actions (CreateModelInvocationJob, InvokeModelWithResponseStream, CreateFoundationModelAgreement, PutFoundationModelEntitlement, InvokeModel) is a prudent measure for a compromised key quarantine policy. These restrictions prevent the creation, invocation, and manipulation of AI models, which could potentially be misused if a key is compromised.
76-81: LGTM for write actions, reconsider S3 read actionsThe addition of S3 write actions (CreateBucket, PutBucketCors) and SageMaker actions (CreateEndpointConfig, CreateProcessingJob) is appropriate for a compromised key quarantine policy, as they prevent the creation of new resources that could be misused.
However, as noted in a previous comment, denying S3 read actions (GetObject, ListBucket) might hinder legitimate administrative tasks during incident response. These read-only operations could be useful for security teams investigating the compromise.
Consider removing "s3:GetObject" and "s3:ListBucket" from the deny list to facilitate incident response activities, unless there's a specific security concern that justifies their inclusion.
86-89: LGTM: Appropriate restrictions for Amplify, CodeBuild, and GlueThe addition of actions for Amplify (CreateDeployment, CreateBackendEnvironment), CodeBuild (CreateProject), and Glue (CreateJob) is appropriate for a compromised key quarantine policy. These restrictions prevent the creation of new resources across these services, which aligns with the policy's purpose of minimizing potential damage from a compromised key.
90-92: LGTM for destructive actions, reconsider IAM:ListUsersThe addition of IAM actions DeleteRole and DeleteAccessKey is appropriate for a compromised key quarantine policy, as they prevent destructive actions on access controls.
As noted in a previous comment, including
iam:ListUsersin the deny list might hinder legitimate administrative tasks during incident response. Consider removing this action from the deny list, as it's a read-only operation that could be useful for security teams investigating the compromise.
93-95: LGTM for MediaPackage, reconsider Lambda and SNS read actionsThe addition of
mediapackagev2:CreateChannelis appropriate as it prevents the creation of new resources, aligning with the quarantine policy's purpose.As noted in a previous comment, the inclusion of
lambda:GetEventSourceMappingandsns:GetSMSAttributesraises questions:
- These are read-only actions that don't modify resources or escalate privileges.
- Denying these actions might hinder incident response efforts by restricting access to potentially useful information.
Consider removing these read-only actions from the deny list unless there's a specific security concern that justifies their inclusion.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (6)
Line range hint
27-47: LGTM - Well-scoped permissions for Data Exchange jobsThe "DataExchangeJobsActions" statement provides appropriate permissions for managing AWS Data Exchange jobs. The use of conditions to limit job types is a good security practice, ensuring that only specific job types can be created, started, or canceled.
Line range hint
49-60: LGTM - Secure S3 access for Data ExchangeThe "S3GetActionConditionalResourceAndADX" statement provides a secure way to access S3 objects for AWS Data Exchange. The combination of resource naming condition and the requirement for the action to be called via dataexchange.amazonaws.com ensures that this permission is tightly controlled and used only in the intended context.
Line range hint
62-76: LGTM - Flexible and secure S3 access for Data ExchangeThe "S3GetActionConditionalTagAndADX" statement provides a flexible yet secure way to access S3 objects for AWS Data Exchange. By using object tags and service-based conditions, it allows access to relevant objects across different buckets while ensuring that the access is controlled and used only in the intended context.
Line range hint
78-92: LGTM - Secure S3 write access for Data ExchangeThe "S3WriteActions" statement provides a secure way to write S3 objects for AWS Data Exchange. The combination of resource naming condition and the requirement for the actions to be called via dataexchange.amazonaws.com ensures that these write permissions are tightly controlled and used only in the intended context.
Line range hint
124-132: LGTM - Appropriate KMS read permissionsThe "KMSActions" statement provides necessary read-only permissions for KMS operations. These are typically required for working with encrypted resources and are appropriately scoped to just the required actions.
Line range hint
134-162: LGTM - Well-scoped permissions for Redshift and API GatewayThe new statements for Redshift and API Gateway actions are appropriately scoped:
- "RedshiftConditionalActions" allows data share authorization with a specific condition, enhancing security.
- "RedshiftActions" provides necessary describe actions for data shares.
- "APIGatewayActions" is limited to GET requests, following the principle of least privilege.
These permissions appear to be necessary for the expanded functionality of AWS Data Exchange while maintaining good security practices.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (5)
80-87: LGTM: Enhanced Customer Profiles capabilitiesThe new permissions added to the "AllowCustomerProfilesForConnectDomain" statement expand the capabilities for managing customer profiles and segmentation. These additions include:
- Listing integrations and segment definitions
- Listing profile attribute values
- Creating and getting segment estimates
- Batch operations for profiles and calculated attributes
- Getting segment membership
These changes align with the PR objectives and enhance the functionality of the Amazon Connect service.
96-97: LGTM: Added permission to list object type attributesThe addition of the "profile:ListObjectTypeAttributes" permission to the "AllowReadPermissionForCustomerProfileObjects" statement enhances the read capabilities for Customer Profile objects. This change allows the service to list attributes of object types, which is consistent with the existing read permissions and improves the overall functionality for managing customer profiles.
149-163: LGTM: Expanded Wisdom capabilities for message template managementThe "AllowWisdomForConnectEnabledTaggedResources" statement has been significantly enhanced with new permissions for managing message templates in Amazon Connect Wisdom. These additions allow for creating, updating, deleting, and managing templates and their metadata, as well as activating, deactivating, and rendering templates.
These changes align with the PR objectives and expand the functionality of the Amazon Connect Wisdom service while maintaining the existing security model of allowing actions only on tagged resources.
195-208: LGTM: New permissions for Customer Profiles segmentationA new statement "AllowCustomerProfilesSegmentationForConnectDomain" has been added to the policy. This statement grants permissions for managing segment definitions and snapshots within the Customer Profiles service, including:
- Creating, getting, and deleting segment definitions
- Creating and getting segment snapshots
These permissions are correctly scoped to the Amazon Connect domain and enhance the segmentation capabilities of the Customer Profiles service. This addition aligns with the PR objectives and complements the existing Customer Profiles permissions.
Line range hint
1-258: Summary: Comprehensive update to AmazonConnectServiceLinkedRolePolicyThis update to the AmazonConnectServiceLinkedRolePolicy significantly enhances the capabilities of Amazon Connect and its integrated services:
- Expanded Customer Profiles functionality, including improved segmentation and attribute management.
- Enhanced Wisdom service capabilities, particularly in message template management.
- New permissions for Customer Profiles segmentation, allowing for more advanced customer segmentation strategies.
These changes align with the PR objectives of updating AWS managed policies and maintain the existing security model of resource-specific permissions and tagging. The updates will provide Amazon Connect users with more powerful tools for managing customer interactions and data.
Overall, this is a well-structured and comprehensive update to the policy that should improve the functionality of Amazon Connect while maintaining appropriate security controls.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (10)
Line range hint
5-127: Comprehensive ECS management policy addedThis new policy statement, "ECSIntegrationsManagementPolicy", provides a wide range of permissions necessary for managing Amazon ECS and its integrations with other AWS services. It includes actions for auto-scaling, AppMesh, CloudFormation, CloudWatch, CodeDeploy, EC2, Elastic File System, Elastic Load Balancing, EventBridge, FSx, IAM, Lambda, CloudWatch Logs, Route 53, and Service Discovery.
The policy follows the principle of least privilege by granting only the permissions necessary for ECS management, despite its broad scope. The use of "*" for the Resource is appropriate for a service-level management policy.
Line range hint
128-137: Well-scoped SSM permissions for ECS parametersThe "SSMPolicy" statement grants permissions to retrieve parameters from AWS Systems Manager Parameter Store. It's correctly limited to only the necessary actions (
GetParameter,GetParameters,GetParametersByPath) and scoped specifically to ECS-related parameters (arn:aws:ssm:*:*:parameter/aws/service/ecs*).This adheres to the principle of least privilege by providing only the required access for ECS operations.
Line range hint
138-155: Secure cleanup policy for ECS-managed CloudFormation resourcesThe "ManagedCloudformationResourcesCleanupPolicy" statement allows for the deletion of specific EC2 resources (Internet Gateways, Routes, Route Tables, and Security Groups) that are typically created as part of ECS infrastructure.
A notable security measure is the condition that restricts these delete actions to resources tagged with a CloudFormation stack name matching the pattern "EC2ContainerService-*". This ensures that only resources created by ECS through CloudFormation can be deleted, preventing accidental deletion of unrelated resources.
Line range hint
156-168: Secure IAM role passing for ECS tasksThe "TasksPassRolePolicy" statement allows the passing of IAM roles, which is crucial for assigning permissions to ECS tasks. The policy is well-constrained:
- It's limited to the
iam:PassRoleaction.- It includes a condition that restricts role passing to only the ECS tasks service (
ecs-tasks.amazonaws.com).This configuration ensures that roles can only be passed to ECS tasks, preventing potential misuse of this permission for other services.
169-180: Secure IAM role passing for ECS infrastructureThe "InfrastructurePassRolePolicy" statement is well-designed for securely passing the ECS infrastructure role:
- It's limited to the
iam:PassRoleaction.- The resource is correctly scoped to the specific ECS infrastructure role (
arn:aws:iam::*:role/ecsInfrastructureRole).- It includes a condition that restricts role passing to only the ECS service (
ecs.amazonaws.com).This configuration ensures that the ECS infrastructure role can only be passed to the ECS service, maintaining the principle of least privilege.
Line range hint
181-197: Secure IAM role passing for ECS EC2 instancesThe "InstancePassRolePolicy" statement is well-crafted for securely passing roles to EC2 instances used by ECS:
- It's limited to the
iam:PassRoleaction.- The resource is correctly scoped to ECS instance roles (
arn:aws:iam::*:role/ecsInstanceRole*).- It includes a condition that restricts role passing to only EC2 services, covering both global and China regions.
This configuration ensures that ECS instance roles can only be passed to EC2 instances, maintaining security while allowing for global operations.
Line range hint
198-213: Secure IAM role passing for ECS Auto ScalingThe "AutoScalingPassRolePolicy" statement is well-designed for securely passing roles to Application Auto Scaling for ECS:
- It's limited to the
iam:PassRoleaction.- The resource is correctly scoped to ECS autoscale roles (
arn:aws:iam::*:role/ecsAutoscaleRole*).- It includes a condition that restricts role passing to only Application Auto Scaling services, covering both global and China regions.
This configuration ensures that ECS autoscale roles can only be passed to Application Auto Scaling, maintaining security while allowing for global operations.
Line range hint
214-230: Extended service-linked role creation for ECS and related servicesThe "ServiceLinkedRoleCreationPolicy" statement has been expanded to allow creation of service-linked roles for additional services commonly used with ECS:
- It's limited to the
iam:CreateServiceLinkedRoleaction.- It includes a condition that restricts role creation to specific AWS services:
- ecs.amazonaws.com
- autoscaling.amazonaws.com (new)
- ecs.application-autoscaling.amazonaws.com (new)
- spot.amazonaws.com (new)
- spotfleet.amazonaws.com (new)
This expansion allows for better integration with Auto Scaling and EC2 Spot Instances, which can enhance the flexibility and cost-effectiveness of ECS deployments.
Line range hint
231-248: Controlled tagging for ELB resources in ECSThe "ELBTaggingPolicy" statement is a valuable addition that allows for controlled tagging of Elastic Load Balancing resources:
- It's limited to the
elasticloadbalancing:AddTagsaction.- It includes a condition that restricts tagging to only when ELB resources are being created, specifically:
- CreateTargetGroup
- CreateRule
- CreateListener
- CreateLoadBalancer
This policy enables consistent tagging of ELB resources at creation time, which is crucial for proper resource management, cost allocation, and maintaining organizational tagging standards in ECS deployments that utilize load balancers.
Line range hint
1-249: Comprehensive and secure update to AmazonECS_FullAccess policyThis update to the AmazonECS_FullAccess policy is well-structured and comprehensive. It introduces several new policy statements that enhance the capabilities for managing Amazon ECS and its integrations with other AWS services. Key improvements include:
- Expanded permissions for ECS integrations and management
- Secure access to SSM parameters for ECS
- Controlled cleanup of ECS-managed CloudFormation resources
- Secure IAM role management for ECS tasks, infrastructure, EC2 instances, and Auto Scaling
- Extended service-linked role creation capabilities
- Controlled tagging for ELB resources in ECS deployments
Throughout these additions, the policy maintains strong security practices by consistently applying scoped resources and restrictive conditions. This update strikes a good balance between providing the necessary permissions for full ECS management and adhering to the principle of least privilege.
These changes will allow for more comprehensive management of ECS environments, including better integration with Auto Scaling, EC2 Spot Instances, and load balancers, while maintaining a strong security posture.
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (3)
Line range hint
120-126: Improved security through specific service-linked role ARNThe update to the
CreateServiceLinkedRolestatement enhances security by specifying a precise ARN for the service-linked role. This change restricts the policy to create only the intended role for the AWS Service Catalog App Registry service, adhering to the principle of least privilege.
276-297: Well-structured permission for SAP resource group managementThe new
SsmSapResourceGroupstatement is a well-crafted addition that allows for the creation and tagging of resource groups specifically for Systems Manager for SAP. The conditions ensure that:
- Only groups with the
SSMForSAPCreatedtag set to "True" can be created or tagged.- The
awsApplicationtag must be an ARN of a resource group, maintaining consistency.- Only the specified tags (
SSMForSAPCreatedandawsApplication) can be added.This structured approach enhances control and organization of SAP-related resources.
299-316: Controlled tag management for SSM-managed SAP instancesThe new
ManageSsmSapTagsOnEc2Instancesstatement provides a secure way to manage tags on EC2 instances that are already under SSM for SAP management. Key points:
- Only instances with the
SSMForSAPManagedtag set to "True" can have their tags modified.- Only tags starting with "SystemsManagerForSAP-" can be created or deleted.
This ensures that tag management is restricted to the appropriate instances and tag keys, maintaining the integrity of the SAP management system.
docs/source/_static/managed-policies/AWS_ConfigRole.json (6)
32-43: LGTM: Enhanced AOSS monitoring capabilitiesThe addition of these Amazon OpenSearch Service (AOSS) permissions enhances AWS Config's ability to monitor and assess AOSS resources. This includes operations for retrieving and listing various AOSS components such as collections, lifecycle policies, VPC endpoints, access policies, and security configurations. These read-only permissions align with AWS Config's role in resource monitoring and compliance checking.
89-89: LGTM: Extended monitoring capabilities for AppStream, AWS Backup, and CloudTrailThese additions enhance AWS Config's monitoring capabilities:
- AppStream: Ability to describe app block builders.
- AWS Backup: Permissions to get and list restore testing plans and selections.
- CloudTrail: Capabilities to get and list channels.
These read-only permissions are consistent with AWS Config's role in resource monitoring and compliance checking across various AWS services.
Also applies to: 136-137, 144-145, 185-185, 189-189
568-568: LGTM: Enhanced monitoring for AWS Glue and IoT servicesThese additions expand AWS Config's monitoring capabilities:
- AWS Glue: Permissions to get and list triggers.
- AWS IoT: Abilities to describe and list billing groups.
These read-only permissions allow AWS Config to gather more comprehensive information about Glue and IoT resources, enhancing its ability to monitor and assess the configuration of these services.
Also applies to: 574-574, 676-676, 693-693
769-774: LGTM: Expanded monitoring for video streaming and media servicesThese additions significantly enhance AWS Config's capabilities for monitoring video streaming and media services:
AWS IVS (Interactive Video Service):
- New permissions to get and list encoder configurations, playback restriction policies, stages, and storage configurations.
MediaConnect:
- Added abilities to describe and list bridges and gateways.
MediaTailor:
- New permissions to describe and list channels, live sources, source locations, and VOD sources.
These read-only permissions allow AWS Config to gather comprehensive information about these media services, improving its ability to monitor and assess their configurations for compliance and best practices.
Also applies to: 777-782, 905-910, 917-926
970-971: LGTM: Extended monitoring for Omics, Scheduler, and SSM-SAP servicesThese additions further expand AWS Config's monitoring capabilities to include newer or less common AWS services:
- AWS Omics: Permissions to get and list workflows.
- AWS Scheduler: Abilities to get and list schedules.
- SSM-SAP: Permission to list tags for resources.
These read-only permissions enable AWS Config to gather information about these specialized services, enhancing its ability to monitor and assess their configurations. This expansion aligns with AWS Config's role in providing comprehensive resource monitoring across the AWS ecosystem.
Also applies to: 1256-1257, 1308-1308
Line range hint
1-1395: Summary: Comprehensive update enhancing AWS Config's monitoring capabilitiesThis update to the AWS_ConfigRole.json policy significantly expands AWS Config's ability to monitor and assess a wide range of AWS services. The additions include new permissions for:
- Amazon OpenSearch Service (AOSS)
- AppStream
- AWS Backup
- CloudTrail
- AWS Glue
- AWS IoT
- AWS IVS (Interactive Video Service)
- MediaConnect
- MediaTailor
- AWS Omics
- AWS Scheduler
- SSM-SAP
These changes align perfectly with the PR objective of updating AWS managed policies. By granting read-only access to these additional services and resources, AWS Config can now provide more comprehensive monitoring, auditing, and compliance checking across the AWS ecosystem.
The expanded permissions are consistent with AWS Config's role and do not introduce any apparent security risks, as they are limited to read-only operations. This update will enable users to have a more holistic view of their AWS environment through AWS Config, enhancing their ability to maintain compliance and best practices across a broader range of services.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (9)
32-43: LGTM: New AOSS permissions enhance AWS Config capabilitiesThe addition of these Amazon OpenSearch Service (AOSS) permissions allows AWS Config to monitor and assess the configuration of AOSS resources. These read-only permissions are appropriate for AWS Config's role and cover a comprehensive set of AOSS resources and operations.
135-136: LGTM: New AWS Backup permissions for restore testingThe addition of these AWS Backup permissions enables AWS Config to monitor and assess the configuration of restore testing plans and selections. These read-only permissions are appropriate for AWS Config's role and enhance its ability to provide insights into disaster recovery preparedness.
Also applies to: 143-144
88-88: LGTM: New AppStream permission for app block buildersThe addition of the "appstream:DescribeAppBlockBuilders" permission allows AWS Config to monitor and assess the configuration of AppStream 2.0 app block builders. This read-only permission is appropriate for AWS Config's role and enhances its coverage of AppStream resources.
566-566: LGTM: New Glue permissions for trigger monitoringThe addition of "glue:GetTrigger" and "glue:ListTriggers" permissions enables AWS Config to monitor and assess the configuration of AWS Glue triggers. These read-only permissions are appropriate for AWS Config's role and enhance its ability to provide insights into Glue resource configurations.
Also applies to: 572-572
767-772: LGTM: New IVS permissions for comprehensive resource monitoringThe addition of these Interactive Video Service (IVS) permissions allows AWS Config to monitor and assess the configuration of various IVS resources, including encoder configurations, playback restriction policies, stages, and storage configurations. These read-only permissions are appropriate for AWS Config's role and significantly enhance its coverage of IVS resources.
Also applies to: 775-780
903-903: LGTM: New MediaConnect permissions for bridge and gateway monitoringThe addition of these MediaConnect permissions enables AWS Config to monitor and assess the configuration of MediaConnect bridges and gateways. These read-only permissions (Describe and List operations) are appropriate for AWS Config's role and enhance its ability to provide insights into MediaConnect resource configurations.
Also applies to: 905-906, 908-908
915-918: LGTM: New MediaTailor permissions for comprehensive resource monitoringThe addition of these MediaTailor permissions allows AWS Config to monitor and assess the configuration of various MediaTailor resources, including channels, live sources, source locations, and VOD sources. These read-only permissions (Describe and List operations) are appropriate for AWS Config's role and significantly enhance its coverage of MediaTailor resources.
Also applies to: 920-924
968-969: LGTM: New Omics and Scheduler permissions for workflow and schedule monitoringThe addition of Omics permissions (GetWorkflow, ListWorkflows) and Scheduler permissions (GetSchedule, ListSchedules) enables AWS Config to monitor and assess the configuration of Omics workflows and Scheduler schedules. These read-only permissions are appropriate for AWS Config's role and extend its coverage to include these newer AWS services.
Also applies to: 1254-1255
Line range hint
1-1437: Summary: Comprehensive update to AWSConfigServiceRolePolicyThis update to the AWSConfigServiceRolePolicy significantly enhances AWS Config's capabilities by adding permissions for several AWS services:
- Amazon OpenSearch Service (AOSS)
- AWS Backup
- AppStream
- AWS Glue
- Interactive Video Service (IVS)
- MediaConnect
- MediaTailor
- Omics
- Scheduler
All added permissions are read-only (Get, Describe, List operations), which is appropriate for AWS Config's monitoring and assessment role. These changes allow AWS Config to provide more comprehensive insights into the configuration and compliance of a wider range of AWS resources.
The updates follow the principle of least privilege and are consistent with AWS Config's purpose. This expansion of monitored services will improve the overall visibility and governance of AWS environments using Config.
docs/source/_static/managed-policies/ReadOnlyAccess.json (6)
111-111: Approval: New permission aligns with read-only access policyThe addition of "application-signals:ListServices" is appropriate for a read-only access policy as it only allows listing services without any modification capabilities.
222-225: Approval: New bedrock permissions maintain read-only accessThe additions to the bedrock service permissions are appropriate for a read-only access policy. They include only Get and List operations, which allow for viewing information without making any changes. These permissions enhance the policy's coverage for the bedrock service while maintaining its read-only nature.
Also applies to: 239-242
275-275: Approval: New budgets permission is read-onlyThe addition of "budgets:ListTagsForResource" is appropriate for this read-only access policy. It allows for viewing tags associated with resources in the budgets service without granting any modification capabilities.
318-328: Approval: New cleanrooms-ml permissions maintain read-only accessThe additions to the cleanrooms-ml service permissions are appropriate for a read-only access policy. They include only Get and List operations, which allow for viewing information about audience models, datasets, and other related resources without making any changes. These permissions enhance the policy's coverage for the cleanrooms-ml service while adhering to the read-only principle.
1922-1938: Approval: New s3-outposts permissions align with read-only accessThe additions to the s3-outposts service permissions are appropriate for a read-only access policy. They include only Get and List operations, which allow for viewing information about buckets, objects, and other S3 on Outposts resources without making any changes. These permissions enhance the policy's coverage for the s3-outposts service while maintaining its read-only nature.
Line range hint
1-2175: Overall approval: All additions maintain read-only access principleAfter reviewing all the additions to the ReadOnlyAccess policy, I can confirm that they all adhere to the principle of providing read-only access. The new permissions added for various services (application-signals, bedrock, budgets, cleanrooms-ml, s3-outposts, and others) only include Get and List operations, which allow for viewing and retrieving information without granting any modification capabilities.
These additions enhance the policy's coverage across multiple AWS services while maintaining its intended purpose of read-only access. The updates appear to be in line with AWS best practices for IAM policies.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (13)
87-88: New permissions added for AWS Account serviceThe policy now includes new permissions for the AWS Account service:
account:getRegionOptStatusaccount:listRegionsThese additions allow the AWS Support Service Role to retrieve information about region opt-in status and list available regions. This is likely to enhance support capabilities for region-related issues.
264-264: New permission added for Auto Scaling serviceA new permission has been added for the Auto Scaling service:
autoscaling:describeTrafficSourcesThis addition allows the AWS Support Service Role to describe traffic sources for Auto Scaling groups, which can be helpful in diagnosing scaling-related issues.
547-558: New permissions added for AWS CodeConnections serviceSeveral new permissions have been added for the AWS CodeConnections service, including:
- Various
getoperations (e.g.,getConnection,getHost,getRepositoryLink)- Multiple
listoperations (e.g.,listConnections,listHosts,listRepositoryLinks)These additions allow the AWS Support Service Role to retrieve and list information related to CodeConnections, which can be useful for diagnosing issues with code integration and deployment pipelines.
786-802: New permissions added for AWS Deadline serviceMultiple new permissions have been added for the AWS Deadline service, primarily focused on listing various resources:
listAvailableMeteredProductslistBudgetslistFarmMemberslistFarmslistFleetMemberslistFleetslistJobMemberslistJobslistLicenseEndpointslistMeteredProductslistMonitorslistQueueEnvironmentslistQueueFleetAssociationslistQueueMemberslistQueueslistStorageProfileslistWorkersThese additions enhance the role's ability to gather information about Deadline resources, which can be valuable for supporting render farm and content production workflows.
1018-1018: New EC2-related permissions addedTwo new permissions have been added for EC2-related operations:
ec2:describeSnapshotTierStatusec2:getSubnetCidrReservationsThese additions allow the AWS Support Service Role to retrieve information about EC2 snapshot tier status and subnet CIDR reservations, which can be helpful in diagnosing EC2-related issues.
Also applies to: 1064-1064
1143-1144: New permissions added for EKS Pod Identity AssociationsTwo new permissions have been added for Amazon EKS (Elastic Kubernetes Service) related to Pod Identity Associations:
eks:describePodIdentityAssociationeks:listPodIdentityAssociationsThese additions allow the AWS Support Service Role to retrieve information about Pod Identity Associations in EKS, which can be useful for troubleshooting identity and access management issues in Kubernetes environments.
1210-1212: New permissions added for Elastic Load Balancing TrustStore operationsThree new permissions have been added for Elastic Load Balancing TrustStore operations:
elasticloadbalancing:describeTrustStoreselasticloadbalancing:describeTrustStoreAssociationselasticloadbalancing:describeTrustStoreRevocationsThese additions allow the AWS Support Service Role to retrieve information about TrustStores, their associations, and revocations in Elastic Load Balancing, which can be helpful in diagnosing SSL/TLS-related issues.
1343-1343: New permission added for AWS Free Tier usageA new permission has been added for retrieving AWS Free Tier usage information:
freetier:getFreeTierUsageThis addition allows the AWS Support Service Role to access Free Tier usage data, which can be helpful in assisting customers with billing-related inquiries and optimizing their resource usage.
2295-2300: New permissions added for AWS OSIS serviceSeveral new permissions have been added for the AWS OSIS (Open Search Ingestion Service) service:
osis:getPipelineosis:getPipelineBlueprintosis:getPipelineChangeProgressosis:listPipelineBlueprintsosis:listPipelinesosis:validatePipelineThese additions allow the AWS Support Service Role to retrieve and manage OSIS pipelines and blueprints, which can be useful for troubleshooting data ingestion issues in OpenSearch environments.
3355-3356: New permissions added for WorkSpaces associationsTwo new permissions have been added for AWS WorkSpaces associations:
workspaces:describeApplicationAssociationsworkspaces:describeWorkspaceAssociationsThese additions allow the AWS Support Service Role to retrieve information about application and workspace associations in WorkSpaces, which can be helpful in diagnosing issues related to virtual desktop environments.
3368-3374: New permissions added for AWS X-Ray serviceSeveral new permissions have been added for the AWS X-Ray service:
xray:listResourcePoliciesxray:getInsightImpactGraphxray:getSamplingStatisticSummariesxray:getSamplingTargetsxray:getServiceGraphxray:getTimeSeriesServiceStatisticsxray:getTraceGraphThese additions enhance the role's ability to retrieve various X-Ray related information, which can be valuable for diagnosing and troubleshooting application performance issues.
Line range hint
1-3374: Overall assessment of policy changesThe updates to the AWSSupportServiceRolePolicy significantly expand its capabilities across various AWS services. New permissions have been added for services such as AWS Account, Auto Scaling, Bedrock, CodeConnections, Deadline, EC2, EKS, Elastic Load Balancing, Free Tier, OSIS, WorkSpaces, and X-Ray. These additions enhance the AWS Support Service Role's ability to diagnose issues, gather relevant information, and provide more comprehensive support across a wider range of AWS offerings.
The new permissions are generally focused on read-only or descriptive actions, which aligns with the principle of least privilege for a support role. However, it's important to note that the policy now includes a substantial number of permissions, which may warrant periodic reviews to ensure all permissions remain necessary and properly scoped.
Recommendation:
- Implement a regular review process (e.g., quarterly) to assess the usage and necessity of each permission in this policy.
- Consider using AWS Access Analyzer to identify any permissions that are not being used and could potentially be removed to adhere to the principle of least privilege.
324-345: Extensive new permissions added for AWS Bedrock serviceA significant number of new permissions have been added for the AWS Bedrock service, including:
- Various
getoperations (e.g.,getAgent,getCustomModel,getDataSource)- Multiple
listoperations (e.g.,listAgents,listCustomModels,listDataSources)These additions greatly expand the role's capabilities in managing and monitoring AWS Bedrock resources, which is likely related to new AI and machine learning offerings.
To ensure these new Bedrock permissions are necessary and properly scoped, please run the following script:
✅ Verification successful
Bedrock permissions verified and necessary
The added AWS Bedrock permissions in
AWSSupportServiceRolePolicy.jsonare necessary and appropriately scoped based on their extensive usage within the codebase and existing managed policies.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any existing uses of Bedrock services in AWS documentation or knowledge base echo "Searching for Bedrock-related support documentation:" rg -i "bedrock.*get|bedrock.*list" --type md docs/ echo "If results are found, they may indicate existing use cases for these permissions in support scenarios."Length of output: 382
Script:
#!/bin/bash # Description: Search the entire codebase for any usage of AWS Bedrock service APIs or configurations echo "Searching for Bedrock service usage in the codebase:" rg -i "bedrock" --type js --type py --type java --type go --type ts --type json --type yaml --type ymlLength of output: 245
Script:
#!/bin/bash # Description: Search the entire codebase for any usage of AWS Bedrock service APIs or configurations echo "Searching for Bedrock service usage in the codebase:" rg -i "bedrock" --type js --type py --type java --type go --type ts --type json --type yamlLength of output: 87628
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ecr:GetAuthorizationToken", | ||
| "ecr:BatchGetImage", | ||
| "ecr:GetDownloadUrlForLayer", | ||
| "ecr:BatchImportUpstreamImage" | ||
| ], | ||
| "Resource": "*" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider refining the "pull-only" permissions.
The policy grants appropriate permissions for pulling images from ECR, including authentication and image retrieval. However, the inclusion of ecr:BatchImportUpstreamImage might extend beyond the scope of a strictly "pull-only" policy.
Consider removing the ecr:BatchImportUpstreamImage action if the policy is intended to be strictly for pulling images:
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
- "ecr:BatchImportUpstreamImage"
],If the ecr:BatchImportUpstreamImage action is necessary for your use case, consider updating the policy name or documentation to reflect this additional capability.
📝 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.
| "Effect": "Allow", | |
| "Action": [ | |
| "ecr:GetAuthorizationToken", | |
| "ecr:BatchGetImage", | |
| "ecr:GetDownloadUrlForLayer", | |
| "ecr:BatchImportUpstreamImage" | |
| ], | |
| "Resource": "*" | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ecr:GetAuthorizationToken", | |
| "ecr:BatchGetImage", | |
| "ecr:GetDownloadUrlForLayer" | |
| ], | |
| "Resource": "*" |
| "ses:GetSendQuota", | ||
| "ses:ListIdentities", | ||
| "sts:GetSessionToken", | ||
| "sts:GetFederationToken", |
There was a problem hiding this comment.
LGTM for STS actions, reconsider SES read actions
The addition of STS actions (GetSessionToken, GetFederationToken) is appropriate for a compromised key quarantine policy, as they prevent obtaining new credentials that could be misused.
However, the SES actions (GetSendQuota, ListIdentities) are read-only operations that don't pose a direct security risk. Denying these might hinder legitimate administrative tasks or incident response efforts.
Consider removing "ses:GetSendQuota" and "ses:ListIdentities" from the deny list, as they are read-only actions that could be useful for investigating the extent of a potential compromise.
| "Sid": "ManageSsmSapTagsOnEbsVolumes", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ec2:CreateTags", | ||
| "ec2:DeleteTags" | ||
| ], | ||
| "Resource": "arn:aws:ec2:*:*:volume/*", | ||
| "Condition": { | ||
| "ForAllValues:StringLike": { | ||
| "aws:TagKeys": [ | ||
| "SystemsManagerForSAP-*" | ||
| ] | ||
| } | ||
| } | ||
| }, |
There was a problem hiding this comment.
Potential over-permissive tagging on EBS volumes
The new ManageSsmSapTagsOnEbsVolumes statement allows for managing tags on EBS volumes, but it may be too permissive:
- It allows tagging any EBS volume, not just those associated with SSM-managed SAP instances.
- The only restriction is on the tag keys that can be managed.
This could potentially allow tagging of unrelated EBS volumes, which may not be the intended behavior.
Consider adding a condition to restrict this action to EBS volumes associated with SSM-managed SAP instances, similar to the EC2 instance tagging statement. For example:
"Condition": {
"StringEquals": {
"ec2:ResourceTag/SSMForSAPManaged": "True"
},
"ForAllValues:StringLike": {
"aws:TagKeys": [
"SystemsManagerForSAP-*"
]
}
}This would ensure that only volumes related to SSM-managed SAP instances can be tagged.
| "Sid": "ManageAppTagsOnEbsVolumes", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ec2:CreateTags", | ||
| "ec2:DeleteTags" | ||
| ], | ||
| "Resource": "arn:aws:ec2:*:*:volume/*", | ||
| "Condition": { | ||
| "ArnLike": { | ||
| "aws:RequestTag/awsApplication": "arn:aws:resource-groups:*:*:group/*/*" | ||
| }, | ||
| "ForAllValues:StringEquals": { | ||
| "aws:TagKeys": [ | ||
| "awsApplication" | ||
| ] | ||
| } | ||
| } |
There was a problem hiding this comment.
Broad permission for application tagging on EBS volumes
The new ManageAppTagsOnEbsVolumes statement allows for managing the awsApplication tag on EBS volumes. While it ensures the tag value is a resource group ARN, there are potential issues:
- It allows tagging any EBS volume, not just those associated with SSM-managed SAP instances.
- There's no restriction on which volumes can be tagged, which might be too permissive.
This broad permission could lead to unintended tagging of volumes not related to the SAP management system.
Consider adding a condition to restrict this action to EBS volumes associated with SSM-managed SAP instances. For example:
"Condition": {
"StringEquals": {
"ec2:ResourceTag/SSMForSAPManaged": "True"
},
"ArnLike": {
"aws:RequestTag/awsApplication": "arn:aws:resource-groups:*:*:group/*/*"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"awsApplication"
]
}
}This would ensure that only volumes related to SSM-managed SAP instances can be tagged with the awsApplication tag.
udondan
force-pushed
the
update-aws-managed-policies
branch
from
8d8350a
to
5e5a481
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (9)
docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1)
Line range hint
1-45: Overall policy changes expand scope while maintaining read-only natureThe changes to this policy significantly expand its scope by including read-only access to WorkSpaces, WorkSpaces Web, and AppStream services, in addition to the existing Thin Client permissions. While these additions maintain the read-only nature of the policy, they represent a substantial increase in the accessible resources and services.
Consider the following recommendations:
Verify that all these permissions are indeed necessary for Thin Client operations. The inclusion of WorkSpaces Web and AppStream permissions suggests a broader use case than just Thin Client management.
If possible, use more specific resource ARNs instead of "*" to adhere to the principle of least privilege.
Document the rationale for these changes, especially the inclusion of WorkSpaces Web and AppStream permissions, to maintain clear understanding of the policy's purpose and scope.
Consider splitting this policy if it's serving multiple distinct use cases (e.g., separate policies for Thin Client, WorkSpaces Web, and AppStream read-only access).
Ensure that all services using this policy are aware of and prepared for the expanded permissions to prevent any unintended access or functionality changes.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (3)
Line range hint
27-47: Approve DataExchangeJobsActions with a minor suggestionThe "DataExchangeJobsActions" statement is well-structured and follows good security practices:
- It grants specific permissions for job-related actions (create, start, cancel).
- The condition restricts the job types, which is a good security measure.
Consider adding a comment explaining the purpose of each job type for better documentation. For example:
"Condition": { "StringEquals": { "dataexchange:JobType": [ "IMPORT_ASSETS_FROM_S3", // Import assets from S3 buckets "IMPORT_ASSET_FROM_SIGNED_URL", // Import assets from signed URLs // ... (add comments for other job types) ] } }
Line range hint
62-77: Approve S3GetActionConditionalTagAndADX with a suggestionThe "S3GetActionConditionalTagAndADX" statement demonstrates good security practices:
- It grants a specific permission (S3:GetObject) rather than using wildcards.
- Although the resource is set to "*", the conditions effectively restrict access:
- Objects must have the tag "AWSDataExchange" set to "true" (case-insensitive).
- The action must be called via the Data Exchange service.
These conditions provide a good balance between flexibility and security.
Consider adding a comment explaining the purpose of the "AWSDataExchange" tag for better documentation. For example:
"Condition": { "StringEqualsIgnoreCase": { "s3:ExistingObjectTag/AWSDataExchange": "true" // Ensures object is intended for Data Exchange use }, // ... (rest of the condition) }
Line range hint
78-93: Approve S3WriteActions with a suggestionThe "S3WriteActions" statement demonstrates good security practices:
- It grants specific permissions (S3:PutObject and S3:PutObjectAcl) rather than using wildcards.
- The resource is restricted to S3 buckets containing "aws-data-exchange" in the name, limiting the scope.
- The condition ensures the action is called via the Data Exchange service, adding an extra layer of security.
Consider adding the
s3:x-amz-aclcondition key to ensure that only private ACLs are set. This can prevent accidental public exposure of objects. For example:"Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": [ "dataexchange.amazonaws.com" ] }, "StringEquals": { "s3:x-amz-acl": "private" } }This addition would further enhance the security of the policy.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (1)
Documentation Update Required
The documentation does not reflect the recent changes to Customer Profiles and Wisdom message template capabilities. Please update the README.md and relevant docs to include:
Customer Profiles:
- Enhanced segment management
- New functionalities related to profile attributes and segmentation
Wisdom Message Templates:
- Management of message templates
- Usage guidelines and examples
Ensure that all new permissions and capabilities introduced in the AmazonConnectServiceLinkedRolePolicy are accurately documented.
🔗 Analysis chain
Line range hint
1-258: Summary: Comprehensive update to AmazonConnectServiceLinkedRolePolicyThis PR successfully updates the AmazonConnectServiceLinkedRolePolicy with new permissions that significantly enhance the capabilities of Amazon Connect, Customer Profiles, and Wisdom services. The key improvements include:
- Expanded Customer Profiles functionality for managing profiles, segmentation, and attribute values.
- Enhanced read permissions for Customer Profile objects.
- Comprehensive new permissions for Wisdom message template management.
- New segmentation capabilities for Customer Profiles within the Connect domain.
These changes align well with the PR objectives and follow AWS best practices for IAM policy structure and scoping. The updates will provide users with more robust tools for managing customer data and content within the Amazon Connect ecosystem.
To ensure these policy changes are properly reflected in the documentation, please run the following script:
If the script doesn't find any relevant documentation updates, please ensure that the project documentation is updated to reflect these new capabilities and policy changes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if the README or documentation has been updated to reflect these policy changes # Search for mentions of new Customer Profiles and Wisdom capabilities in README and docs grep -R -i "customer profiles.*segment" README.md docs/ grep -R -i "wisdom.*message.*template" README.md docs/ # Check for any updates to policy documentation grep -R -i "AmazonConnectServiceLinkedRolePolicy" docs/Length of output: 45547
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (4)
Line range hint
5-127: Consider refining the resource scope for ECSIntegrationsManagementPolicyThe new ECSIntegrationsManagementPolicy provides a comprehensive set of permissions necessary for ECS integrations across multiple AWS services. However, the broad Resource scope ("*") might grant more permissions than necessary.
Consider the following recommendations:
- Review if all listed actions are required for your use case.
- Where possible, narrow down the Resource scope to specific ARNs or ARN patterns.
- Use condition keys to further restrict permissions based on tags, VPC, or other attributes.
This refinement will help adhere to the principle of least privilege and enhance the overall security posture.
Line range hint
138-155: Approve ManagedCloudformationResourcesCleanupPolicy with a suggestionThis policy statement allows for the cleanup of EC2 resources created by CloudFormation for ECS. The condition effectively limits the scope to ECS-related resources, which is a good practice.
Suggestion for improvement:
Consider using a more specific condition if possible. Instead of:"StringLike": { "ec2:ResourceTag/aws:cloudformation:stack-name": "EC2ContainerService-*" }You might use:
"StringEquals": { "ec2:ResourceTag/aws:cloudformation:stack-name": "EC2ContainerService-${aws:PrincipalAccount}" }This would further restrict the policy to only affect resources in the same account.
Line range hint
156-168: Approve TasksPassRolePolicy with a suggestion for tighter controlThis policy statement allows passing any IAM role to the ECS tasks service, which is necessary for ECS functionality. The condition correctly limits this to the ECS tasks service.
Suggestion for improvement:
Consider restricting the roles that can be passed to a specific path or naming convention. For example:{ "Sid": "TasksPassRolePolicy", "Action": "iam:PassRole", "Effect": "Allow", "Resource": [ "arn:aws:iam::*:role/ecs-task-*" ], "Condition": { "StringEquals": { "iam:PassedToService": "ecs-tasks.amazonaws.com" } } }This would ensure that only roles specifically designated for ECS tasks (by their name prefix in this example) can be passed.
Line range hint
1-249: Summary of AmazonECS_FullAccess policy updatesThe changes to the AmazonECS_FullAccess policy significantly enhance its capabilities while generally maintaining good security practices. Key points:
- New integrations are supported, including auto-scaling, AppMesh, and various AWS services.
- Most new statements are well-scoped, using appropriate conditions to limit permissions.
- The policy now covers a broader range of ECS-related operations, including infrastructure management, auto-scaling, and load balancing.
While the changes are generally approved, consider the following recommendations:
- Review the broad resource scope in the ECSIntegrationsManagementPolicy.
- Consider tightening the TasksPassRolePolicy to specific role patterns.
- Evaluate the suggested refinements in other policies for potential further improvements.
These updates align well with the PR objectives of updating AWS managed policies, providing necessary permissions for comprehensive ECS management while largely adhering to the principle of least privilege.
📜 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 (59)
- 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/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/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.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 (1 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/AWSSupportPlansFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 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 (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.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/AmazonECS_FullAccess.json (8 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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 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 (45)
- 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/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.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/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.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/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.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/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
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
🔇 Additional comments (63)
docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (4)
37-43: New AppStream access looks good, verify relevance to Thin ClientThe addition of the "AllowAppStreamAccess" statement granting permission to "appstream:DescribeStacks" is consistent with the read-only nature of this policy.
To ensure this new permission is necessary and used within the context of Thin Client operations, you can run the following command:
#!/bin/bash # Description: Search for usage of DescribeStacks in the codebase rg 'DescribeStacks' --type python --type typescript --type javascriptThis will help identify if and where this new permission is being utilized in relation to Thin Client functionality.
27-36: New WorkSpaces Web access looks appropriate, verify relevance to Thin ClientThe addition of the "AllowWorkSpacesWebAccess" statement granting read-only permissions to WorkSpaces Web actions (GetPortal, GetUserSettings, ListPortals) is consistent with the policy's purpose.
To ensure these new permissions are relevant to Thin Client operations, you can run the following command:
#!/bin/bash # Description: Search for usage of WorkSpaces Web actions in the codebase rg 'GetPortal|GetUserSettings|ListPortals' --type python --type typescript --type javascriptThis will help identify if and where these new permissions are being utilized in the context of Thin Client operations.
9-10: Verify the intended scope of the "AllowThinClientReadAccess" statementThe Resource specification for this statement has been changed from a specific ARN format to a wildcard "*". This broadens the scope of accessible resources under this policy.
Please confirm if this change is intentional and aligns with the principle of least privilege. If a more restrictive scope is possible, consider using a specific ARN or a condition to limit access.
To verify the impact, you can run the following command:
This will help identify if the specific ARN pattern is used elsewhere in the repository, which might indicate a need for consistency or further updates.
Also applies to: 13-13, 17-17
19-26: New WorkSpaces access looks good, verify if it's requiredThe addition of the "AllowWorkSpacesAccess" statement granting permission to "workspaces:DescribeWorkspaceDirectories" aligns with the read-only nature of this policy.
To ensure this addition is necessary and used within the context of Thin Client operations, you can run the following command:
This will help identify if and where this new permission is being utilized in the codebase.
✅ Verification successful
AllowWorkSpacesAccess Verified
The "AllowWorkSpacesAccess" statement granting permission to "workspaces:DescribeWorkspaceDirectories" is used within
lib/generated/policy-statements/workspaces.ts, confirming the necessity of this addition.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for usage of DescribeWorkspaceDirectories in the codebase rg 'DescribeWorkspaceDirectories' --type python --type typescript --type javascriptLength of output: 202
Script:
#!/bin/bash # Description: Search for usage of DescribeWorkspaceDirectories in the codebase by file extensions rg 'DescribeWorkspaceDirectories' --type-add 'python:*.py' --type-add 'typescript:*.ts' --type-add 'javascript:*.js' --type python --type typescript --type javascriptLength of output: 577
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (6)
5-11: Consider restricting the resource scope for ConnectCampaignAccessThe new statement allows listing campaigns across all resources. While this might be necessary for the service-linked role, it's generally a good practice to limit the scope of permissions when possible.
Consider if it's feasible to restrict the resource to a specific ARN pattern, such as:
"Resource": "arn:aws:connect-campaigns:*:*:instance/*/campaign/*"If this is not possible due to service requirements, please confirm that this broad permission is indeed necessary.
13-22: Approved: ConnectAccess statement updated appropriatelyThe additional actions "connect:DescribeContactFlow" and "connect:SendOutboundEmail" are relevant to the Connect service and align with the statement's purpose. The resource scope remains appropriately limited to Connect instances.
24-35: Approved: EventBridgeListRuleAccess statement added with proper restrictionsThis new statement allows listing EventBridge rules while implementing a good security practice. The condition
"aws:ResourceAccount": "${aws:PrincipalAccount}"ensures that the role can only list rules within its own account, preventing potential cross-account access.
37-52: Approved: EventBridgeManagedResourceAccess statement added with proper restrictionsThis new statement allows managing EventBridge rules specifically for Connect Campaigns. The security considerations are well-implemented:
- The resource is limited to rules starting with "ConnectCampaignsRule".
- The condition ensures the role only affects resources in its own account.
- The
events:ManagedBycondition adds an extra layer of security, ensuring only rules managed by "connect-campaigns.amazonaws.com" are affected.These restrictions help prevent unintended modifications to other EventBridge rules.
54-65: Approved: EventBridgeListTargetsByRuleAccess statement added with proper restrictionsThis new statement allows listing targets for EventBridge rules specifically related to Connect Campaigns. The security considerations are well-implemented:
- The resource is limited to rules starting with "ConnectCampaignsRule".
- The condition ensures the role only accesses resources in its own account.
These restrictions help prevent unintended access to targets of other EventBridge rules.
67-78: Consider refining the resource scope for Wisdom actionsWhile the tag-based condition
"aws:ResourceTag/AmazonConnectCampaignsEnabled": "True"helps restrict access, using "*" as the resource might still be overly permissive.Consider if it's possible to further restrict the resource to a specific ARN pattern for Wisdom resources, such as:
"Resource": "arn:aws:wisdom:*:*:association/*"If a more specific resource pattern is not feasible due to service requirements, please confirm that this broad permission with the tag-based condition is indeed necessary.
docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (4)
24-37: Approve: New statement enhances tagging controlThe new "AllowGlueTaggingAction" statement is a positive addition to the policy. It allows for more granular control over tagging actions on Glue session resources. The conditions ensure that users can only tag resources they own, which is a good practice for maintaining proper resource ownership and preventing unauthorized tagging.
Line range hint
78-92: Approve: Consistent update to deny actionsThe removal of "glue:TagResource" from the "NotebookDenyActions" statement is consistent with the newly added "AllowGlueTaggingAction" statement. This change allows for tagging while still preventing untagging and other tag-related actions, providing a more flexible approach to resource tagging within the Glue service.
Line range hint
1-116: Summary: Enhanced tagging control and expanded role permissionsThe changes in this policy update provide more granular control over tagging actions for Glue session resources while expanding the scope of roles that can be passed to the Glue service. These updates enhance the policy's capability for resource management and align with AWS best practices for IAM policies.
Key improvements:
- Introduction of specific tagging permissions with owner-based conditions.
- Consistent updates to allow tagging while preventing untagging.
- Expanded role patterns for PassRole permissions.
These changes collectively contribute to better resource management and security in AWS Glue sessions.
106-107: Approve with verification: Expanded role pattern in PassRole permissionThe addition of the new resource ARN "arn:aws:iam:::role/AwsGlueSessionUserRestrictedNotebookServiceRole" expands the scope of roles that can be passed to the Glue service. This change aligns with the PR objective of updating AWS managed policies.
Please verify that this expansion is intentional and doesn't inadvertently grant excessive permissions. Run the following script to check for any existing roles matching this new pattern:
If no roles are found, consider documenting the purpose of this new role pattern for future reference.
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (6)
67-70: LGTM: Appropriate ECS and ECR restrictions addedThe addition of ECS creation actions and ECR authentication token retrieval to the deny list is appropriate for a compromised key quarantine policy. These restrictions prevent potential abuse of container services and align with the policy's security objectives.
71-75: LGTM: Comprehensive Bedrock service restrictions addedThe addition of Bedrock-related actions to the deny list is a prudent security measure. These restrictions prevent the creation and invocation of AI/ML models and related resources, which could potentially be misused in a compromised key scenario.
76-81: LGTM for SageMaker and S3 write actions, reconsider S3 read actionsThe addition of SageMaker creation actions and S3 write operations (CreateBucket, PutBucketCors) to the deny list is appropriate for a compromised key quarantine policy.
However, as previously noted, denying S3 read actions (GetObject, ListBucket) might hinder legitimate administrative tasks and incident response efforts. These read-only operations could be crucial for investigating the extent of a potential compromise.
Consider removing "s3:GetObject" and "s3:ListBucket" from the deny list unless there's a specific security concern that justifies their inclusion.
82-85: LGTM for STS actions, reconsider SES read actionsThe addition of STS actions (GetSessionToken, GetFederationToken) to the deny list is appropriate for a compromised key quarantine policy, as they prevent obtaining new credentials that could be misused.
However, as previously noted, the SES actions (GetSendQuota, ListIdentities) are read-only operations that don't pose a direct security risk. Denying these might hinder legitimate administrative tasks or incident response efforts.
Consider removing "ses:GetSendQuota" and "ses:ListIdentities" from the deny list, as they are read-only actions that could be useful for investigating the extent of a potential compromise.
86-92: LGTM for most additions, reconsider IAM:ListUsersThe additions for Amplify, CodeBuild, Glue, and most IAM actions are appropriate:
- Amplify, CodeBuild, and Glue actions prevent creating new resources.
- IAM
DeleteRoleandDeleteAccessKeyprevent destructive actions on access controls.However, as previously noted, including
iam:ListUsersin the deny list might hinder legitimate administrative tasks during incident response. Consider removing this action from the deny list, as it's a read-only operation that could be useful for security teams investigating the compromise.Suggest removing
iam:ListUsersfrom the deny list to facilitate incident response activities.
93-95: Approve MediaPackage action, query Lambda and SNS inclusionsThe addition of
mediapackagev2:CreateChannelis appropriate as it prevents the creation of new resources, aligning with the quarantine policy's purpose.However, as previously noted, the inclusion of
lambda:GetEventSourceMappingandsns:GetSMSAttributesraises questions:
- These are read-only actions that don't modify resources or escalate privileges.
- Denying these actions might hinder incident response efforts by restricting access to potentially useful information.
Recommend removing
lambda:GetEventSourceMappingandsns:GetSMSAttributesfrom the deny list unless there's a compelling reason to include them.docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (6)
Line range hint
49-61: Approve S3GetActionConditionalResourceAndADXThe "S3GetActionConditionalResourceAndADX" statement demonstrates good security practices:
- It grants specific permission (S3:GetObject) rather than using wildcards.
- The resource is restricted to S3 buckets containing "aws-data-exchange" in the name, limiting the scope.
- The condition ensures the action is called via the Data Exchange service, adding an extra layer of security.
These measures collectively enhance the policy's security while maintaining necessary functionality.
Line range hint
124-133: Review resource scope for KMSActionsThe "KMSActions" statement grants necessary read-only permissions for KMS operations, which are typically required for working with encrypted resources. However, consider the following:
- If possible, restrict the resource scope to specific KMS key ARNs used in Data Exchange operations, rather than using "*".
- If specific key ARNs cannot be determined, consider using a condition to restrict access to keys with a specific tag related to Data Exchange.
To identify the specific KMS keys used in Data Exchange operations, analyze the CloudTrail logs with the following command:
#!/bin/bash # List KMS keys accessed in relation to Data Exchange operations aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=dataexchange.amazonaws.com | jq '.Events[] | select(.Resources[].Type == "AWS::KMS::Key") | .Resources[].ResourceName' | sort | uniqUse the results to refine the resource scope in the policy, enhancing security by adhering to the principle of least privilege.
Line range hint
104-123: Review AWSMarketplaceActions permissionsThe "AWSMarketplaceActions" statement grants various permissions for AWS Marketplace operations, which are likely necessary for Data Exchange providers. However, consider the following suggestions:
- Review each permission to ensure it's necessary for Data Exchange operations. Remove any that are not required.
- For permissions that can modify Marketplace listings (e.g.,
aws-marketplace:StartChangeSet,aws-marketplace:CancelChangeSet), consider adding conditions to restrict their use. For example, you could limit these actions to specific IP ranges or require multi-factor authentication.To identify which Marketplace actions are actually being used, analyze the CloudTrail logs with the following command:
#!/bin/bash # List AWS Marketplace actions used in relation to Data Exchange operations aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=aws-marketplace.amazonaws.com | jq '.Events[].EventName' | sort | uniqUse the results to refine the permissions in the policy, adhering to the principle of least privilege.
Line range hint
134-162: Approve Redshift and API Gateway actions with suggestionsThe statements for Redshift and API Gateway actions demonstrate good security practices:
- "RedshiftConditionalActions" is well-restricted with a condition limiting the consumer identifier to "ADX".
- "RedshiftActions" and "APIGatewayActions" grant only specific, necessary permissions.
Consider the following enhancements:
- For "RedshiftActions", if possible, restrict the resource scope to specific Redshift cluster ARNs used in Data Exchange operations, rather than using "*".
- For "APIGatewayActions", consider adding a condition to restrict access to API Gateway resources related to Data Exchange, if applicable.
To identify specific Redshift clusters and API Gateway resources used in Data Exchange operations, analyze the CloudTrail logs:
#!/bin/bash # List Redshift clusters accessed in relation to Data Exchange operations aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=dataexchange.amazonaws.com | jq '.Events[] | select(.Resources[].Type == "AWS::Redshift::Cluster") | .Resources[].ResourceName' | sort | uniq # List API Gateway resources accessed in relation to Data Exchange operations aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=dataexchange.amazonaws.com | jq '.Events[] | select(.Resources[].Type == "AWS::ApiGateway::RestApi") | .Resources[].ResourceName' | sort | uniqUse the results to further refine the resource scopes or add conditions in the policy, enhancing security by adhering to the principle of least privilege.
Line range hint
5-25: Review broad permissions in DataExchangeActionsThe "DataExchangeActions" statement grants comprehensive permissions for AWS Data Exchange operations. While this aligns with the "FullAccess" nature of the policy, consider the following security best practices:
- Review the use of wildcard permissions (e.g., "Get*", "Update*", "List*", "Delete*"). If possible, explicitly list the required actions to adhere to the principle of least privilege.
- The "Resource": "*" allows these actions on all resources. Consider restricting this to specific resource ARNs if applicable.
To help identify the minimum required permissions, you can analyze the CloudTrail logs for the actual actions used. Run the following command:
This will help in refining the policy to include only necessary permissions.
Line range hint
94-103: Review resource scope for S3ReadActionsThe "S3ReadActions" statement grants necessary read permissions for S3 operations. However, the broad resource scope ("*") might grant more access than required. Consider the following:
- If possible, restrict the
s3:ListBucketaction to specific bucket ARNs related to Data Exchange operations.- The
s3:ListAllMyBucketspermission might not be necessary for Data Exchange operations. Consider removing it if not explicitly required.To identify the specific buckets used in Data Exchange operations, you can analyze the CloudTrail logs. Run the following command:
Use the results to refine the resource scope in the policy.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4)
80-87: LGTM: Enhanced Customer Profiles capabilitiesThe new permissions added to the "AllowCustomerProfilesForConnectDomain" statement expand the capabilities for managing customer profiles and segmentation. These additions include:
- Listing integrations and segment definitions
- Listing profile attribute values
- Creating and getting segment estimates
- Batch operations for profiles and calculated attributes
- Getting segment membership
These changes align with the PR objective of updating AWS managed policies and enhance the functionality of Amazon Connect with Customer Profiles.
96-97: LGTM: Added permission to list object type attributesThe addition of the "profile:ListObjectTypeAttributes" permission to the "AllowReadPermissionForCustomerProfileObjects" statement enhances the read capabilities for Customer Profile objects. This new permission allows listing attributes of object types, which complements the existing abilities to list profile objects and get profile object types.
149-163: LGTM: Expanded Wisdom capabilities for message template managementThe "AllowWisdomForConnectEnabledTaggedResources" statement has been significantly enhanced with new permissions for managing message templates in Amazon Connect Wisdom. These additions allow for:
- Creating, updating, and deleting message templates
- Managing message template metadata and versions
- Activating and deactivating templates
- Creating and deleting template attachments
- Rendering message templates
These changes align with the PR objective of updating AWS managed policies and greatly expand the functionality available for content management within the Wisdom service.
As noted in a previous review comment, please ensure that the project documentation is updated to reflect these new Wisdom message template capabilities.
195-208: LGTM: New permissions for Customer Profiles segmentationA new statement "AllowCustomerProfilesSegmentationForConnectDomain" has been added to the policy. This statement introduces permissions for managing segment definitions and snapshots in Customer Profiles, including:
- Creating, getting, and deleting segment definitions
- Creating and getting segment snapshots
These new permissions are properly scoped to the Amazon Connect domain and enhance the segmentation capabilities of the Customer Profiles service. This addition aligns with the PR objective of updating AWS managed policies and complements the existing Customer Profiles permissions in the policy.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (6)
Line range hint
128-137: Well-scoped SSM parameter access for ECSThe SSMPolicy statement is well-defined and follows security best practices:
- It allows only read actions (
GetParameter,GetParameters,GetParametersByPath).- The resource scope is appropriately limited to ECS-related parameters.
This policy statement adheres to the principle of least privilege and is approved.
169-180: Well-defined InfrastructurePassRolePolicyThis policy statement is excellently scoped and follows security best practices:
- It allows passing only a specific role ("ecsInfrastructureRole").
- The passed role is limited to a specific service (ECS).
- It uses a strict condition with "StringEquals" rather than a more permissive "StringLike".
This policy statement adheres to the principle of least privilege and is approved without any suggestions for improvement.
Line range hint
181-197: Approve well-scoped InstancePassRolePolicyThis policy statement is well-defined and follows security best practices:
- It allows passing only roles specifically named for ECS instances (prefix "ecsInstanceRole").
- The passed roles are limited to the EC2 service, including both global and China regions.
- It uses "StringLike" appropriately to allow for variations in the role name while still maintaining the required prefix.
This policy statement provides the necessary permissions for EC2 instances in ECS to assume roles while adhering to the principle of least privilege. It is approved without any suggestions for improvement.
Line range hint
198-213: Approve well-defined AutoScalingPassRolePolicyThis policy statement is well-structured and follows security best practices:
- It allows passing only roles specifically named for ECS Auto Scaling (prefix "ecsAutoscaleRole").
- The passed roles are limited to the Application Auto Scaling service, including both global and China regions.
- It uses "StringLike" appropriately to allow for variations in the role name while still maintaining the required prefix.
This policy statement provides the necessary permissions for ECS Auto Scaling to assume roles while adhering to the principle of least privilege. It is approved without any suggestions for improvement.
Line range hint
214-230: Approve ServiceLinkedRoleCreationPolicy with expanded service coverageThis policy statement allows the creation of service-linked roles for specific AWS services related to ECS operations. The policy is well-structured:
- It limits the action to only creating service-linked roles.
- It uses a condition to restrict the services for which roles can be created.
- The list of services has been expanded to include Auto Scaling and Spot-related services, which are relevant to ECS operations.
The expansion of services (lines 222-225) is appropriate and consistent with ECS functionality, particularly for managing capacity and cost optimization through Auto Scaling and Spot instances.
This policy statement is approved as it provides necessary permissions while maintaining proper scope.
Line range hint
231-248: Approve well-structured ELBTaggingPolicyThis policy statement is well-defined and follows best practices for resource management:
- It allows only the
AddTagsaction for Elastic Load Balancing resources.- The condition limits tagging to specific creation actions (CreateTargetGroup, CreateRule, CreateListener, CreateLoadBalancer).
- This ensures that tags can be added only during resource creation, preventing unintended modifications to existing resources.
The policy supports proper resource organization and management in the context of ECS operations involving Elastic Load Balancing. It is approved without any suggestions for improvement.
docs/source/_static/managed-policies/AWS_ConfigRole.json (8)
32-43: LGTM: New permissions for Amazon OpenSearch Service (AOSS) addedThese new permissions allow AWS Config to access and evaluate AOSS resources, which is consistent with the role's purpose. This addition enhances AWS Config's ability to monitor and assess the configuration of AOSS components.
89-89: LGTM: New AppStream permission addedThe addition of "appstream:DescribeAppBlockBuilders" permission is consistent with the existing AppStream permissions in the policy. This allows AWS Config to gather information about AppBlockBuilders in AppStream, enhancing its monitoring capabilities.
136-137: LGTM: New AWS Backup permissions for restore testing addedThese new permissions allow AWS Config to access information about restore testing plans and selections in AWS Backup. This addition enhances Config's ability to monitor and assess the configuration of backup and restore processes, which is crucial for ensuring data recoverability.
Also applies to: 144-145
185-185: LGTM: New CloudTrail permissions for channels addedThe addition of "cloudTrail:GetChannel" and "cloudTrail:ListChannels" permissions allows AWS Config to access information about CloudTrail channels. This enhances Config's ability to monitor and assess CloudTrail configurations, which is important for maintaining a comprehensive audit trail of AWS account activity.
Also applies to: 189-189
568-568: LGTM: New AWS Glue permissions for triggers addedThe addition of "glue:GetTrigger" and "glue:ListTriggers" permissions allows AWS Config to access information about Glue triggers. This enhances Config's ability to monitor and assess Glue configurations, which is important for maintaining visibility into ETL processes and workflows.
Also applies to: 574-574
676-676: LGTM: New AWS IoT permissions for billing groups addedThe addition of "iot:DescribeBillingGroup" and "iot:ListBillingGroups" permissions allows AWS Config to access information about IoT billing groups. This enhances Config's ability to monitor and assess IoT configurations, including billing-related aspects, which is important for cost management and resource organization in IoT deployments.
Also applies to: 693-693
769-782: LGTM: New permissions added for IVS, MediaConnect, MediaTailor, and Omics servicesThese additions grant AWS Config the necessary permissions to access and evaluate resources in Amazon IVS (Interactive Video Service), MediaConnect, MediaTailor, and Omics. The new permissions include operations like Describe, Get, and List for various resources within these services. This expansion of permissions allows AWS Config to provide more comprehensive monitoring and compliance checking across a wider range of AWS services, enhancing its ability to ensure proper configuration and security practices.
Also applies to: 905-910, 917-926, 970-971
Line range hint
1-1399: Summary: AWS Config Role Policy Successfully UpdatedThis review has examined all the new permissions added to the AWS_ConfigRole.json file. The changes consistently expand AWS Config's ability to monitor and assess configurations across a wide range of AWS services, including AOSS, AppStream, AWS Backup, CloudTrail, Glue, IoT, IVS, MediaConnect, MediaTailor, and Omics. These additions align well with the PR objective of updating AWS managed policies and enhance AWS Config's capability to provide comprehensive configuration and compliance monitoring across the AWS ecosystem.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (5)
32-43: New permissions added for Amazon OpenSearch Service (AOSS)These new permissions allow AWS Config to interact with AOSS resources, enabling it to assess and monitor the configuration of AOSS collections, lifecycle policies, VPC endpoints, access policies, and security configurations. The added permissions are read-only, which is appropriate for AWS Config's role in monitoring and auditing resource configurations.
135-136: New permissions added for AWS Backup restore testingThese new permissions enable AWS Config to assess and monitor AWS Backup restore testing plans and selections. This addition enhances AWS Config's ability to evaluate disaster recovery readiness, which is crucial for maintaining robust backup strategies. The permissions are appropriately scoped to read-only operations, maintaining the principle of least privilege.
Also applies to: 143-144
88-88: Extended monitoring capabilities for AppStream, Glue, and IVS servicesThis update expands AWS Config's ability to monitor and assess configurations across multiple services:
- AppStream: Added permission to describe app block builders.
- Glue: New permissions to get and list triggers.
- IVS (Interactive Video Service): Added permissions to describe and list various IVS resources such as encoder configurations, playback restriction policies, stages, and storage configurations.
These additions enhance AWS Config's coverage and ability to provide a comprehensive view of resource configurations across the AWS environment. All new permissions are read-only, maintaining the principle of least privilege and aligning with Config's monitoring and auditing role.
Also applies to: 566-572, 767-780
184-188: Additional monitoring capabilities for various AWS servicesThis update further expands AWS Config's monitoring capabilities across several AWS services:
- CloudTrail: Added permissions to get and list channels.
- MediaConnect: New permissions to describe bridges and gateways, and list related resources.
- MediaTailor: Added permissions to describe channels, live sources, source locations, and VOD sources, as well as list these resources.
- Omics: New permissions to get and list workflows.
- Scheduler: Added permissions to get and list schedules.
These additions enhance AWS Config's ability to provide a more comprehensive view of resource configurations across a wider range of AWS services. All new permissions are read-only, which is appropriate for Config's monitoring and auditing role, and maintains the principle of least privilege.
Also applies to: 903-908, 915-924, 968-969, 1254-1255
Line range hint
1-1437: Summary of AWSConfigServiceRolePolicy updatesThis policy update significantly expands AWS Config's capabilities to monitor and assess configurations across a wide range of AWS services. The new permissions added are consistently read-only, which aligns perfectly with AWS Config's primary function of resource configuration assessment and auditing.
Key areas of expansion include:
- Amazon OpenSearch Service (AOSS)
- AWS Backup restore testing
- AppStream, Glue, and IVS services
- CloudTrail, MediaConnect, MediaTailor, Omics, and Scheduler services
These changes will enable more comprehensive monitoring and compliance checking across the AWS environment. The principle of least privilege is maintained throughout the updates, as all new permissions are scoped to non-destructive, read-only operations.
Overall, these policy updates enhance AWS Config's functionality without introducing additional security risks.
docs/source/_static/managed-policies/ReadOnlyAccess.json (8)
111-111: Approved: Consistent read-only permission addedThe addition of "application-signals:ListServices" is appropriate for a ReadOnlyAccess policy as it only allows listing services, which is a read operation.
222-225: Approved: Consistent read-only permissions added for bedrock serviceThe additions of various "bedrock:Get*" and "bedrock:List*" permissions are appropriate for a ReadOnlyAccess policy. These operations allow read-only access to bedrock resources, which aligns with the policy's intent.
Also applies to: 239-242
275-275: Approved: Consistent read-only permission added for budgets serviceThe addition of "budgets:ListTagsForResource" is appropriate for a ReadOnlyAccess policy as it only allows listing tags, which is a read operation.
303-303: Approved: Consistent read-only permission added for Cost Explorer serviceThe addition of "ce:ListCostAllocationTags" is appropriate for a ReadOnlyAccess policy as it only allows listing cost allocation tags, which is a read operation.
318-328: Approved: Consistent read-only permissions added for cleanrooms-ml serviceThe additions of various "cleanrooms-ml:Get*" and "cleanrooms-ml:List*" permissions are appropriate for a ReadOnlyAccess policy. These operations allow read-only access to cleanrooms-ml resources, which aligns with the policy's intent.
1922-1938: Approved: Consistent read-only permissions added for s3-outposts serviceThe additions of various "s3-outposts:Get*" and "s3-outposts:List*" permissions are appropriate for a ReadOnlyAccess policy. These operations allow read-only access to s3-outposts resources, which aligns with the policy's intent.
1973-1974: Approved: Consistent read-only permissions added for multiple servicesThe additions of various "Get*" and "List*" permissions for securityhub, ssm-sap, trustedadvisor, and user-subscriptions services are appropriate for a ReadOnlyAccess policy. These operations allow read-only access to resources, which aligns with the policy's intent.
Also applies to: 2072-2082, 2165-2175
Line range hint
1-2175: Summary: All additions to the ReadOnlyAccess policy are appropriateAfter reviewing all the additions to the ReadOnlyAccess policy, I can confirm that they are all consistent with the policy's intent. The new permissions only grant read-only access to various AWS services and resources, including application-signals, bedrock, budgets, cost explorer, cleanrooms-ml, s3-outposts, securityhub, ssm-sap, trustedadvisor, and user-subscriptions. These changes enhance the policy's coverage while maintaining its read-only nature.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (6)
87-88: Approved: Enhanced account and autoscaling permissionsThe new permissions added for account management and autoscaling are appropriate for the AWS Support Service Role:
account:getRegionOptStatusandaccount:listRegions: These allow the support role to check region opt-in status and list available regions, which is useful for diagnosing region-related issues.autoscaling:describeTrafficSources: This enables the role to retrieve information about traffic sources for autoscaling groups, aiding in autoscaling-related support tasks.These additions will improve the support team's ability to assist with account configuration and autoscaling concerns.
Also applies to: 264-264
547-558: Approved: New CodeConnections permissions enhance DevOps supportThe policy now includes several new permissions for the AWS CodeConnections service, which are appropriate for the AWS Support Service Role:
- These permissions allow retrieving information about connections, hosts, repository links, and sync configurations.
- They enable listing of various CodeConnections resources.
These read-only permissions will empower the support team to assist with CodeConnections-related inquiries, troubleshooting CI/CD workflow issues, and diagnosing problems with source control integrations. This addition aligns well with AWS's focus on improving DevOps and CI/CD capabilities.
786-802: Approved: New Deadline permissions improve render farm supportThe policy now includes several new permissions for the AWS Deadline service, which are appropriate for the AWS Support Service Role:
- These permissions allow listing various Deadline resources such as workers, render queues, render jobs, farms, fleets, and budgets.
- All added permissions are read-only "list" operations, maintaining the principle of least privilege for the support role.
These additions will enable the support team to assist customers using AWS Thinkbox Deadline for render farm management and batch processing workflows. Support agents will be able to view necessary information to troubleshoot issues related to rendering jobs, resource allocation, and farm configuration.
1018-1018: Approved: Expanded permissions across various AWS servicesThe policy includes new permissions for several AWS services, enhancing the support role's capabilities:
- EC2: Added
describeSnapshotTierStatusandgetSubnetCidrReservationsfor improved EC2 resource management.- EKS: New permissions for managing pod identity associations.
- Elasticloadbalancing: Added trust store-related permissions for enhanced load balancer management.
- Freetier: Included
getFreeTierUsagefor better cost management support.- Inspector2: New permissions for configuration and deep inspection capabilities.
- OSIS: Added permissions for pipeline management in OpenSearch Ingestion.
- Workspaces: New permissions for describing application and workspace associations.
- X-Ray: Expanded permissions for advanced monitoring and tracing capabilities.
These additions will allow the support team to provide more comprehensive assistance across a wide range of AWS services, improving their ability to diagnose and resolve customer issues.
Also applies to: 1064-1064, 1143-1144, 1210-1212, 1343-1343, 2295-2300, 3355-3356, 3368-3374
Line range hint
1-3374: Overall policy update enhances support capabilities across AWS servicesThis update to the AWSSupportServiceRolePolicy significantly expands the capabilities of the AWS Support Service Role across numerous AWS services. Key points to note:
- New permissions have been added for emerging services like AWS Bedrock (AI/ML) and CodeConnections (DevOps).
- Existing service permissions have been expanded to cover new features and functionalities.
- All added permissions are read-only, maintaining the principle of least privilege.
These changes will enable the AWS support team to provide more comprehensive and effective assistance to customers using a wide range of AWS services. However, given the broad scope of these permissions, it's recommended to:
- Regularly review the usage patterns of these permissions to ensure they align with current support requirements.
- Conduct periodic audits to identify any permissions that may no longer be necessary.
- Consider implementing more granular access controls or conditional statements if certain permissions are only required in specific scenarios.
To assist with ongoing management of this policy, periodically run the following script:
#!/bin/bash # Description: Analyze permission usage for the AWSSupportServiceRolePolicy # Get the policy ARN POLICY_ARN=$(aws iam list-policies --query 'Policies[?PolicyName==`AWSSupportServiceRolePolicy`].Arn' --output text) # Generate a report of permission usage aws iam generate-service-last-accessed-details --arn $POLICY_ARN # Wait for the report to be generated (adjust sleep time if needed) sleep 30 # Get the report ID REPORT_ID=$(aws iam list-service-last-accessed-details --arn $POLICY_ARN --query 'JobId' --output text) # Fetch and display the report aws iam get-service-last-accessed-details --job-id $REPORT_ID echo "Review the output to identify unused permissions that could potentially be removed from the policy."This script will help identify permissions that are not being actively used, allowing for potential policy refinement in the future.
324-345: Approved: Comprehensive Bedrock permissions addedThe policy now includes a wide range of permissions for AWS Bedrock, Amazon's new foundation model service. These additions are appropriate for the AWS Support Service Role, as they allow:
- Retrieval of information about Bedrock agents, models, knowledge bases, and customization jobs.
- Listing of various Bedrock resources.
These read-only permissions will enable the support team to assist with Bedrock-related inquiries and issues effectively. However, given the breadth of these permissions, it's recommended to:
- Regularly review the usage of these permissions to ensure they align with support requirements.
- Consider implementing more granular access controls if certain Bedrock features are not commonly needed in support scenarios.
To ensure these permissions are necessary, please run the following script to check for Bedrock-related support cases:
✅ Verification successful
To verify the necessity of the newly added Bedrock permissions, please run the following script to search the codebase for any references to "Bedrock":
Verified: Bedrock permissions are necessary
The search results confirm that AWS Bedrock is actively referenced within the codebase, including in policy statements and generated configurations. Therefore, the added Bedrock permissions are justified and required for the AWS Support Service Role to operate effectively.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for Bedrock-related support cases in the last 30 days # Note: This script assumes the AWS CLI is configured with appropriate permissions echo "Checking for Bedrock-related support cases in the last 30 days:" aws support describe-cases --include-resolved-cases --after-time $(date -d "30 days ago" +%Y-%m-%d) \ --query 'cases[?contains(subject, `Bedrock`) || contains(recentCommunications.body, `Bedrock`)].{CaseId:caseId, Subject:subject}' \ --output table echo "If there are no results, consider reviewing the necessity of all Bedrock permissions."Length of output: 826
Script:
#!/bin/bash # Description: Search the codebase for Bedrock usage to verify its necessity for support operations. echo "Searching for 'Bedrock' references in the codebase:" rg 'Bedrock' --files-with-matches echo "Review the listed files to determine if Bedrock is actively used in support scenarios."Length of output: 887
udondan
force-pushed
the
update-aws-managed-policies
branch
from
5e5a481
to
4ab15dd
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (5)
docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessQueues.json (1)
145-145: LGTM! Consider updating documentation.The additions of
deadline:GetJobTemplateanddeadline:ListJobParameterDefinitionsto the "AllLevelsPermissions" statement are appropriate and consistent with the existing permissions. These read-only operations enhance the capabilities for all user levels without introducing security risks.Consider updating any relevant documentation or README files to reflect these new permissions, ensuring that users and administrators are aware of the expanded capabilities for all membership levels.
Also applies to: 154-154
docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessFarms.json (1)
Line range hint
165-176: LGTM! Consider reordering actions for better readability.The addition of
deadline:GetJobTemplateanddeadline:ListJobParameterDefinitionsactions to the "AllLevelsPermissions" statement is appropriate and aligns with the PR objectives. These read-only operations enhance the capabilities of users across all membership levels without introducing significant security risks.For improved readability and maintainability, consider grouping similar actions together. You might want to move
deadline:ListJobParameterDefinitionsnext to other "List" actions. Here's a suggested reordering:"deadline:GetJob", "deadline:GetJobTemplate", "deadline:GetQueue", "deadline:GetQueueEnvironment", "deadline:GetQueueFleetAssociation", "deadline:GetSession", "deadline:GetSessionAction", "deadline:GetStep", "deadline:GetStorageProfile", "deadline:GetStorageProfileForQueue", "deadline:GetTask", "deadline:GetWorker", -"deadline:ListJobParameterDefinitions", "deadline:ListQueueEnvironments", "deadline:ListQueueFleetAssociations", +"deadline:ListJobParameterDefinitions", "deadline:ListSessionActions", "deadline:ListSessions", "deadline:ListSessionsForWorker",docs/source/_static/managed-policies/AmazonECS_FullAccess.json (1)
Line range hint
156-168: Appropriate PassRole policy for ECS tasks with room for improvementThe "TasksPassRolePolicy" statement correctly allows the
iam:PassRoleaction, which is necessary for assigning IAM roles to ECS tasks. The condition appropriately restricts this action to the ECS tasks service (ecs-tasks.amazonaws.com), which is a good security measure.However, the Resource is set to "*", which allows passing any IAM role. While this might be necessary for flexibility, consider if it's possible to scope this down to specific role ARNs or patterns used for ECS tasks to further enhance security.
Consider refining the Resource field to specific role ARNs or patterns used for ECS tasks if possible, to adhere more closely to the principle of least privilege.
docs/source/_static/managed-policies/SecurityAudit.json (1)
Line range hint
1-724: Summary of changes to SecurityAudit policyThe changes to the SecurityAudit policy expand its scope to include:
- Access to the account's primary email address.
- Read-only access to various resources and configurations within the Amazon Q service (formerly Amazon QuickSight Q).
These additions are consistent with the policy's purpose of providing read-only access for security auditing. However, given the significant expansion of permissions for the qbusiness service, it would be beneficial to add a comment explaining this addition.
Consider adding a comment at the beginning of the policy or in the associated documentation to explain the inclusion of Amazon Q (qbusiness) permissions. For example:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "BaseSecurityAuditStatement", "Effect": "Allow", // This policy now includes permissions for auditing Amazon Q (qbusiness) resources "Action": [ // ... existing actions ... ], // ... rest of the policy ... } ] }This comment would help future readers understand the context of these additions.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (1)
Line range hint
1-3374: Consider a holistic review of the expanded AWSSupportServiceRolePolicy.This update significantly broadens the AWS Support Service Role's access across various services, including account management, Auto Scaling, Bedrock (AI/ML), CodeConnections (CI/CD), Deadline (rendering and simulation), OSIS (Open Search Ingestion), and X-Ray (application performance monitoring). While these additions enhance support capabilities, they also increase the policy's complexity and potential attack surface.
Recommendations:
- Conduct a comprehensive review to ensure all permissions adhere to the principle of least privilege.
- Consider implementing a regular review process (e.g., quarterly) to assess the necessity of each permission.
- Evaluate the possibility of creating more granular roles for specialized support tasks, rather than expanding a single role.
- Implement strong monitoring and alerting for the usage of sensitive permissions, especially those related to AI/ML services like Bedrock.
To assist in ongoing management of this policy, consider implementing an automated policy review system that can:
- Track permission usage over time.
- Flag permissions that haven't been used in a specified period.
- Compare this policy against best practice templates for support roles.
- Generate regular reports on policy changes and their potential impact on security posture.
📜 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 (63)
- 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/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/AWSDataExchangeProviderFullAccess.json (11 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/AWSIAMIdentityCenterAllowListForIdentityContext.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 (1 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/AWSSupportPlansFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 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 (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.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/AmazonECS_FullAccess.json (8 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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/SecurityAudit.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 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 (45)
- 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/AWSCompromisedKeyQuarantineV3.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataFullAccess.json
- docs/source/_static/managed-policies/AWSDirectoryServiceDataReadOnlyAccess.json
- docs/source/_static/managed-policies/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.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/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.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/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.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/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
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
🧰 Additional context used
🔇 Additional comments (78)
docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (5)
Line range hint
1-45: Overall policy update enhances functionality while maintaining read-only accessThe changes to this policy align well with the PR objectives of updating AWS managed policies. The policy has been expanded to include read-only access to additional services (WorkSpaces, WorkSpaces Web, and AppStream) while maintaining its overall read-only nature. This enhancement provides a more comprehensive set of permissions for managing Amazon WorkSpaces Thin Client environments.
However, there are a few points to consider:
- The broadening of the Resource specification in the "AllowThinClientReadAccess" statement from a specific ARN to a wildcard "*" should be reviewed to ensure it aligns with the principle of least privilege.
- For all new statements, verify if the use of wildcard "*" for Resource is necessary or if more specific ARNs can be used.
These considerations will help ensure that the policy provides the necessary access while maintaining tight security controls.
To assist in verifying the resource specifications, I've provided shell commands in the previous comments. Please review the results of these commands to determine if more specific resource ARNs can be used in any of the policy statements.
27-36: New "AllowWorkSpacesWebAccess" statement enhances functionalityThe addition of this statement granting permissions for WorkSpaces Web actions (
GetPortal,GetUserSettings,ListPortals) extends the policy's scope while maintaining its read-only nature.Consider if the Resource can be more specific than "*":
#!/bin/bash # Check if other policies use more specific resources for these WorkSpaces Web actions rg -e '"workspaces-web:GetPortal"' -e '"workspaces-web:GetUserSettings"' -e '"workspaces-web:ListPortals"' -C 5 --type json | grep -C 5 'Resource'
37-43: New "AllowAppStreamAccess" statement is appropriateThe addition of this statement granting permission for
appstream:DescribeStacksextends the policy's functionality while maintaining its read-only nature.Confirm if the wildcard "*" for Resource is necessary or if it can be more specific:
#!/bin/bash # Check if other policies use more specific resources for this AppStream action rg '"appstream:DescribeStacks"' -C 5 --type json | grep -C 5 'Resource'
19-26: New "AllowWorkSpacesAccess" statement looks goodThe addition of this statement granting permission for
workspaces:DescribeWorkspaceDirectoriesaligns with the policy's read-only nature and enhances its functionality.Verify if the wildcard "*" for Resource is necessary or if it can be more specific:
#!/bin/bash # Check if other policies use more specific resources for this action rg '"workspaces:DescribeWorkspaceDirectories"' -C 5 --type json | grep -C 5 'Resource'
9-10: Review the changes in the "AllowThinClientReadAccess" statement
The reordering of actions
thinclient:GetEnvironmentandthinclient:GetSoftwareSetimproves readability but doesn't affect functionality.The Resource specification has been changed from a specific ARN format to a wildcard "*". This broadens the scope of accessible resources.
Please confirm if this broader access is intentional and aligns with the principle of least privilege. Consider using more specific resource ARNs if possible.
Also applies to: 13-13, 17-17
✅ Verification successful
Wildcard resource specification is common but consider narrowing scope if possible
The use of "Resource": "*" in the AmazonWorkSpacesThinClientReadOnlyAccess policy is consistent with many other AWS managed policies. While this provides flexibility, it may grant broader read access than necessary. Consider the following:
The wildcard resource is common in read-only policies, reducing the risk compared to policies with write permissions.
No specific ARNs for thinclient resources were found in other policies, suggesting that narrowing the scope might not be straightforward.
If possible, work with the AWS WorkSpaces team to identify if more granular resource specifications can be implemented without breaking functionality.
Given this is a read-only policy, the current implementation likely balances functionality and security adequately.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any other policies using specific ARNs for thinclient resources rg 'arn:aws:thinclient:' --type jsonLength of output: 5639
Script:
#!/bin/bash # Corrected script to search for thinclient-specific ARNs in JSON policies rg 'arn:aws:thinclient:' --type jsonLength of output: 36
Script:
#!/bin/bash # Additional script to search for wildcard resources in IAM policies rg '"Resource": "\*"' --type jsonLength of output: 231931
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (7)
5-11: Approve new statement with clarification request.The new statement "ConnectCampaignAccess" allows listing campaigns across all resources. While this might be necessary for the service-linked role, the broad scope ("Resource": "*") could potentially grant more access than needed.
Could you please clarify if this broad access is intentional and necessary for the service-linked role's functionality? If possible, consider restricting the resource scope to enhance security.
13-22: Approve updated "ConnectAccess" statement.The changes to the "ConnectAccess" statement appropriately expand the permissions for the Connect service while maintaining a specific resource scope. The added actions "connect:DescribeContactFlow" and "connect:SendOutboundEmail" align with the functionality typically required for Connect campaigns.
24-35: Approve new "EventBridgeListRuleAccess" statement.The new statement appropriately grants permission to list EventBridge rules while implementing a security best practice by restricting access to the principal's own account. This addition enhances the policy's functionality for managing EventBridge rules related to Connect campaigns.
37-52: Approve new "EventBridgeManagedResourceAccess" statement.This new statement grants appropriate permissions for managing EventBridge rules specific to Connect campaigns. The resource pattern restriction and conditions ensure that these permissions are applied only to relevant rules and within the correct account. This addition enhances the policy's capability to manage campaign-related EventBridge rules while maintaining security.
54-65: Approve new "EventBridgeListTargetsByRuleAccess" statement.This new statement appropriately grants permission to list targets for EventBridge rules specific to Connect campaigns. The resource pattern restriction and account condition ensure that these permissions are applied only to relevant rules and within the correct account. This addition complements the other EventBridge-related permissions in the policy.
67-78: Approve new "AllowWisdomForConnectCampaignsEnabledTaggedResources" statement with clarification request.This new statement grants permissions for Wisdom actions on resources tagged as Connect Campaigns enabled, which aligns with the policy's purpose. The tag-based condition is a good practice for ensuring these permissions are only applied to relevant resources.
However, the broad resource scope ("Resource": "*") could potentially grant more access than needed.
Could you please clarify if this broad resource scope is intentional and necessary? If possible, consider restricting the resource scope to enhance security while still meeting the requirements for Connect Campaigns functionality.
Line range hint
1-81: Overall policy update enhances functionality and maintains security.The changes to this policy document effectively expand the permissions for Amazon Connect Campaigns Service Linked Role, aligning with the PR objectives. The additions related to EventBridge and Wisdom integrate well with the existing Connect permissions, providing a comprehensive set of capabilities for managing campaigns.
Most of the changes follow good security practices by implementing specific resource patterns and conditions. However, there are two instances (in the "ConnectCampaignAccess" and "AllowWisdomForConnectCampaignsEnabledTaggedResources" statements) where broad resource scopes are used. While these may be necessary for the service-linked role's functionality, it would be beneficial to have clarification on these broad scopes to ensure they align with the principle of least privilege.
Overall, this update significantly enhances the policy's capabilities while maintaining a good security posture.
docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (4)
24-37: Approved: New statement allows controlled tagging of Glue session resourcesThis new statement, "AllowGlueTaggingAction", enhances resource management capabilities by allowing users to tag their Glue session resources. The conditions ensure that users can only tag resources they own, maintaining proper access control. This change aligns with the PR objective of updating AWS managed policies and follows AWS best practices for fine-grained permissions.
Line range hint
78-93: Approved: Removed tagging restriction aligns with new permissionsThe "NotebookDenyActions" statement has been updated to remove the "glue:TagResource" action from the list of denied actions. This change is consistent with the new "AllowGlueTaggingAction" statement and allows for more flexible resource management. The statement still denies untagging and other tagging actions, maintaining necessary restrictions to prevent unauthorized tag modifications.
Line range hint
1-116: Summary: Positive enhancements to AWS Glue policyThe changes made to this AWS Glue policy file are well-structured and align with the PR objectives. They enhance resource management capabilities by allowing controlled tagging of Glue session resources, remove unnecessary restrictions, and provide more flexibility in role management. These updates maintain security through appropriate conditions and restrictions.
Key improvements:
- New "AllowGlueTaggingAction" statement enables controlled resource tagging.
- Removal of tagging restriction in "NotebookDenyActions" aligns with the new permissions.
- Extended role pattern in "NotebookPassRole" provides more flexibility in role naming.
These changes collectively improve the policy's functionality while adhering to AWS best practices for IAM policies.
106-107: Approved: Extended role pattern for iam:PassRole actionThe "NotebookPassRole" statement has been updated to include an additional resource ARN pattern: "arn:aws:iam:::role/AwsGlueSessionUserRestrictedNotebookServiceRole". This change provides more flexibility in role naming while maintaining the necessary prefix for Glue session user roles. The condition still ensures that the role can only be passed to the Glue service, preserving security.
To ensure this change is used correctly, please run the following script to verify the usage of the new role pattern:
This script will help identify any existing roles or Glue session configurations that may be affected by or benefit from this policy change.
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (7)
67-70: LGTM: Appropriate ECS and ECR restrictions addedThe addition of ECS actions (CreateService, CreateCluster, RegisterTaskDefinition) and ECR's GetAuthorizationToken is appropriate for a compromised key quarantine policy. These restrictions prevent the creation of new container resources and limit access to existing ones, which is crucial in containing potential threats.
71-75: LGTM: Comprehensive Bedrock service restrictions addedThe addition of Bedrock actions (CreateModelInvocationJob, InvokeModelWithResponseStream, CreateFoundationModelAgreement, PutFoundationModelEntitlement, InvokeModel) is a prudent measure for a compromised key quarantine policy. These restrictions prevent the creation, modification, and invocation of AI/ML models, effectively mitigating the risk of unauthorized use of these powerful resources.
76-81: LGTM for write operations, reconsider S3 read actionsThe addition of S3 write operations (CreateBucket, PutBucketCors) and SageMaker actions (CreateEndpointConfig, CreateProcessingJob) is appropriate for a compromised key quarantine policy. These restrictions prevent the creation of new resources that could be exploited.
However, as noted in a previous comment, denying S3 read operations (GetObject, ListBucket) might hinder legitimate administrative tasks during incident response. These read-only operations could be crucial for security teams investigating the compromise.
Consider removing "s3:GetObject" and "s3:ListBucket" from the deny list to facilitate incident response activities, unless there's a specific security concern that justifies their inclusion.
82-85: LGTM for STS actions, reconsider SES read actionsThe addition of STS actions (GetSessionToken, GetFederationToken) is appropriate for a compromised key quarantine policy, as they prevent obtaining new credentials that could be misused.
However, as noted in a previous comment, the SES actions (GetSendQuota, ListIdentities) are read-only operations that don't pose a direct security risk. Denying these might hinder legitimate administrative tasks or incident response efforts.
Consider removing "ses:GetSendQuota" and "ses:ListIdentities" from the deny list, as they are read-only actions that could be useful for investigating the extent of a potential compromise.
86-89: LGTM: Appropriate restrictions for Amplify, CodeBuild, and GlueThe addition of actions to prevent resource creation in Amplify (CreateDeployment, CreateBackendEnvironment), CodeBuild (CreateProject), and Glue (CreateJob) is a sound measure for a compromised key quarantine policy. These restrictions effectively limit the potential for unauthorized deployments, builds, and data processing jobs, reducing the attack surface in case of a compromised key.
90-92: LGTM for IAM delete actions, reconsider IAM:ListUsersThe addition of IAM delete actions (DeleteRole, DeleteAccessKey) is appropriate for a compromised key quarantine policy, as they prevent destructive actions on access controls.
However, as noted in a previous comment, including "iam:ListUsers" in the deny list might hinder legitimate administrative tasks during incident response. This is a read-only operation that could be useful for security teams investigating the compromise.
Consider removing "iam:ListUsers" from the deny list to facilitate incident response activities, as it's a read-only operation that could be crucial for security investigations.
93-95: LGTM for MediaPackage, reconsider Lambda and SNS read actionsThe addition of "mediapackagev2:CreateChannel" is appropriate as it prevents the creation of new resources, aligning with the quarantine policy's purpose.
However, as noted in a previous comment, the inclusion of "lambda:GetEventSourceMapping" and "sns:GetSMSAttributes" raises questions:
- These are read-only actions that don't modify resources or escalate privileges.
- Denying these actions might hinder incident response efforts by restricting access to potentially useful information.
Consider removing "lambda:GetEventSourceMapping" and "sns:GetSMSAttributes" from the deny list unless there's a compelling reason to include them, as they are read-only actions that could be beneficial during incident investigation.
docs/source/_static/managed-policies/AWSDeadlineCloud-UserAccessJobs.json (1)
119-124: New actions added to AllLevelsPermissions: Verify scope and impactTwo new actions have been added to the "AllLevelsPermissions" statement:
deadline:GetJobTemplatedeadline:ListJobParameterDefinitionsThese additions seem to align with the policy's purpose of managing job-related permissions in the Deadline service. The placement within the "AllLevelsPermissions" statement is appropriate, as it grants these permissions to all membership levels (OWNER, MANAGER, CONTRIBUTOR, VIEWER).
However, consider the following:
- Verify that these new permissions don't expose sensitive information to lower-level roles (e.g., VIEWER) that shouldn't have access to job templates or parameter definitions.
- Ensure that these new actions are required for all levels and don't need to be restricted to higher-level roles like OWNER or MANAGER.
- Check if any documentation needs to be updated to reflect these new permissions.
To verify the impact and usage of these new actions, run the following script:
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (10)
Line range hint
27-47: LGTM: Well-defined permissions for Data Exchange jobsThe "DataExchangeJobsActions" statement provides specific permissions for managing Data Exchange jobs with a clear condition limiting the job types. This approach effectively balances functionality and security.
Line range hint
49-60: LGTM: Well-constrained S3 access for Data ExchangeThe "S3GetActionConditionalResourceAndADX" statement provides specific and well-constrained access to S3 objects. The condition ensuring the action is called via Data Exchange and the resource pattern limiting to relevant S3 buckets are excellent security practices.
Line range hint
62-76: LGTM: Flexible and secure S3 access for Data ExchangeThe "S3GetActionConditionalTagAndADX" statement provides a flexible yet secure approach to S3 object access. The use of object tags for access control, combined with the condition ensuring the action is called via Data Exchange, is a robust security practice.
Line range hint
78-92: LGTM: Secure S3 write permissions for Data ExchangeThe "S3WriteActions" statement provides appropriate permissions for writing objects to S3 buckets related to Data Exchange. The resource pattern and the condition ensuring the action is called via Data Exchange effectively limit the scope and enhance security.
Line range hint
1-164: Overall assessment: Well-structured policy with room for fine-tuningThe AWSDataExchangeProviderFullAccess policy is generally well-structured and appropriate for its purpose. It makes good use of specific actions and conditions to limit permissions where possible. However, there are opportunities to potentially tighten the scope of some permissions, particularly where the Resource is set to "*".
Key recommendations:
- Review the use of wildcards in the DataExchange actions.
- Consider limiting the scope of S3 read actions and KMS actions if possible.
- Verify the necessity of all AWS Marketplace permissions.
- Review the scope of API Gateway GET actions.
These refinements could help adhere more closely to the principle of least privilege while maintaining the functionality required for the Data Exchange provider role.
Line range hint
104-122: Verify the necessity of all AWS Marketplace permissionsThe "AWSMarketplaceActions" statement grants a wide range of permissions for AWS Marketplace operations, which seems appropriate for interactions between Data Exchange and Marketplace. However, it's worth verifying if all these permissions are necessary for the Data Exchange provider role.
To help verify the usage of these permissions, run the following command:
#!/bin/bash # Search for usage of AWS Marketplace actions in the codebase grep -R "aws-marketplace:" .Review the results to ensure that all the granted Marketplace permissions are actually used in the codebase.
Line range hint
134-162: LGTM for Redshift actions, review API Gateway scopeThe Redshift-related statements ("RedshiftConditionalActions" and "RedshiftActions") are well-defined and appropriately constrained. The condition on "RedshiftConditionalActions" is a good security practice.
For the "APIGatewayActions" statement, while limiting to GET actions is a good start, consider if it's possible to restrict the Resource scope further, rather than using "*" for all API Gateway resources.
To assess the scope of API Gateway access, run the following command:
#!/bin/bash # List all API Gateway APIs to understand the scope of access aws apigateway get-rest-apisReview the output to determine if GET access to all these APIs is necessary for the Data Exchange provider role.
Line range hint
124-132: Consider limiting the scope of KMS read actionsThe "KMSActions" statement grants read-only permissions for KMS across all resources. While these permissions are often necessary for operations involving encrypted resources, consider if it's possible to limit the scope to specific KMS keys or a more restricted set of resources, rather than using "*" for the Resource.
To assess the scope of KMS access, run the following command:
#!/bin/bash # List all KMS keys to understand the scope of access aws kms list-keysReview the output to determine if access to all these keys is necessary for the Data Exchange provider role.
Line range hint
5-25: Review the broad permissions granted by wildcardsThe "DataExchangeActions" statement grants extensive permissions for AWS Data Exchange actions. While this aligns with a "FullAccess" policy, consider reviewing the use of wildcards (Get*, Update*, List*, Delete*) to ensure they don't grant more permissions than necessary.
To verify the extent of permissions granted, run the following command:
This will help identify if there are any actions inadvertently included by the wildcards that should be excluded.
Line range hint
94-102: Consider limiting the scope of S3 read actionsThe "S3ReadActions" statement grants permissions to list all buckets and get bucket locations across all S3 resources. While these permissions are often necessary, consider if it's possible to limit the scope to specific buckets or a more restricted set of resources, rather than using "*" for the Resource.
To assess the impact of this broad permission, run the following command:
Review the output to determine if access to all these buckets is necessary for the Data Exchange provider role.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (5)
80-87: Enhanced Customer Profiles and Segmentation CapabilitiesThe new permissions added to the "AllowCustomerProfilesForConnectDomain" section significantly expand the capabilities for managing customer profiles and segmentation. These additions align well with the PR objectives of updating AWS managed policies.
New capabilities include:
- Listing segment definitions and profile attribute values
- Creating and retrieving segment estimates
- Batch operations for profiles and calculated attributes
- Retrieving segment membership information
These enhancements will provide more granular control and improved functionality for customer profile management within Amazon Connect.
96-97: Extended Read Permissions for Customer Profile ObjectsThe addition of the "profile:ListObjectTypeAttributes" permission to the "AllowReadPermissionForCustomerProfileObjects" section enhances the read capabilities for customer profile objects. This new permission complements the existing ones, allowing for a more comprehensive view of object type attributes.
This change is consistent with the overall policy structure and improves the granularity of permissions for managing customer profiles.
149-163: Expanded Wisdom Capabilities for Message Template ManagementThe "AllowWisdomForConnectEnabledTaggedResources" statement has been significantly enhanced with new permissions for managing message templates in Amazon Connect Wisdom. These additions allow for comprehensive management of message templates, including creation, updating, deletion, and version control.
These changes align with the PR objectives and maintain proper security scoping by applying to tagged resources only.
As noted in a previous review, it's important to ensure that the project documentation is updated to reflect these new Wisdom message template capabilities.
195-208: New Section for Customer Profiles SegmentationA new section, "AllowCustomerProfilesSegmentationForConnectDomain", has been added to the policy. This section introduces permissions specifically for managing customer profile segmentation within the Amazon Connect domain. The new capabilities include:
- Creating, retrieving, and deleting segment definitions
- Creating and retrieving segment snapshots
These additions significantly enhance the policy's support for advanced customer segmentation features, which can be crucial for targeted customer interactions and analytics.
The permissions are properly scoped to the Connect domain, maintaining the principle of least privilege. This new section complements the earlier changes to the customer profiles permissions, providing a more comprehensive set of tools for customer data management in Amazon Connect.
Line range hint
1-258: Summary of Policy UpdatesThis PR successfully updates the AmazonConnectServiceLinkedRolePolicy with several important enhancements:
- Expanded customer profile management capabilities, including advanced segmentation features.
- Enhanced read permissions for customer profile objects.
- Comprehensive support for Wisdom message template management.
- New dedicated section for customer profiles segmentation operations.
These changes significantly improve the functionality available to Amazon Connect, particularly in areas of customer data management and engagement. The updates maintain proper security practices by appropriately scoping permissions and adhering to the principle of least privilege.
The changes align well with the PR objectives of updating AWS managed policies. They reflect ongoing improvements in AWS services and provide users with more granular control over Connect-related resources.
Recommendation: Ensure that all related documentation is updated to reflect these new capabilities, particularly the Wisdom message template features as mentioned in a previous review.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (9)
Line range hint
5-127: Comprehensive ECS management policy addedThis new policy statement, "ECSIntegrationsManagementPolicy", provides a wide range of permissions necessary for managing Amazon ECS and its integrations with other AWS services. It includes actions for auto-scaling, AppMesh, CloudFormation, CloudWatch, CodeDeploy, EC2, Elastic File System, Elastic Load Balancing, EventBridge, FSx, IAM, Lambda, CloudWatch Logs, Route 53, and Service Discovery.
The policy follows the principle of least privilege by granting only the permissions necessary for ECS management, despite its broad scope. The use of "*" for the Resource is appropriate for a service-level management policy.
Line range hint
128-137: Well-scoped SSM permissions for ECS parametersThe "SSMPolicy" statement grants permissions to retrieve parameters from AWS Systems Manager Parameter Store. It's correctly limited to only the necessary actions (
GetParameter,GetParameters,GetParametersByPath) and scoped specifically to ECS-related parameters (arn:aws:ssm:*:*:parameter/aws/service/ecs*).This adheres to the principle of least privilege by providing only the required access for ECS operations.
Line range hint
138-155: Secure cleanup policy for ECS-managed CloudFormation resourcesThe "ManagedCloudformationResourcesCleanupPolicy" statement provides permissions to delete specific EC2 resources (Internet Gateways, Routes, Route Tables, and Security Groups) that are typically created as part of ECS deployments using CloudFormation.
A notable security feature is the condition that restricts these delete actions to resources tagged with a CloudFormation stack name matching the pattern "EC2ContainerService-*". This ensures that only resources created by ECS through CloudFormation can be deleted, preventing accidental deletion of unrelated resources.
169-180: Well-scoped PassRole policy for ECS infrastructureThe "InfrastructurePassRolePolicy" statement is correctly configured to allow passing the "ecsInfrastructureRole" to the ECS service. This policy demonstrates good security practices:
- It's limited to a specific role ARN pattern (
arn:aws:iam::*:role/ecsInfrastructureRole).- The condition ensures the role can only be passed to the ECS service (
ecs.amazonaws.com).This policy adheres well to the principle of least privilege, granting only the necessary permissions for ECS infrastructure management.
Line range hint
181-197: Properly scoped PassRole policy for ECS EC2 instancesThe "InstancePassRolePolicy" statement is well-configured to allow passing ECS instance roles to EC2 instances:
- It's limited to role ARNs matching the pattern
arn:aws:iam::*:role/ecsInstanceRole*.- The condition restricts passing these roles only to EC2 services (
ec2.amazonaws.comandec2.amazonaws.com.cn).This policy demonstrates good security practices by adhering to the principle of least privilege and ensuring that ECS instance roles can only be used for their intended purpose.
Line range hint
198-213: Well-defined PassRole policy for ECS Auto ScalingThe "AutoScalingPassRolePolicy" statement is correctly configured to allow passing ECS auto scaling roles:
- It's limited to role ARNs matching the pattern
arn:aws:iam::*:role/ecsAutoscaleRole*.- The condition restricts passing these roles only to Application Auto Scaling services (
application-autoscaling.amazonaws.comandapplication-autoscaling.amazonaws.com.cn).This policy demonstrates good security practices by ensuring that ECS auto scaling roles can only be passed to the appropriate services, adhering to the principle of least privilege.
Line range hint
214-230: Appropriate Service-Linked Role creation policy for ECS and related servicesThe "ServiceLinkedRoleCreationPolicy" statement is well-configured to allow the creation of service-linked roles for ECS and its related services:
- It allows the
iam:CreateServiceLinkedRoleaction, which is necessary for creating service-linked roles.- The condition restricts this action to specific AWS services: ECS, Auto Scaling, Application Auto Scaling for ECS, and Spot Fleet.
This policy follows good security practices by ensuring that service-linked roles can only be created for the necessary services. The use of "*" for the Resource is appropriate in this case, as service-linked roles have predefined paths and naming conventions.
Line range hint
231-248: Well-designed ELB tagging policy for resource managementThe "ELBTaggingPolicy" statement is effectively configured to allow tagging of Elastic Load Balancing resources:
- It permits the
elasticloadbalancing:AddTagsaction.- The condition restricts this action to specific ELB creation operations (CreateTargetGroup, CreateRule, CreateListener, CreateLoadBalancer).
This policy enhances resource management capabilities by ensuring that tags can be added at the time of resource creation. This approach promotes consistent tagging practices, which are crucial for effective resource organization and cost allocation in AWS environments.
The use of "*" for the Resource is acceptable here, as the policy is already well-scoped by the condition.
Line range hint
1-249: Comprehensive and well-structured updates to AmazonECS_FullAccess policyThe changes to the AmazonECS_FullAccess policy significantly enhance its capabilities while maintaining good security practices. Key improvements include:
- Comprehensive permissions for ECS management and integrations with various AWS services.
- Well-scoped policies for Systems Manager parameter access, CloudFormation resource cleanup, and Elastic Load Balancing tagging.
- Properly restricted PassRole permissions for ECS tasks, infrastructure, EC2 instances, and Auto Scaling.
- Appropriate permissions for creating service-linked roles for ECS and related services.
These updates adhere to the principle of least privilege by granting only necessary permissions and using conditions to restrict actions where appropriate. The enhanced policy provides users with the required access to effectively manage ECS environments while maintaining a strong security posture.
docs/source/_static/managed-policies/SecurityAudit.json (2)
19-19: New permission added for account serviceThe addition of
"account:GetPrimaryEmail"allows the SecurityAudit policy to retrieve the primary email address associated with the AWS account. This is consistent with the policy's purpose of auditing security-related information.
480-490: New permissions added for qbusiness serviceSeveral new permissions have been added for the "qbusiness" service:
"qbusiness:ListApplications", "qbusiness:ListDataSourceSyncJobs", "qbusiness:ListDataSources", "qbusiness:ListDocuments", "qbusiness:ListGroups", "qbusiness:ListIndices", "qbusiness:ListPlugins", "qbusiness:ListRetrievers", "qbusiness:ListSubscriptions", "qbusiness:ListTagsForResource", "qbusiness:ListWebExperiences"These additions allow the SecurityAudit policy to list various resources and configurations within the Amazon Q (formerly known as Amazon QuickSight Q) service. This is consistent with the policy's purpose of providing read-only access for security auditing.
However, it's worth noting that these new permissions significantly expand the scope of the SecurityAudit policy.
To ensure these additions are intentional and necessary, please run the following script:
This script will help verify if the addition of qbusiness permissions is documented and if it's consistent with other policies in the project.
✅ Verification successful
SecurityAudit Policy Permissions Verified
The added "qbusiness" permissions are appropriate and align with the SecurityAudit policy's purpose of providing read-only access for security auditing. No unintended expansions were detected in other policies.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the necessity of new qbusiness permissions # Check if qbusiness service is mentioned in any documentation or comments echo "Checking for qbusiness mentions in documentation:" rg -i "qbusiness" README.md docs/ || echo "No mentions found in README or docs" # Check if there are any other policies that use qbusiness permissions echo "Checking for other policies using qbusiness permissions:" rg -i "qbusiness" docs/source/_static/managed-policies/*.json | grep -v "SecurityAudit.json" || echo "No other policies found using qbusiness permissions"Length of output: 192187
docs/source/_static/managed-policies/AWS_ConfigRole.json (5)
32-43: LGTM: New permissions for Amazon OpenSearch Service (AOSS) addedThese new permissions enhance AWS Config's capability to monitor and assess AOSS resources. The additions include read-only operations for collections, lifecycle policies, VPC endpoints, access policies, security configs, and security policies. This change aligns with the PR objective of updating AWS managed policies and improves AWS Config's coverage of AOSS resources.
89-89: LGTM: New permission for AppStream addedThe addition of "appstream:DescribeAppBlockBuilders" permission allows AWS Config to retrieve information about AppStream AppBlockBuilders. This enhances AWS Config's ability to monitor and assess AppStream resources, consistent with its role in providing a detailed inventory of your AWS resources and their configurations.
136-137: LGTM: New permissions for AWS Backup addedThese new permissions enhance AWS Config's capability to monitor and assess AWS Backup resources, specifically for restore testing plans and selections. The additions include:
- GetRestoreTestingPlan
- GetRestoreTestingSelection
- ListRestoreTestingPlans
- ListRestoreTestingSelections
These read-only permissions allow AWS Config to gather information about restore testing configurations in AWS Backup, improving its coverage and ability to assess backup and recovery readiness.
Also applies to: 144-145
185-189: LGTM: Comprehensive update of permissions for various AWS servicesThis update significantly expands AWS Config's capabilities to monitor and assess resources across multiple AWS services. Key additions include:
- CloudTrail: Permissions to get and list channels.
- EC2: Permission to describe VPC endpoints.
- Glue: Permissions to get and list triggers.
- IoT: Permissions to describe and list billing groups.
- IVS: Permissions for encoder configurations, playback restriction policies, stages, and storage configurations.
- MediaConnect: Permissions to describe and list bridges and gateways.
- MediaTailor: Permissions for channels, live sources, source locations, and VOD sources.
- Omics: Permissions to get and list workflows.
- Scheduler: Permissions to get and list schedules.
- SSM-SAP: Permission to list tags for resource.
These read-only permissions enhance AWS Config's ability to provide a comprehensive inventory and assessment of your AWS resources and their configurations across a wide range of services. This update aligns with the PR objective of keeping the AWS Config managed policy up-to-date with the latest AWS service offerings and features.
Also applies to: 568-574, 659-669, 676-693, 769-782, 905-926, 970-971, 1256-1257, 1308-1308
Line range hint
1-1408: Summary: Comprehensive update to AWS Config managed policyThis update to the AWS_ConfigRole.json policy significantly enhances AWS Config's capabilities to monitor and assess resources across a wide range of AWS services. The changes consistently add read-only permissions for describing, getting, and listing various resources. This expansion allows AWS Config to provide a more comprehensive inventory and configuration assessment of AWS resources, aligning with its core functionality and the PR objective of updating AWS managed policies.
Key points:
- The update covers multiple AWS services, including AOSS, AppStream, AWS Backup, CloudTrail, EC2, Glue, IoT, IVS, MediaConnect, MediaTailor, Omics, and Scheduler.
- All new permissions are read-only, maintaining the principle of least privilege and introducing no apparent security risks.
- The changes are consistent with the existing pattern of permissions in the policy.
This update ensures that AWS Config remains up-to-date with the latest AWS service offerings and features, enhancing its value for resource inventory, audit, and compliance purposes.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (8)
32-43: Approval: New permissions for Amazon OpenSearch Service (AOSS) addedThese new permissions allow AWS Config to interact with Amazon OpenSearch Service (AOSS). They enable AWS Config to retrieve information about collections, lifecycle policies, VPC endpoints, access policies, and security configurations. This addition enhances AWS Config's ability to monitor and assess the configuration of OpenSearch resources, which is in line with its primary function of auditing and evaluating resource configurations across AWS services.
The permissions are appropriately scoped to read-only actions, maintaining the principle of least privilege for the AWS Config service role.
135-136: Approval: New permissions for AWS Backup restore testing addedThese new permissions enable AWS Config to interact with AWS Backup's restore testing feature. Specifically, they allow AWS Config to retrieve information about restore testing plans and selections, as well as list these resources. This addition enhances AWS Config's ability to assess the configuration and readiness of backup restore tests, which is crucial for ensuring robust disaster recovery capabilities.
The permissions are appropriately limited to read-only actions, maintaining the principle of least privilege for the AWS Config service role while allowing it to perform its monitoring and assessment functions effectively.
Also applies to: 143-144
88-88: Approval: New permission for Amazon AppStream 2.0 addedThe addition of the "appstream:DescribeAppBlockBuilders" permission allows AWS Config to retrieve information about AppStream 2.0 app block builders. This enhancement enables AWS Config to more comprehensively assess the configuration of AppStream resources, which is in line with its role in monitoring and evaluating AWS resource configurations.
This read-only permission maintains the principle of least privilege while expanding AWS Config's visibility into AppStream resources.
566-566: Approval: New permissions for AWS Glue triggers addedThe addition of "glue:GetTrigger" and "glue:ListTriggers" permissions enhances AWS Config's ability to monitor and assess AWS Glue resources. These permissions allow AWS Config to retrieve information about Glue triggers, which are crucial components in automating ETL workflows.
By including these read-only permissions, AWS Config can now provide more comprehensive insights into the configuration and setup of Glue resources, particularly focusing on how triggers are configured within ETL processes. This aligns well with AWS Config's role in auditing and evaluating resource configurations across AWS services.
Also applies to: 572-572
767-772: Approval: New permissions for Amazon Interactive Video Service (IVS) addedThese new permissions significantly enhance AWS Config's ability to monitor and assess Amazon Interactive Video Service (IVS) resources. The additions include:
- Retrieving and listing encoder configurations
- Retrieving and listing playback restriction policies
- Retrieving and listing stages
- Retrieving and listing storage configurations
These read-only permissions allow AWS Config to provide more comprehensive insights into the setup and configuration of IVS resources. This expansion of AWS Config's capabilities aligns well with its role in auditing and evaluating resource configurations across AWS services, now including detailed visibility into IVS components that are crucial for live streaming operations.
Also applies to: 775-780
903-906: Approval: New permissions for AWS Elemental MediaConnect addedThe addition of these permissions enhances AWS Config's ability to monitor and assess AWS Elemental MediaConnect resources. Specifically, the new permissions allow AWS Config to:
- Describe bridges and gateways
- List bridges and gateways
These read-only permissions enable AWS Config to provide more comprehensive insights into the setup and configuration of MediaConnect resources, particularly focusing on bridges and gateways which are crucial components in media transport workflows.
This expansion of AWS Config's capabilities aligns with its role in auditing and evaluating resource configurations across AWS services, now including detailed visibility into MediaConnect components that are essential for reliable and secure transport of live video.
Also applies to: 908-908
915-918: Approval: New permissions for AWS Elemental MediaTailor addedThese new permissions significantly enhance AWS Config's ability to monitor and assess AWS Elemental MediaTailor resources. The additions include:
- Describing and listing channels
- Describing and listing live sources
- Describing and listing source locations
- Describing and listing VOD (Video on Demand) sources
These read-only permissions allow AWS Config to provide more comprehensive insights into the setup and configuration of MediaTailor resources. This expansion of AWS Config's capabilities aligns well with its role in auditing and evaluating resource configurations across AWS services, now including detailed visibility into MediaTailor components that are crucial for video personalization and monetization.
By including these permissions, AWS Config can now offer a more complete view of how MediaTailor is configured within an AWS environment, which is valuable for ensuring compliance and optimizing resource usage in media delivery workflows.
Also applies to: 920-924
Line range hint
1-1437: Summary: Comprehensive expansion of AWS Config monitoring capabilitiesThis update to the AWSConfigServiceRolePolicy significantly enhances AWS Config's ability to monitor and assess a wider range of AWS services. The additions include new read-only permissions for:
- Amazon OpenSearch Service (AOSS)
- AWS Backup (restore testing)
- Amazon AppStream 2.0
- AWS Glue (triggers)
- Amazon Interactive Video Service (IVS)
- AWS Elemental MediaConnect
- AWS Elemental MediaTailor
These changes are consistent with AWS Config's role in providing comprehensive visibility into AWS resource configurations. All new permissions adhere to the principle of least privilege by being read-only, which is appropriate for AWS Config's monitoring and auditing functions.
The expanded permissions will enable more detailed and comprehensive compliance checks, security assessments, and resource optimization across a broader spectrum of AWS services, particularly in areas related to search, backup, streaming, and media services.
Overall, these updates to the AWSConfigServiceRolePolicy are well-considered and will contribute to improved governance and operational excellence for AWS environments leveraging these services.
docs/source/_static/managed-policies/ReadOnlyAccess.json (8)
111-111: Approved: Reaffirmation of necessary permissionThe removal and subsequent re-addition of "application-signals:ListServices" suggests a deliberate review of this permission. Its reinstatement confirms its necessity for read-only access to Application Signals service.
222-225: Approved: Comprehensive read-only access for Bedrock serviceThe additions to the Bedrock service permissions provide a thorough set of read-only capabilities:
- GetEvaluationJob, GetGuardrail
- ListEvaluationJobs, ListGuardrails
These new permissions maintain the read-only nature of the policy while expanding access to important Bedrock resources and operations.
Also applies to: 239-242
275-275: Approved: Enhanced visibility for Budget resourcesThe addition of "budgets:ListTagsForResource" permission enhances the policy's capabilities by allowing users to view tags associated with Budget resources. This read-only access can be valuable for resource organization, cost allocation, and improved financial management within AWS.
318-328: Approved: Comprehensive read-only access for Cleanrooms ML serviceThe policy now includes a robust set of read-only permissions for the Cleanrooms ML service:
- Get operations: AudienceGenerationJob, AudienceModel, ConfiguredAudienceModel, ConfiguredAudienceModelPolicy, TrainingDataset
- List operations: AudienceExportJobs, AudienceGenerationJobs, AudienceModels, ConfiguredAudienceModels, TagsForResource, TrainingDatasets
These additions provide thorough visibility into Cleanrooms ML resources while maintaining the read-only nature of the policy.
Line range hint
1842-1857: Approved: Enhanced read-only access for Resilience Hub serviceThe policy now includes additional read-only permissions for the AWS Resilience Hub service:
- Describe operations: ResourceGroupingRecommendationTask
- List operations: ResourceGroupingRecommendations, SopRecommendations, SuggestedResiliencyPolicies, TagsForResource, TestRecommendations, UnsupportedAppVersionResources
These additions provide valuable insights into resilience recommendations and resource groupings while maintaining the read-only nature of the policy.
1922-1938: Approved: Comprehensive read-only access for S3 on OutpostsThe policy now includes an extensive set of read-only permissions for S3 on Outposts:
- Get operations: BucketVersioning, Object, ObjectTagging, ObjectVersion, ObjectVersionForReplication, ObjectVersionTagging, ReplicationConfiguration
- List operations: Bucket, BucketMultipartUploads, BucketVersions, MultipartUploadParts, OutpostsWithS3, SharedEndpoints
These additions provide thorough visibility into S3 on Outposts resources and operations while maintaining the read-only nature of the policy.
2165-2175: Approved: Enhanced access to Trusted Advisor and User SubscriptionsThe policy now includes additional read-only permissions for Trusted Advisor and User Subscriptions:
Trusted Advisor:
- Get operations: OrganizationRecommendation, Recommendation
- List operations: Checks, OrganizationRecommendationAccounts, OrganizationRecommendationResources, OrganizationRecommendations, RecommendationResources, Recommendations
User Subscriptions:
- List operations: ApplicationClaims, Claims, UserSubscriptions
These additions provide valuable insights into cost optimization opportunities and subscription management while maintaining the read-only nature of the policy.
Line range hint
1-2175: Summary: Comprehensive update to ReadOnlyAccess policyThis update to the AWS ReadOnlyAccess managed policy significantly expands its coverage to include newer AWS services and features. Key points:
- Maintains read-only nature: All new permissions are for "Get", "List", or "Describe" operations.
- Expanded service coverage: Adds or enhances permissions for services like Bedrock, Cleanrooms ML, Resilience Hub, S3 on Outposts, and Trusted Advisor.
- Improved visibility: Enables better resource management, cost optimization, and security analysis across a wider range of AWS services.
- Consistency: Changes are consistent with the policy's purpose of providing comprehensive read-only access.
These updates ensure that users with this policy can effectively view and analyze resources across the evolving AWS ecosystem without the ability to modify them.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (7)
87-88: New account service permissions look appropriate.The addition of
account:getRegionOptStatusandaccount:listRegionspermissions allows the AWS Support role to query region-specific information. This is beneficial for troubleshooting regional issues and understanding account configurations across different regions, which aligns well with the support role's responsibilities.
264-264: Autoscaling permission addition is appropriate.The new
autoscaling:describeTrafficSourcespermission enables the AWS Support role to retrieve information about traffic sources for Auto Scaling groups. This is valuable for diagnosing issues related to load balancing and traffic distribution in Auto Scaling setups, which is well within the scope of support activities.
547-558: CodeConnections permissions are appropriate for support role.The new CodeConnections permissions enable the AWS Support role to retrieve and list information about connections, hosts, repository links, and sync configurations. These read-only operations are valuable for troubleshooting CI/CD related issues, which falls within the expected scope of AWS support activities.
786-802: Deadline service permissions are suitable for support activities.The new Deadline service permissions allow the AWS Support role to list various resources such as workers, jobs, fleets, and queues. These read-only operations are essential for diagnosing and troubleshooting issues related to rendering, modeling, and simulation workloads managed by AWS Deadline. The additions are appropriate for the support role's responsibilities.
2295-2300: OSIS service permissions are appropriate for the support role.The new permissions for the AWS Open Search Ingestion Service (OSIS) allow the support role to retrieve and list information about pipelines and blueprints, as well as validate pipelines. These operations are essential for diagnosing and troubleshooting OSIS-related issues, which aligns with the support role's responsibilities. The
validatePipelinepermission, while not strictly read-only, doesn't modify resources and is valuable for identifying configuration issues.
3368-3374: X-Ray service permissions enhance support capabilities.The new X-Ray permissions provide the AWS Support role with expanded access to detailed tracing and performance data. These read-only operations allow for retrieving insight impact graphs, sampling statistics, service graphs, and trace graphs. Such information is crucial for diagnosing application performance issues and understanding distributed system behavior, which directly aligns with the support role's responsibilities.
324-345: Bedrock service permissions added, but require careful consideration.The addition of multiple Bedrock service permissions allows the AWS Support role to access and list various AI/ML resources. While these are read-only permissions and can be useful for support scenarios involving Bedrock, they do provide broad access to potentially sensitive information.
Consider reviewing each permission to ensure it's strictly necessary for support operations. If possible, limit the scope to only the most essential permissions required for troubleshooting Bedrock-related issues.
To help assess the usage and necessity of these permissions, run the following script:
✅ Verification successful
Bedrock service permissions addition verified and approved.
The reviewed Bedrock permissions are consistently referenced in existing support documentation, confirming their necessity for the AWS Support role to effectively handle Bedrock-related operations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any existing uses of Bedrock permissions in AWS Support documentation or knowledge base echo "Searching for Bedrock-related support documentation:" rg -i "bedrock.*get|bedrock.*list" --type md echo "If results are found, they may indicate existing use cases for these permissions in support scenarios."Length of output: 1382
udondan
force-pushed
the
update-aws-managed-policies
branch
from
4ab15dd
to
5176638
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (13)
docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1)
Line range hint
1-45: Overall policy review summaryThe AmazonWorkSpacesThinClientReadOnlyAccess policy has undergone significant changes:
Expanded Scope: The policy now includes permissions for WorkSpaces, WorkSpaces Web, and AppStream in addition to the original Thin Client permissions. This represents a substantial increase in the policy's scope.
Resource Specifications: All statements now use "*" as the resource specifier, potentially granting broader access than necessary.
Consistency with Policy Name: The added permissions, while read-only, extend beyond what might be expected from a policy named "ThinClientReadOnlyAccess".
Consider the following recommendations:
Policy Naming: Review if the current policy name accurately reflects its expanded scope. If not, consider renaming or splitting into multiple policies.
Principle of Least Privilege: Evaluate each "*" resource specification and consider using more specific ARNs where possible.
Documentation: Ensure that the policy's documentation is updated to reflect these significant changes and the rationale behind them.
Usage Review: Analyze the usage of this policy in your AWS environment to ensure that the expanded permissions don't unintentionally grant excessive access to any principals.
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (2)
5-11: Consider resource-specific permissions for ListCampaigns action.The new statement allows listing campaigns across all resources, which is likely necessary for the service-linked role. However, if possible, consider restricting the resource scope to specific Amazon Connect instances or regions for enhanced security.
If applicable, you might want to replace the wildcard resource with a more specific ARN pattern:
"Resource": "arn:aws:connect-campaigns:*:*:instance/*/campaign/*"
67-78: Consider more specific resource targeting for Wisdom actions.This statement appropriately allows Wisdom-related actions for resources tagged as Connect Campaigns enabled. However, the use of a wildcard resource ("*") might be broader than necessary.
If possible, consider replacing the wildcard resource with a more specific ARN pattern for Wisdom resources:
"Resource": "arn:aws:wisdom:*:*:assistant/*"This would further enhance the principle of least privilege while still allowing the necessary actions on tagged resources.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (6)
Line range hint
5-25: LGTM! Consider implementing least privilege principle.The new "DataExchangeActions" statement provides comprehensive permissions for AWS Data Exchange operations, which aligns with the policy's full access intent. However, consider implementing the principle of least privilege by restricting permissions to only the necessary resources if possible.
Line range hint
62-77: LGTM! Consider combining with previous S3 statement if possible.The "S3GetActionConditionalTagAndADX" statement effectively uses tagging and service-based conditions to limit S3 access, which is a good security practice. However, consider if this statement could be combined with the previous S3-related statement to simplify the policy structure, if the business logic allows.
Line range hint
94-103: LGTM! Consider restricting bucket listing if possible.The "S3ReadActions" statement provides necessary permissions for bucket discovery and listing. However, consider if it's possible to restrict the ListAllMyBuckets action to only the required buckets, as this could potentially expose more information than necessary.
Line range hint
104-123: LGTM! Consider resource-specific permissions if applicable.The "AWSMarketplaceActions" statement provides necessary permissions for AWS Marketplace interactions, which are likely required for Data Exchange providers. The permissions are appropriately specific. However, if possible, consider restricting the Resource field to specific AWS Marketplace resources rather than using "*" to align with the principle of least privilege.
Line range hint
124-133: LGTM! Consider restricting KMS permissions if possible.The "KMSActions" statement provides necessary permissions for interacting with KMS, which is likely required for handling encrypted resources. However, if possible, consider restricting these permissions to specific KMS keys that are actually used by AWS Data Exchange, rather than allowing access to all keys.
Line range hint
1-164: Overall, these changes significantly enhance the AWSDataExchangeProviderFullAccess policy.The updates to this policy provide a comprehensive set of permissions necessary for AWS Data Exchange providers while implementing several security best practices:
- Use of conditions to limit the scope of permissions.
- Resource-specific restrictions where applicable.
- Separation of concerns with distinct statements for different services and actions.
While some permissions are broad (using "*" for resources), this is often necessary for a "FullAccess" policy. However, it's worth periodically reviewing if any of these can be further restricted based on actual usage patterns.
These changes should improve the functionality available to Data Exchange providers while maintaining a good security posture. As always, continue to monitor and adjust permissions based on the principle of least privilege as the service evolves.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (3)
Line range hint
5-127: LGTM, but consider resource-specific permissions for enhanced security.The "ECSIntegrationsManagementPolicy" statement provides comprehensive access for managing ECS and its integrations across multiple AWS services. This is consistent with a "FullAccess" policy. However, for enhanced security, consider using more specific resource ARNs where possible, instead of "*" for all resources.
Line range hint
156-168: LGTM, but consider limiting the roles that can be passed.The "TasksPassRolePolicy" statement allows passing any IAM role to ECS tasks, which is necessary for task execution. The condition limiting this to "ecs-tasks.amazonaws.com" is good. However, for enhanced security, consider limiting the Resource to specific role ARNs that should be allowed for ECS tasks, rather than using "*".
Line range hint
1-249: Overall, these changes enhance the AmazonECS_FullAccess policy appropriately.The updates to the AmazonECS_FullAccess policy introduce several new statements that provide comprehensive permissions for managing ECS and its integrations. The policy maintains a good balance between providing full access and implementing security best practices through the use of specific resource ARNs and conditions where appropriate.
Key improvements include:
- Comprehensive ECS integration management
- Targeted access to ECS-related SSM parameters
- Controlled cleanup of ECS-related CloudFormation resources
- Well-scoped permissions for various role-passing scenarios
- Appropriate permissions for service-linked role creation
- Controlled tagging permissions for ELB resources
While the policy is generally well-structured, consider further tightening permissions in areas where "*" is used for the Resource, particularly in the ECSIntegrationsManagementPolicy and TasksPassRolePolicy statements, if more granular control is desired.
These changes should significantly improve the ability to manage ECS resources and their integrations while maintaining a reasonable security posture for a FullAccess policy.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (1)
Line range hint
1-3374: Comprehensive policy update with significant expansion of permissionsThis update to the AWSSupportServiceRolePolicy significantly broadens the AWS Support Service Role's access across various services. Key changes include:
- New permissions for AI/ML services (Bedrock)
- Enhanced access to networking and compute services (EC2, EKS, Elastic Load Balancing)
- Additional permissions for developer tools (CodeConnections)
- New access to cost management features (Free Tier)
- Expanded security and compliance capabilities (Inspector2)
- New permissions for data processing and analytics (OSIS, X-Ray)
While these additions enhance support capabilities, they also increase the policy's complexity and potential attack surface. Recommendations:
- Implement a regular review process (e.g., quarterly) to assess the necessity of each permission.
- Consider using AWS Access Analyzer to identify unused permissions that could be removed.
- Maintain documentation justifying the need for each group of permissions.
- Monitor for any potential misuse or unexpected access patterns using AWS CloudTrail.
To assist in ongoing management of this policy, implement an automated process to regularly review and analyze the usage of these permissions. This can help maintain the principle of least privilege over time.
📜 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 (64)
- 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/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/AWSDataExchangeProviderFullAccess.json (11 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/AWSIAMIdentityCenterAllowListForIdentityContext.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 (1 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/AWSSupportPlansFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (14 hunks)
- docs/source/_static/managed-policies/AWS_ConfigRole.json (14 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 (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.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/AmazonECS_FullAccess.json (8 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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/SecurityAudit.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 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 (49)
- 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/AWSCompromisedKeyQuarantineV3.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/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.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/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.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/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.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/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
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientFullAccess.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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/index.json
🧰 Additional context used
🔇 Additional comments (66)
docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (3)
27-36: New "AllowWorkSpacesWebAccess" statement addedThis new statement grants read-only permissions for WorkSpaces Web services across all resources. While these actions align with the policy's read-only nature, consider the following:
- The addition of WorkSpaces Web permissions represents a significant expansion of the policy's scope. Verify if this aligns with the intended use case for Thin Client Read-Only Access.
- The use of "*" as the Resource allows these actions on all WorkSpaces Web resources. Consider if a more granular resource specification is appropriate.
Please confirm if this expansion of permissions to include WorkSpaces Web is necessary and intentional for the Thin Client Read-Only Access policy.
#!/bin/bash # Check for any existing WorkSpaces Web-related permissions in the old version of the policy jq '.Statement[] | select(.Action | arrays and (arrays | any(startswith("workspaces-web:")))) | .Sid' docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
19-26: New "AllowWorkSpacesAccess" statement addedThis new statement grants permission to describe WorkSpace directories across all resources. While this aligns with the read-only nature of the policy, consider the following:
- Verify if this broad access to all WorkSpace directories is necessary for the intended use case.
- If possible, consider limiting the Resource to specific WorkSpace directory ARNs to adhere to the principle of least privilege.
Please confirm if this level of access is required and intentional.
#!/bin/bash # Check for any existing WorkSpaces-related permissions in the old version of the policy jq '.Statement[] | select(.Action | arrays and (arrays | any(startswith("workspaces:")))) | .Sid' docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
37-43: New "AllowAppStreamAccess" statement addedThis new statement grants permission to describe AppStream stacks across all resources. While this action is read-only, its addition raises some points to consider:
- The inclusion of AppStream permissions represents another expansion of the policy's scope. Verify if this aligns with the intended use case for Thin Client Read-Only Access.
- The use of "*" as the Resource allows this action on all AppStream stacks. Consider if a more specific resource specification is appropriate.
Please confirm if this addition of AppStream permissions is necessary and intentional for the Thin Client Read-Only Access policy. Also, consider if there are any potential implications or dependencies between Thin Client, WorkSpaces, and AppStream that justify these additions.
docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.json (3)
Line range hint
38-47: LGTM: Addition of ec2:DescribeRouteTables enhances network validation capabilitiesThe addition of the
ec2:DescribeRouteTablesaction to the NetworkValidationStatement is appropriate and consistent with the existing permissions. This change allows the policy to retrieve information about route tables, which complements the existing abilities to describe subnets, VPCs, and security groups.This addition enhances the policy's capability to perform comprehensive network validation, which is likely necessary for the proper functioning of Amazon Timestream InfluxDB services in various network configurations.
Line range hint
1-85: Overall impact: Minor enhancement to network validation capabilitiesThe addition of the
ec2:DescribeRouteTablesaction to the NetworkValidationStatement is the only change in this policy update. This modification:
- Enhances the policy's ability to perform network validation by allowing access to route table information.
- Maintains the existing structure and principles of the policy.
- Adheres to the principle of least privilege by adding a specific, read-only permission.
- Does not introduce any conflicts or inconsistencies with the existing permissions.
This change appears to be a targeted enhancement to support Amazon Timestream InfluxDB operations in various network configurations.
Line range hint
1-85: Verify consistency with other AWS managed policiesWhile the change is appropriate for this policy, it would be beneficial to verify if similar updates have been made to other AWS managed policies that involve network validation. This check would ensure consistency across AWS services and confirm whether this is a standard enhancement or specific to Timestream InfluxDB.
To check for consistency, you can run the following script:
This script will help identify other policies that include the
ec2:DescribeRouteTablesaction, allowing you to assess the consistency of this change across different AWS services.✅ Verification successful
Verified: ec2:DescribeRouteTables is consistent with other AWS managed policies
The addition of
ec2:DescribeRouteTablesto the AmazonTimestreamInfluxDBFullAccess policy is consistent with many other AWS managed policies. This permission is commonly included in policies for services that may need to interact with VPC networking, such as AppStream, VPC, EKS, and various database services. Its presence in this policy aligns with AWS's standard practices for granting necessary VPC-related permissions to managed services.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for the presence of ec2:DescribeRouteTables in other AWS managed policies # Search for other AWS managed policies policies=$(fd -e json . docs/source/_static/managed-policies) # Check each policy for the presence of ec2:DescribeRouteTables for policy in $policies do if grep -q "ec2:DescribeRouteTables" "$policy"; then echo "Found ec2:DescribeRouteTables in $policy" fi doneLength of output: 281156
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (5)
13-22: LGTM: Appropriate permissions added for Connect operations.The additional actions "connect:DescribeContactFlow" and "connect:SendOutboundEmail" are relevant to the Connect service and align with the statement's purpose. The resource specification remains appropriately scoped to Connect instances.
24-35: LGTM: Secure EventBridge rule listing permissions added.This new statement allows listing EventBridge rules with appropriate account-level restrictions. The condition ensuring that the resource account matches the principal's account is a good security practice.
37-52: LGTM: Well-scoped EventBridge rule management permissions.This statement provides necessary permissions for managing EventBridge rules specific to Connect Campaigns. The resource pattern restriction and conditions on account and managed-by tag provide appropriate scoping for these powerful permissions.
54-65: LGTM: Consistent EventBridge target listing permissions.This statement allows listing targets for specific EventBridge rules, complementing the previous EventBridge permissions. The resource restriction and account condition maintain consistency with the overall permission structure.
Line range hint
1-81: Overall, the policy updates enhance functionality with good security practices.The changes to this policy document for the Amazon Connect Campaigns Service Linked Role are well-structured and generally follow the principle of least privilege. New permissions have been added with appropriate scoping through resource patterns, account conditions, and tags.
Key improvements include:
- Addition of necessary Connect Campaign and Connect service permissions.
- Well-scoped EventBridge rule management and listing permissions.
- Inclusion of Wisdom service actions with tag-based restrictions.
While most changes are appropriately restricted, consider reviewing the resource specifications for the ConnectCampaignAccess and Wisdom-related statements to potentially tighten them further if the service architecture allows.
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (6)
67-70: LGTM: Appropriate ECS and ECR restrictions addedThe addition of ECS actions (CreateService, CreateCluster, RegisterTaskDefinition) and ECR's GetAuthorizationToken is appropriate for a compromised key quarantine policy. These restrictions prevent the creation of new container resources and limit access to existing ones, which is crucial in containing potential threats.
71-75: LGTM: Comprehensive Bedrock service restrictions addedThe addition of Bedrock actions effectively prevents the creation, invocation, and management of AI/ML models. This is a prudent measure in a compromised key scenario, as it mitigates the risk of unauthorized use of potentially costly and sensitive AI/ML resources.
76-81: LGTM for write operations, reconsider S3 read actionsThe addition of S3 write operations (CreateBucket, PutBucketCors) and SageMaker actions is appropriate for a compromised key quarantine policy. However, as previously noted in an existing comment, denying S3 read operations (GetObject, ListBucket) might hinder legitimate administrative tasks during incident response.
Consider removing "s3:GetObject" and "s3:ListBucket" from the deny list to facilitate incident response activities, unless there's a specific security concern that justifies their inclusion.
82-85: LGTM for STS actions, reconsider SES read actionsThe addition of STS actions (GetSessionToken, GetFederationToken) is appropriate for a compromised key quarantine policy, as they prevent obtaining new credentials that could be misused.
As previously noted, consider removing "ses:GetSendQuota" and "ses:ListIdentities" from the deny list, as they are read-only actions that could be useful for investigating the extent of a potential compromise.
86-92: LGTM for most additions, reconsider IAM:ListUsersThe additions for Amplify, CodeBuild, Glue, and most IAM actions are appropriate:
- Amplify, CodeBuild, and Glue actions prevent creating new resources.
- IAM
DeleteRoleandDeleteAccessKeyprevent destructive actions on access controls.However, as previously noted, including
iam:ListUsersin the deny list might hinder legitimate administrative tasks during incident response. Consider removing this action from the deny list, as it's a read-only operation that could be useful for security teams investigating the compromise.
93-95: Approve MediaPackage action, query Lambda and SNS inclusionsThe addition of
mediapackagev2:CreateChannelis appropriate as it prevents the creation of new resources, aligning with the quarantine policy's purpose.However, as previously noted, the inclusion of
lambda:GetEventSourceMappingandsns:GetSMSAttributesraises questions:
- These are read-only actions that don't modify resources or escalate privileges.
- Denying these actions might hinder incident response efforts by restricting access to potentially useful information.
Consider removing these read-only actions from the deny list unless there's a specific security concern that justifies their inclusion.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (4)
Line range hint
27-47: LGTM! Good use of conditions for enhanced security.The "DataExchangeJobsActions" statement effectively limits job-related permissions to specific job types using conditions. This is a good security practice that aligns with the principle of least privilege.
Line range hint
49-61: LGTM! Excellent use of resource scoping and conditions.The "S3GetActionConditionalResourceAndADX" statement demonstrates good security practices by:
- Limiting S3 access to buckets containing "aws-data-exchange" in the name.
- Using a condition to ensure the action is only allowed when called via AWS Data Exchange.
These measures help to prevent unauthorized access and align with the principle of least privilege.
Line range hint
78-93: LGTM! Crucial restrictions on write permissions.The "S3WriteActions" statement appropriately restricts S3 write permissions by:
- Limiting access to buckets containing "aws-data-exchange" in the name.
- Ensuring actions are only allowed when called via AWS Data Exchange.
These restrictions are particularly important for write permissions and help prevent unauthorized data modification.
Line range hint
134-163: LGTM! Good use of conditions and action-specific permissions.The Redshift and API Gateway related statements demonstrate good security practices:
- The "RedshiftConditionalActions" statement uses a condition to limit the consumer identifier to "ADX".
- The "RedshiftActions" and "APIGatewayActions" statements are limited to specific, necessary actions.
These measures help to prevent unauthorized access and align with the principle of least privilege.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (5)
80-87: LGTM: Enhanced Customer Profiles and Segmentation CapabilitiesThe new permissions added to the "AllowCustomerProfilesForConnectDomain" section significantly expand the capabilities for managing customer profiles and segmentation. These additions include:
- Listing segment definitions and profile attribute values
- Creating and retrieving segment estimates
- Batch operations for profiles and calculated attributes
- Retrieving segment membership
These enhancements align well with the PR objectives of updating AWS managed policies and should provide more robust functionality for Amazon Connect users working with customer profiles.
96-97: LGTM: Expanded Read Permissions for Customer Profile ObjectsThe addition of the "profile:ListObjectTypeAttributes" permission to the "AllowReadPermissionForCustomerProfileObjects" section is a logical extension of the existing read permissions. This change allows for listing attributes of object types, which is consistent with the overall enhancements to customer profile management capabilities in this policy update.
149-163: LGTM: Comprehensive Wisdom Message Template ManagementThe additions to the "AllowWisdomForConnectEnabledTaggedResources" section significantly enhance the capabilities for managing Wisdom message templates. These new permissions cover a wide range of operations, including:
- Creating, updating, and deleting message templates
- Managing template metadata and versions
- Activating and deactivating templates
- Creating and deleting template attachments
- Rendering message templates
These changes align well with the PR objectives and the AI-generated summary, providing a comprehensive set of tools for working with Wisdom message templates.
As noted in a previous review comment, please ensure that the project documentation is updated to reflect these new Wisdom message template capabilities.
195-208: LGTM: New Section for Customer Profiles SegmentationA new section, "AllowCustomerProfilesSegmentationForConnectDomain", has been added to the policy. This section introduces specific permissions for customer profiles segmentation operations, including:
- Creating, retrieving, and deleting segment definitions
- Creating and retrieving segment snapshots
These additions complement the earlier changes related to customer profiles and segmentation, providing a more complete set of tools for working with customer segments. The resource ARN is correctly scoped to the Connect domain, maintaining proper access control.
This new section enhances the policy's capabilities in line with the PR objectives of updating AWS managed policies.
Line range hint
1-265: Overall Assessment: Comprehensive Policy UpdateThis update to the AmazonConnectServiceLinkedRolePolicy significantly enhances the capabilities of Amazon Connect, particularly in the areas of:
- Customer Profiles: Expanded permissions for managing profiles, attributes, and segmentation.
- Wisdom: Comprehensive additions for managing message templates.
- Segmentation: New dedicated section for segmentation operations.
These changes align well with the PR objectives of updating AWS managed policies and the AI-generated summary. The additions are logically structured, maintain proper access control, and should provide Amazon Connect users with more robust tools for managing customer data and interactions.
To ensure full utilization of these new capabilities:
- Update relevant documentation to reflect these changes, especially regarding the new Wisdom message template features.
- Consider creating or updating user guides or tutorials to help users leverage these new capabilities effectively.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (7)
Line range hint
128-137: LGTM: Well-scoped SSM access for ECS parameters.The "SSMPolicy" statement provides targeted access to ECS-related parameters in AWS Systems Manager Parameter Store. The resource limitation to "arn:aws:ssm:::parameter/aws/service/ecs*" is a good security practice, ensuring access only to relevant parameters.
Line range hint
138-155: LGTM: Well-controlled cleanup permissions for ECS CloudFormation resources.The "ManagedCloudformationResourcesCleanupPolicy" statement allows for the deletion of specific EC2 resources created by ECS through CloudFormation. The condition limiting this to resources tagged with "EC2ContainerService-*" stack names provides a good balance between functionality and security.
169-180: LGTM: Well-scoped permission for ECS infrastructure role.The "InfrastructurePassRolePolicy" statement is well-defined, allowing only the "ecsInfrastructureRole" to be passed to the ECS service. This specific scoping of both the resource and the service in the condition is a good security practice.
Line range hint
181-197: LGTM: Appropriate permissions for ECS instance roles.The "InstancePassRolePolicy" statement is well-structured, allowing only roles matching the "ecsInstanceRole*" pattern to be passed to EC2 instances. The condition limiting this to EC2 services in different regions is appropriate for global deployments.
Line range hint
198-213: LGTM: Well-defined permissions for ECS auto-scaling roles.The "AutoScalingPassRolePolicy" statement is appropriately structured, allowing only roles matching the "ecsAutoscaleRole*" pattern to be passed to application auto-scaling services. The condition limiting this to auto-scaling services in different regions supports global deployments effectively.
Line range hint
214-230: LGTM: Appropriate permissions for creating ECS-related service-linked roles.The "ServiceLinkedRoleCreationPolicy" statement allows the creation of service-linked roles for ECS and related services (including auto-scaling). This is necessary for these services to function properly. The condition limiting the creation to specific services provides good control over this powerful permission.
Line range hint
231-248: LGTM: Well-controlled tagging permissions for ELB resources.The "ELBTaggingPolicy" statement allows adding tags to Elastic Load Balancing resources, which is often necessary for ECS deployments. The condition limiting this to specific creation actions is a good practice, ensuring tags are only added during resource creation.
docs/source/_static/managed-policies/SecurityAudit.json (3)
19-19: New permission added for account serviceThe action
"account:GetPrimaryEmail"has been added to the SecurityAudit policy. This allows the policy holder to retrieve the primary email address associated with the AWS account.This addition is consistent with the purpose of a SecurityAudit policy, as it provides access to important account information that may be necessary for auditing purposes.
Line range hint
1-724: Summary of changes to SecurityAudit policyThe updates to the SecurityAudit managed policy enhance its capabilities by adding new read-only permissions:
- Access to retrieve the primary email address of the AWS account.
- Comprehensive read-only access to Amazon Q (formerly QuickSight Q) resources and configurations.
These additions align with the policy's purpose of providing broad visibility for auditing purposes without granting any write or modify permissions. They allow for more thorough security audits by including account information and the increasingly important Amazon Q service in the scope of the audit.
The changes are appropriate and beneficial for the SecurityAudit policy, improving its effectiveness in modern AWS environments.
To ensure these changes are reflected in the official AWS documentation, we should verify the following:
#!/bin/bash # Description: Check AWS documentation for updates on SecurityAudit policy # Fetch the AWS managed policies documentation page curl -s https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html > aws_managed_policies_doc.html # Check if the page mentions recent updates to SecurityAudit policy echo "Checking AWS documentation for SecurityAudit policy updates:" if grep -i "SecurityAudit" aws_managed_policies_doc.html | grep -i "recent changes" > /dev/null; then echo "✓ Documentation mentions recent changes to SecurityAudit policy" else echo "✗ No mention of recent changes to SecurityAudit policy found in documentation" fi # Clean up rm aws_managed_policies_doc.htmlThis script will help confirm if the AWS documentation has been updated to reflect these changes to the SecurityAudit policy.
480-490: New permissions added for qbusiness serviceSeveral new actions for the "qbusiness" service have been added to the SecurityAudit policy:
"qbusiness:ListApplications""qbusiness:ListDataSourceSyncJobs""qbusiness:ListDataSources""qbusiness:ListDocuments""qbusiness:ListGroups""qbusiness:ListIndices""qbusiness:ListPlugins""qbusiness:ListRetrievers""qbusiness:ListSubscriptions""qbusiness:ListTagsForResource""qbusiness:ListWebExperiences"These additions are appropriate for a SecurityAudit policy as they provide read-only access to list various resources and configurations within the Amazon Q (formerly known as Amazon QuickSight Q) service. This allows auditors to review the setup and usage of Amazon Q within the AWS environment without granting any write or modify permissions.
To ensure these new permissions are documented and officially part of the AWS managed SecurityAudit policy, let's verify this information:
This script will help confirm that these new permissions are indeed part of the official AWS managed SecurityAudit policy.
docs/source/_static/managed-policies/AWS_ConfigRole.json (8)
32-43: New permissions added for Amazon OpenSearch Service (AOSS)These new permissions allow AWS Config to monitor and assess the configuration of AOSS resources. The added permissions are read-only, which is appropriate for AWS Config's monitoring and auditing purposes. This change enhances AWS Config's ability to provide visibility into AOSS resources.
89-89: New permission added for AWS AppStreamThe addition of "appstream:DescribeAppBlockBuilders" permission allows AWS Config to include AppStream AppBlockBuilders in its configuration assessments. This read-only permission is consistent with AWS Config's monitoring role and enhances its coverage of AppStream resources.
136-137: New permissions added for AWS Backup restore testingThese new permissions allow AWS Config to monitor and assess the configuration of AWS Backup restore testing resources. The added permissions (GetRestoreTestingPlan, GetRestoreTestingSelection, ListRestoreTestingPlans, ListRestoreTestingSelections) are read-only, which is appropriate for AWS Config's monitoring role. This change enhances AWS Config's ability to provide visibility into AWS Backup restore testing configurations.
Also applies to: 144-145
185-185: New permissions added for AWS CloudTrail channelsThe addition of "cloudTrail:GetChannel" and "cloudTrail:ListChannels" permissions allows AWS Config to include CloudTrail channels in its configuration assessments. These read-only permissions are consistent with AWS Config's monitoring role and enhance its coverage of CloudTrail resources, specifically the channels feature.
Also applies to: 189-189
769-774: New permissions added for AWS IVS (Interactive Video Service)These new permissions allow AWS Config to monitor and assess the configuration of various AWS IVS resources. The added permissions cover encoder configurations, playback restriction policies, stages, and storage configurations. All of these are read-only permissions (Get* and List*), which is appropriate for AWS Config's monitoring role. This change significantly enhances AWS Config's ability to provide visibility into IVS resource configurations.
Also applies to: 777-782
917-920: New permissions added for AWS MediaTailorThese new permissions enable AWS Config to monitor and assess the configuration of various AWS MediaTailor resources. The added permissions cover channels, live sources, source locations, and VOD sources. All of these are read-only permissions (Describe* and List*), which aligns with AWS Config's monitoring role. This change significantly enhances AWS Config's ability to provide visibility into MediaTailor resource configurations, improving overall monitoring and compliance capabilities for MediaTailor services.
Also applies to: 922-926
970-971: New permissions added for AWS Omics and AWS SchedulerThese new permissions enhance AWS Config's monitoring capabilities for AWS Omics and AWS Scheduler services:
For AWS Omics: The addition of "omics:GetWorkflow" and "omics:ListWorkflows" allows AWS Config to include Omics workflows in its configuration assessments.
For AWS Scheduler: The addition of "scheduler:GetSchedule" and "scheduler:ListSchedules" enables AWS Config to monitor and assess Scheduler schedules.
These read-only permissions are consistent with AWS Config's monitoring role and expand its coverage to include these newer AWS services, improving overall configuration management and compliance monitoring.
Also applies to: 1256-1257
Line range hint
1-1392: Summary of AWS Config Role Policy UpdatesThis update to the AWS Config Role policy significantly enhances AWS Config's monitoring and assessment capabilities across multiple AWS services. Key points:
- New read-only permissions have been added for services including Amazon OpenSearch Service, AWS AppStream, AWS Backup, AWS CloudTrail, AWS IVS, AWS MediaTailor, AWS Omics, and AWS Scheduler.
- All new permissions are consistent with AWS Config's monitoring role, being read-only in nature (Get*, Describe*, List*).
- These additions enable AWS Config to provide more comprehensive configuration assessments, enhancing overall security posture and compliance monitoring.
- No security concerns were identified, as all added permissions align with the principle of least privilege for AWS Config's responsibilities.
These changes will allow organizations to have better visibility and control over their AWS resources across a broader range of services.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (6)
32-43: LGTM: New read-only permissions for Amazon OpenSearch Service (AOSS)These new permissions allow AWS Config to monitor and assess AOSS resources, including collections, lifecycle policies, VPC endpoints, access policies, and security configurations. The additions are appropriately scoped to read-only actions, maintaining the principle of least privilege.
135-136: LGTM: New read-only permissions for AWS Backup restore testingThese additions grant AWS Config the ability to retrieve and list restore testing plans and selections. This enables AWS Config to assess the configuration and compliance of AWS Backup's restore testing features, enhancing the service's ability to monitor backup and recovery readiness.
Also applies to: 143-144
88-88: LGTM: Extended read-only permissions for AppStream, Glue, and IVSThese additions enhance AWS Config's monitoring capabilities:
- AppStream: Ability to describe app block builders.
- AWS Glue: Permissions to get and list triggers.
- AWS IVS: Expanded permissions to describe and list various IVS resources like encoder configurations, playback restriction policies, stages, and storage configurations.
All new permissions are appropriately scoped to read-only actions, maintaining the principle of least privilege while expanding AWS Config's monitoring coverage.
Also applies to: 566-566, 572-572, 767-772, 775-780
903-906: LGTM: New read-only permissions for MediaConnect and MediaTailorThese additions expand AWS Config's monitoring capabilities:
- MediaConnect: Permissions to describe bridges, flows, gateways, and list related resources.
- MediaTailor: Abilities to describe channels, live sources, source locations, VOD sources, and list related resources.
These read-only permissions allow AWS Config to effectively monitor and assess the configuration of MediaConnect and MediaTailor resources, enhancing its coverage of AWS media services.
Also applies to: 908-908, 915-918, 920-924
968-969: LGTM: New read-only permissions for AWS Omics and AWS SchedulerThese additions further expand AWS Config's monitoring capabilities:
- AWS Omics: Permissions to get and list workflows.
- AWS Scheduler: Abilities to get and list schedules.
These read-only permissions enable AWS Config to monitor and assess the configuration of Omics workflows and Scheduler schedules, broadening its coverage to include these newer AWS services.
Also applies to: 1254-1255
Line range hint
1-1437: Summary: Expanded monitoring capabilities for AWS ConfigThis update to the AWSConfigServiceRolePolicy significantly enhances AWS Config's ability to monitor and assess a wider range of AWS services. The additions include read-only permissions for:
- Amazon OpenSearch Service (AOSS)
- AWS Backup (restore testing features)
- AppStream, Glue, and IVS (Interactive Video Service)
- MediaConnect and MediaTailor
- AWS Omics and AWS Scheduler
All new permissions adhere to the principle of least privilege, being strictly read-only. These changes will allow AWS Config to provide more comprehensive configuration and compliance assessments across a broader spectrum of AWS services, improving overall monitoring and governance capabilities for AWS environments.
docs/source/_static/managed-policies/ReadOnlyAccess.json (6)
111-111: Approval: New read-only permission for application-signalsThe addition of "application-signals:ListServices" is appropriate for a ReadOnlyAccess policy. This permission allows listing of services, which is a read-only operation.
222-225: Approval: New read-only permissions for bedrock serviceThe following additions to the bedrock service are appropriate for a ReadOnlyAccess policy:
- GetEvaluationJob, GetFoundationModel, GetFoundationModelAvailability, GetGuardrail
- ListEvaluationJobs, ListFoundationModelAgreementOffers, ListFoundationModels, ListGuardrails
These permissions only allow for retrieving and listing information, which aligns with the read-only intent of the policy.
Also applies to: 239-242
275-275: Approval: New read-only permission for budgets serviceThe addition of "budgets:ListTagsForResource" is appropriate for a ReadOnlyAccess policy. This permission allows listing of tags for a resource, which is a read-only operation.
318-328: Approval: New read-only permissions for cleanrooms-ml serviceThe following additions to the cleanrooms-ml service are appropriate for a ReadOnlyAccess policy:
- GetAudienceGenerationJob, GetAudienceModel, GetConfiguredAudienceModel, GetConfiguredAudienceModelPolicy, GetTrainingDataset
- ListAudienceExportJobs, ListAudienceGenerationJobs, ListAudienceModels, ListConfiguredAudienceModels, ListTagsForResource, ListTrainingDatasets
These permissions only allow for retrieving and listing information, which is consistent with the read-only nature of the policy.
1922-1938: Approval: New read-only permissions for s3-outposts serviceThe following additions to the s3-outposts service are appropriate for a ReadOnlyAccess policy:
- GetBucketVersioning, GetObject, GetObjectTagging, GetObjectVersion, GetObjectVersionForReplication, GetObjectVersionTagging, GetReplicationConfiguration
- ListBucket, ListBucketMultipartUploads, ListBucketVersions, ListMultipartUploadParts, ListOutpostsWithS3, ListSharedEndpoints
These permissions only allow for retrieving and listing information related to S3 on Outposts, which aligns with the read-only intent of the policy.
Line range hint
1-2175: Summary: ReadOnlyAccess policy updates maintain read-only integrityAfter reviewing all additions to the ReadOnlyAccess policy, I can confirm that the changes are appropriate and maintain the policy's intended purpose. The new permissions added for various services (application-signals, bedrock, budgets, cleanrooms-ml, s3-outposts, and others) are all read-only in nature, allowing only for retrieving, describing, getting, and listing operations.
These updates expand the policy's coverage to include newer AWS services and additional read-only operations for existing services, enhancing the policy's utility without compromising its read-only principle.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (10)
3355-3356: New WorkSpaces permissions addedTwo new WorkSpaces permissions have been added to the policy:
workspaces:describeApplicationAssociationsworkspaces:describeWorkspaceAssociationsThese permissions allow the support role to retrieve information about application and workspace associations in WorkSpaces, which can be useful for troubleshooting and managing WorkSpaces environments.
To ensure these permissions are necessary and used appropriately, please run the following script:
#!/bin/bash # Description: Check for usage of new WorkSpaces permissions in AWS Support documentation echo "Searching for references to new WorkSpaces permissions in AWS Support documentation:" rg -i "workspaces:(describeApplicationAssociations|describeWorkspaceAssociations)" --type md echo "Review the results to confirm if these permissions are necessary for support operations related to WorkSpaces service."
3368-3374: New X-Ray permissions addedSeveral new X-Ray permissions have been added to the policy:
xray:listResourcePoliciesxray:getInsightImpactGraphxray:getSamplingStatisticSummariesxray:getSamplingTargetsxray:getServiceGraphxray:getTimeSeriesServiceStatisticsxray:getTraceGraphThese permissions enhance the support role's ability to analyze and troubleshoot application performance using X-Ray, which is crucial for identifying and resolving issues in distributed systems.
To ensure these permissions are necessary and used appropriately, please run the following script:
#!/bin/bash # Description: Check for usage of new X-Ray permissions in AWS Support documentation echo "Searching for references to new X-Ray permissions in AWS Support documentation:" rg -i "xray:(listResourcePolicies|getInsightImpactGraph|getSamplingStatisticSummaries|getSamplingTargets|getServiceGraph|getTimeSeriesServiceStatistics|getTraceGraph)" --type md echo "Review the results to confirm if these permissions are necessary for support operations related to X-Ray service."
1637-1638: New Inspector2 permissions addedTwo new Inspector2 permissions have been added to the policy:
inspector2:getConfigurationinspector2:getEc2DeepInspectionConfigurationThese permissions allow the support role to retrieve configuration information for Inspector2, including EC2 deep inspection configurations. This can be useful for troubleshooting and managing security assessments.
To ensure these permissions are necessary and used appropriately, please run the following script:
1143-1144: New EKS permissions addedTwo new EKS (Elastic Kubernetes Service) permissions have been added to the policy:
eks:describePodIdentityAssociationeks:listPodIdentityAssociationsThese permissions allow the support role to retrieve information about pod identity associations in EKS clusters, which can be useful for troubleshooting and managing EKS resources.
To ensure these permissions are necessary and used appropriately, please run the following script:
✅ Verification successful
New EKS permissions correctly added and documented
The new EKS permissions
eks:describePodIdentityAssociationandeks:listPodIdentityAssociationshave been successfully added to the policy and are appropriately documented in the changelog. No additional references were found, confirming their intended purpose for support operations related to EKS service.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for usage of new EKS permissions in AWS Support documentation echo "Searching for references to new EKS permissions in AWS Support documentation:" rg -i "describePodIdentityAssociation|listPodIdentityAssociations" --type md echo "Review the results to confirm if these permissions are necessary for support operations related to EKS service."Length of output: 829
Script:
#!/bin/bash # Description: Check for usage of new EKS permissions in AWS Support documentation echo "Searching for references to new EKS permissions in AWS Support documentation:" rg -i "describePodIdentityAssociation|listPodIdentityAssociations" --type md echo "Review the results to confirm if these permissions are necessary for support operations related to EKS service."Length of output: 591
1210-1212: New Elastic Load Balancing permissions addedThree new Elastic Load Balancing permissions have been added to the policy:
elasticloadbalancing:describeTrustStoreselasticloadbalancing:describeTrustStoreAssociationselasticloadbalancing:describeTrustStoreRevocationsThese permissions allow the support role to retrieve information about trust stores, their associations, and revocations in Elastic Load Balancing, which is important for managing SSL/TLS certificates and security configurations.
To ensure these permissions are necessary and used appropriately, please run the following script:
1018-1018: New EC2 permissions addedTwo new EC2 permissions have been added to the policy:
ec2:describeSnapshotTierStatusec2:getSubnetCidrReservationsThese permissions allow the support role to retrieve information about EC2 snapshot tier status and subnet CIDR reservations, which can be useful for troubleshooting and managing EC2 resources.
To ensure these permissions are necessary and used appropriately, please run the following script:
Also applies to: 1064-1064
87-88: New permissions added for account and autoscaling servicesThe policy now includes new permissions for the account and autoscaling services:
account:getRegionOptStatusaccount:listRegionsautoscaling:describeTrafficSourcesThese additions enhance the support role's capabilities in managing regional operations and autoscaling diagnostics. However, it's important to ensure these expanded permissions align with the principle of least privilege.
To confirm the necessity of these new permissions, please run the following script:
✅ Verification successful
Verification of New Account and Autoscaling Permissions
The new permissions
account:GetRegionOptStatusandautoscaling:DescribeTrafficSourcesare documented in the changelog files (CHANGELOG/v0.480.0.mdandCHANGELOG/v0.481.0.mdrespectively). This confirms their established use in support operations, ensuring that their inclusion aligns with necessary support functionalities and adheres to the principle of least privilege.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any existing uses of the new permissions in AWS Support documentation or knowledge base echo "Checking for account and autoscaling permissions usage:" rg -i "getRegionOptStatus|listRegions|describeTrafficSources" --type md echo "If any results are found, they may indicate existing use cases for these permissions in support scenarios."Length of output: 829
Script:
#!/bin/bash # Description: Check for any existing uses of the new permissions in AWS Support documentation or knowledge base echo "Checking for account and autoscaling permissions usage:" rg -i "getRegionOptStatus|listRegions|describeTrafficSources" --type md echo "If any results are found, they may indicate existing use cases for these permissions in support scenarios."Length of output: 527
786-802: New permissions added for Deadline serviceThe policy now includes several new permissions for the Deadline service:
deadline:listAvailableMeteredProductsdeadline:listBudgetsdeadline:listFarmMembersdeadline:listFarmsdeadline:listFleetMembersdeadline:listFleetsdeadline:listJobMembersdeadline:listJobsdeadline:listLicenseEndpointsdeadline:listMeteredProductsdeadline:listMonitorsdeadline:listQueueEnvironmentsdeadline:listQueueFleetAssociationsdeadline:listQueueMembersdeadline:listQueuesdeadline:listStorageProfilesdeadline:listWorkersThese permissions allow the support role to list various Deadline resources, which are important for managing render farms and distributed computing environments.
To ensure these permissions are necessary and used appropriately, please run the following script:
1343-1343: New Free Tier permission addedA new permission for the Free Tier service has been added to the policy:
freetier:getFreeTierUsageThis permission allows the support role to retrieve information about the usage of free tier resources, which can be helpful for cost management and support inquiries related to free tier limits.
To ensure this permission is necessary and used appropriately, please run the following script:
2295-2300: New OSIS permissions addedSeveral new permissions for the OSIS (Open Search Ingestion Service) have been added to the policy:
osis:getPipelineosis:getPipelineBlueprintosis:getPipelineChangeProgressosis:listPipelineBlueprintsosis:listPipelinesosis:validatePipelineThese permissions allow the support role to manage and monitor OSIS pipelines, which are crucial for data ingestion and processing in OpenSearch environments.
To ensure these permissions are necessary and used appropriately, please run the following script:
| "thinclient:GetEnvironment", | ||
| "thinclient:GetSoftwareSet", |
There was a problem hiding this comment.
💡 Codebase verification
Wildcard Resource Usage in Multiple Statements
The policy contains wildcard "*" in the Resource field for the following statements:
- AllowThinClientReadAccess
- AllowWorkSpacesAccess
- AllowWorkSpacesWebAccess
- AllowAppStreamAccess
This broadens the access scope beyond specific ARNs, which may not adhere to the principle of least privilege. Please review and confirm if granting access to all resources is intentional.
🔗 Analysis chain
Review the changes in the "AllowThinClientReadAccess" statement
-
The reordering of actions (lines 9-10, 13) doesn't affect functionality but may impact readability. Consider maintaining a consistent ordering (e.g., alphabetical) for better maintainability.
-
The Resource specification has been changed to "*" (line 17), which broadens the scope of this policy. This change allows access to all resources instead of being limited to specific ARNs.
Please verify if this broader access is intentional and aligns with the principle of least privilege. If not, consider reverting to a more specific resource ARN.
Also applies to: 13-13, 17-17
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for other occurrences of wildcard resources in the policy
jq '.Statement[] | select(.Resource == "*") | .Sid' docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
Length of output: 291
Script:
#!/bin/bash
# Check for occurrences of wildcard resources in the policy, handling both string and array formats
jq '.Statement[] | select((.Resource == "*") or (.Resource | type == "array" and contains(["*"]))) | .Sid' docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json
Length of output: 293
| "bedrock:getAgent", | ||
| "bedrock:getAgentActionGroup", | ||
| "bedrock:getAgentAlias", | ||
| "bedrock:getAgentKnowledgeBase", | ||
| "bedrock:getAgentVersion", | ||
| "bedrock:getCustomModel", | ||
| "bedrock:getDataSource", | ||
| "bedrock:getIngestionJob", | ||
| "bedrock:getKnowledgeBase", | ||
| "bedrock:getModelCustomizationJob", | ||
| "bedrock:getModelInvocationLoggingConfiguration", | ||
| "bedrock:listAgentActionGroups", | ||
| "bedrock:listAgentAliases", | ||
| "bedrock:listAgentKnowledgeBases", | ||
| "bedrock:listAgents", | ||
| "bedrock:listAgentVersions", | ||
| "bedrock:listCustomModels", | ||
| "bedrock:listDataSources", | ||
| "bedrock:listIngestionJobs", | ||
| "bedrock:listKnowledgeBases", | ||
| "bedrock:listModelCustomizationJobs", | ||
| "bedrock:listProvisionedModelThroughputs", |
There was a problem hiding this comment.
💡 Codebase verification
Unnecessary Bedrock Permissions Detected
No usage of the added Bedrock permissions was found in the codebase. Consider reviewing and minimizing these permissions to adhere to the principle of least privilege.
🔗 Analysis chain
Extensive new permissions added for AWS Bedrock service
A comprehensive set of permissions for the AWS Bedrock service has been added to the policy. These new permissions significantly expand the role's capabilities in AI and machine learning operations, including:
- Agent management (e.g.,
getAgent,listAgents) - Model customization (e.g.,
getCustomModel,listCustomModels) - Job handling (e.g.,
getModelCustomizationJob,listModelCustomizationJobs) - Knowledge base operations (e.g.,
getKnowledgeBase,listKnowledgeBases)
While these additions enhance support capabilities for AWS's machine learning offerings, the broad scope of these permissions warrants careful consideration.
To ensure these permissions align with the principle of least privilege and are necessary for support operations, please run the following script:
Correction Needed in Permission Analysis Script
The previous script incorrectly searched for inspector2 permissions instead of bedrock. Please use the updated script below to accurately analyze Bedrock permissions:
Policy File Not Found: Please Verify Policy File Location
The AWSSupportServiceRolePolicy.json file does not exist in the repository. Please run the following script to locate the correct policy file:
Proceed with Bedrock Permissions Verification
Please run the following script to extract Bedrock permissions from the policy file and search for their usage in the codebase:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Analyze Bedrock permissions usage
# Extract and list all Bedrock permissions
echo "Bedrock permissions in the policy:"
jq -r '.Statement[].Action[]' AWSSupportServiceRolePolicy.json | grep "^bedrock:" | sort
# Search the codebase for references to Bedrock permissions
echo "Searching for Bedrock permission usage in the codebase:"
rg "bedrock:(get|list)" --type md
echo "Review the output to determine if the granted permissions align with your Bedrock resource usage and support requirements."
Length of output: 829
Script:
#!/bin/bash
# Description: Corrected analysis of Bedrock permissions usage
# Extract and list all Bedrock permissions
echo "Bedrock permissions in the policy:"
jq -r '.Statement[].Action[]' AWSSupportServiceRolePolicy.json | grep "^bedrock:" | sort
# Search the codebase for references to Bedrock permissions across relevant file types
echo "Searching for Bedrock permission usage in the codebase:"
rg "bedrock:(get|list)" --type js --type py --type ts --type md
echo "Review the output to determine if the granted permissions align with your Bedrock resource usage and support requirements."
Length of output: 702
Script:
#!/bin/bash
# Description: Locate AWS Support Service Role Policy files in the repository
echo "Searching for AWS Support Service Role Policy JSON files:"
fd "AWSSupport.*Service.*Policy\.json$" --type f
Length of output: 245
Script:
#!/bin/bash
# Description: Analyze Bedrock permissions usage from the identified policy file
# Extract and list all Bedrock permissions
echo "Bedrock permissions in the policy:"
jq -r '.Statement[].Action[]' docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json | grep "^bedrock:" | sort
# Search the codebase for references to Bedrock permissions across relevant file types
echo "Searching for Bedrock permission usage in the codebase:"
rg "bedrock:(get|list)" --type js --type py --type ts --type md
echo "Review the output to determine if the granted permissions align with your Bedrock resource usage and support requirements."
Length of output: 1252
| "codeconnections:getConnection", | ||
| "codeconnections:getHost", | ||
| "codeconnections:getRepositoryLink", | ||
| "codeconnections:getRepositorySyncStatus", | ||
| "codeconnections:getResourceSyncStatus", | ||
| "codeconnections:getSyncBlockerSummary", | ||
| "codeconnections:getSyncConfiguration", | ||
| "codeconnections:listConnections", | ||
| "codeconnections:listHosts", | ||
| "codeconnections:listRepositoryLinks", | ||
| "codeconnections:listRepositorySyncDefinitions", | ||
| "codeconnections:listSyncConfigurations", |
There was a problem hiding this comment.
💡 Codebase verification
Unused CodeConnections Permissions Detected
The newly added CodeConnections permissions are defined in the policy but are not utilized within the application's operational code. Please review and consider removing these unused permissions to enhance security.
- File:
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json(Lines: 547-558)
🔗 Analysis chain
New permissions added for CodeConnections service
The policy now includes several new permissions for the CodeConnections service:
codeconnections:getConnectioncodeconnections:getHostcodeconnections:getRepositoryLinkcodeconnections:getRepositorySyncStatuscodeconnections:getResourceSyncStatuscodeconnections:getSyncBlockerSummarycodeconnections:getSyncConfigurationcodeconnections:listConnectionscodeconnections:listHostscodeconnections:listRepositoryLinkscodeconnections:listRepositorySyncDefinitionscodeconnections:listSyncConfigurations
These permissions allow the support role to access and manage CodeConnections resources, which are crucial for CI/CD processes and repository management.
To ensure these permissions are necessary and used appropriately, please run the following script:
Run Updated Verification Script
Please execute the following shell script to search for CodeConnections references in AWS Support documentation:
[/run_scripts]
Further Verification Required: Search Codebase for CodeConnections Usage
Please execute the following shell script to search for CodeConnections references within the codebase:
[/run_scripts]
Run Corrected Verification Script
Please execute the following shell script to search for CodeConnections references within the codebase:
[/run_scripts]
Further Verification Required: Search for Usage of New CodeConnections Permissions in Application Code
Please execute the following shell script to identify where the new CodeConnections permissions are used within the application's operational code:
[/run_scripts]
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for CodeConnections usage in AWS Support documentation
echo "Searching for CodeConnections references in AWS Support documentation:"
rg -i "codeconnections" --type md
echo "Review the results to confirm if these permissions are necessary for support operations."
Length of output: 829
Script:
#!/bin/bash
# Description: Check for CodeConnections usage in AWS Support documentation
echo "Searching for CodeConnections references in AWS Support documentation:"
rg -i "codeconnections" --type md
echo "Review the results to confirm if these permissions are necessary for support operations related to CodeConnections service."
Length of output: 481
Script:
#!/bin/bash
# Description: Search for CodeConnections usage in the codebase
echo "Searching for CodeConnections references in the codebase:"
rg -i "codeconnections" --type js,py,java,ts
echo "Review the results to confirm if the added permissions are utilized in the code."
Length of output: 378
Script:
#!/bin/bash
# Description: Search for CodeConnections usage in the codebase
echo "Searching for CodeConnections references in the codebase:"
rg -i "codeconnections" --type js --type py --type java --type ts
echo "Review the results to confirm if the added permissions are utilized in the code."
Length of output: 7173
Script:
#!/bin/bash
# Description: Search for usage of specific CodeConnections permissions in the codebase
echo "Searching for usage of CodeConnections permissions in the application code:"
# List of new permissions to verify
permissions=(
"codeconnections:getConnection"
"codeconnections:getHost"
"codeconnections:getRepositoryLink"
"codeconnections:getRepositorySyncStatus"
"codeconnections:getResourceSyncStatus"
"codeconnections:getSyncBlockerSummary"
"codeconnections:getSyncConfiguration"
"codeconnections:listConnections"
"codeconnections:listHosts"
"codeconnections:listRepositoryLinks"
"codeconnections:listRepositorySyncDefinitions"
"codeconnections:listSyncConfigurations"
)
# Iterate over each permission and search in code files
for permission in "${permissions[@]}"; do
echo "Searching for permission: $permission"
rg -i "$permission" --type js --type py --type java --type ts
done
echo "Review the results to confirm if the added permissions are actively used in the application."
Length of output: 3887
udondan
force-pushed
the
update-aws-managed-policies
branch
from
5176638
to
02ee023
Compare
udondan
force-pushed
the
update-aws-managed-policies
branch
from
02ee023
to
648427b
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (5)
docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json (1)
11-11: Consider documenting the "AWS/SocialMessaging" namespace.The CloudWatch namespace "AWS/SocialMessaging" is not a standard AWS namespace. It might be beneficial to add documentation explaining the purpose and usage of this custom namespace.
Would you like me to create a GitHub issue to track the task of adding documentation for this custom namespace?
docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json (2)
3-11: LGTM: Permissions are appropriate for organization discovery.The policy grants read-only permissions for AWS Organizations, which aligns with the policy's intended purpose of organization discovery. The specific actions allowed (DescribeOrganization, DescribeAccount, and ListAccounts) are appropriate for this use case.
Consider adding a comment in the policy to explain the purpose of these permissions, e.g.:
"Comment": "Allows AWS Data Exchange to discover and describe AWS Organizations structure",This would improve clarity for future readers or auditors of the policy.
12-14: Resource specification is acceptable, but consider potential refinement.The use of "*" as the resource specifier is common for AWS Organizations actions and is acceptable in this context. However, as a general security best practice, it's worth considering if the resource scope can be narrowed.
If feasible, consider refining the resource specification to the organization's ARN. This would look like:
"Resource": "arn:aws:organizations::*:organization/o-xxxxxxxxxx"Note that this would require knowing the organization ID in advance and may not be practical if this policy is intended to be used across multiple organizations. If that's not possible or practical, the current "*" specification is acceptable for these read-only actions.
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (1)
Documentation Update Required for Amazon Connect Service-Linked Role Policy Changes
The current documentation does not reflect the recent policy changes related to Customer Profiles segmentation and Wisdom message templates. Please update the following areas to ensure consistency and clarity:
- README.md: Add sections detailing the new Customer Profiles segmentation capabilities.
- Documentation Files: Include information about the expanded Wisdom message template permissions.
- Codebase References:
- Update
index.jsonand relevant TypeScript files to ensure all references toAmazonConnectServiceLinkedRolePolicyare accurate and reflect the latest changes.🔗 Analysis chain
Line range hint
1-258: Summary: Comprehensive update to Amazon Connect Service-Linked Role PolicyThis update to the AmazonConnectServiceLinkedRolePolicy significantly enhances the capabilities of Amazon Connect, particularly in the areas of Customer Profiles and Wisdom services. Key changes include:
- Expanded permissions for Customer Profiles, including new segmentation capabilities.
- Enhanced read permissions for Customer Profile Objects.
- Comprehensive new permissions for Wisdom message template management.
- Addition of a new section specifically for Customer Profiles segmentation.
These changes align well with the PR objectives of updating AWS managed policies. They provide more granular control and expanded functionality for Amazon Connect services while maintaining proper resource scoping and adhering to least privilege principles.
To ensure these policy changes are properly reflected in the codebase and documentation, please run the following verification script:
This script will help identify any areas in the documentation or codebase that may need to be updated to reflect these policy changes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if the README or documentation has been updated to reflect these policy changes # Search for mentions of new Customer Profiles and Wisdom capabilities in README and docs grep -R -i "customer profiles.*segment" README.md docs/ grep -R -i "wisdom.*message.*template" README.md docs/ # Check if there are any hardcoded references to the old policy that might need updating grep -R "AmazonConnectServiceLinkedRolePolicy" --exclude="*AmazonConnectServiceLinkedRolePolicy.json" .Length of output: 46292
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (1)
276-297: Well-structured permission for SAP resource group managementThe new SsmSapResourceGroup statement is well-designed:
- It allows necessary actions for creating and tagging SAP-related resource groups.
- The conditions effectively limit the scope and ensure proper tagging.
- The use of ArnLike condition for the awsApplication tag is a good security practice.
Consider adding a
StringLikecondition for the group name to ensure it always starts with "SystemsManagerForSAP-":"StringLike": { "resource-groups:GroupName": "SystemsManagerForSAP-*" }This would provide an additional layer of control over resource group naming.
📜 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 (69)
- 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/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/AWSDataExchangeProviderFullAccess.json (11 hunks)
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json (1 hunks)
- docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.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/AWSIAMIdentityCenterAllowListForIdentityContext.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 (1 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/AWS_ConfigRole.json (14 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 (4 hunks)
- docs/source/_static/managed-policies/AmazonConnectSynchronizationServiceRolePolicy.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/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/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/AmazonWorkSpacesThinClientFullAccess.json (1 hunks)
- docs/source/_static/managed-policies/AmazonWorkSpacesThinClientReadOnlyAccess.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookPolicy.json (2 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedNotebookServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedPolicy.json (1 hunks)
- docs/source/_static/managed-policies/AwsGlueSessionUserRestrictedServiceRole.json (1 hunks)
- docs/source/_static/managed-policies/IVSReadOnlyAccess.json (2 hunks)
- docs/source/_static/managed-policies/PowerUserAccess.json (1 hunks)
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json (1 hunks)
- docs/source/_static/managed-policies/ReadOnlyAccess.json (18 hunks)
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json (2 hunks)
- docs/source/_static/managed-policies/SecurityAudit.json (2 hunks)
- docs/source/_static/managed-policies/index.json (1 hunks)
💤 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 (51)
- 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/AWSCompromisedKeyQuarantineV3.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/AWSIAMIdentityCenterAllowListForIdentityContext.json
- docs/source/_static/managed-policies/AWSPCSServiceRolePolicy.json
- docs/source/_static/managed-policies/AWSResilienceHubAsssessmentExecutionPolicy.json
- docs/source/_static/managed-policies/AWSResourceExplorerServiceRolePolicy.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/AWSSupportPlansFullAccess.json
- docs/source/_static/managed-policies/AWSSupportPlansReadOnlyAccess.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/AmazonEC2ContainerRegistryPullOnly.json
- docs/source/_static/managed-policies/AmazonEC2RolePolicyForLaunchWizard.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/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
- docs/source/_static/managed-policies/AmazonSageMakerHyperPodServiceRolePolicy.json
- docs/source/_static/managed-policies/AmazonTimestreamInfluxDBFullAccess.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/IVSReadOnlyAccess.json
- docs/source/_static/managed-policies/PowerUserAccess.json
- docs/source/_static/managed-policies/QAppsServiceRolePolicy.json
- docs/source/_static/managed-policies/SSMQuickSetupRolePolicy.json
- docs/source/_static/managed-policies/SecurityAudit.json
- docs/source/_static/managed-policies/index.json
🧰 Additional context used
🔇 Additional comments (78)
docs/source/_static/managed-policies/AWSSocialMessagingServiceRolePolicy.json (1)
1-16: LGTM! Well-structured IAM policy adhering to best practices.The policy is well-defined and follows AWS best practices:
- It adheres to the principle of least privilege by allowing only the necessary action (
cloudwatch:PutMetricData).- The condition further restricts the scope of the permission to a specific CloudWatch namespace.
- The policy is focused on a single responsibility (CloudWatch metric publishing).
To ensure this policy is intended for use as a service role, please run the following command:
This will help verify if the policy is documented or referenced as a service role policy in the project.
docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForOrganizationDiscovery.json (2)
1-2: LGTM: Policy structure and version are correct.The policy uses the standard JSON structure for AWS IAM policies, and the "Version" is set to "2012-10-17", which is the current version for IAM policy language.
1-17: Overall, the policy is well-designed and appropriate for its purpose.This new AWS Data Exchange service role policy for organization discovery is well-structured and grants appropriate read-only permissions. It follows AWS best practices and limits the scope of actions to what's necessary for organization discovery.
The minor suggestions provided (adding a comment for clarity and considering resource refinement) are optimizations rather than critical changes. The policy as it stands is suitable for use and aligns well with its intended purpose.
docs/source/_static/managed-policies/AWSDataExchangeServiceRolePolicyForLicenseManagement.json (3)
1-19: LGTM: Policy structure follows AWS best practices.The overall structure of the policy is correct and adheres to AWS IAM policy best practices. It includes the required "Version" field and a "Statement" array.
2-2: LGTM: Policy version is correct.The Version "2012-10-17" is the most recent and correct version for AWS IAM policies.
1-1: Clarify policy name and purpose.There seems to be a discrepancy between the policy name and its contents:
- The policy is named "AWSDataExchangeServiceRolePolicyForLicenseManagement", suggesting it's for AWS Data Exchange.
- However, the permissions granted are primarily for AWS License Manager.
- The statement Sid "AllowLicenseManagerActions" accurately reflects the permissions, but doesn't mention Data Exchange.
Consider clarifying the relationship between AWS Data Exchange and these License Manager permissions. If this policy is indeed intended for AWS Data Exchange, consider adding a comment explaining how these License Manager permissions are used in the context of Data Exchange.
To help verify the intended use of this policy, you can search for references to it in the codebase:
#!/bin/bash # Description: Search for references to this policy in the codebase # Expected result: Any code that uses or references this policy rg "AWSDataExchangeServiceRolePolicyForLicenseManagement" --type python --type javascript --type typescriptThis may provide context on how and where this policy is intended to be used.
Also applies to: 5-5
docs/source/_static/managed-policies/AWSDataSyncServiceRolePolicy.json (4)
1-3: LGTM: Policy structure and metadata are correct.The policy is well-structured with the correct version "2012-10-17" and follows AWS IAM policy best practices.
Also applies to: 25-26
4-14: LGTM: First statement follows security best practices.The "DataSyncCloudWatchLogCreateAccess" statement correctly grants minimal permissions for creating DataSync-specific log groups and streams. The resource ARN pattern effectively restricts the scope, adhering to the principle of least privilege.
15-24: LGTM: Second statement follows security best practices.The "DataSyncCloudWatchLogStreamUpdateAccess" statement correctly grants minimal permissions for writing log events to DataSync-specific log streams. The resource ARN pattern effectively restricts the scope, adhering to the principle of least privilege.
1-26: Overall policy assessment: Well-structured and secure.The AWSDataSyncServiceRolePolicy is well-crafted, granting necessary permissions for DataSync to interact with CloudWatch Logs while adhering to the principle of least privilege. The policy is limited to DataSync-specific log groups and streams, following AWS IAM best practices.
To ensure completeness, please verify that these permissions are sufficient for all DataSync operations. Run the following script to check for any existing DataSync policies that might have additional permissions:
docs/source/_static/managed-policies/AmazonECSInfrastructureRolePolicyForVolumes.json (1)
18-23:⚠️ Potential issueSecurity concern: Overly broad permissions for volume creation from snapshots
The new statement "CreateEBSManagedVolumeFromSnapshot" allows the creation of EBS volumes from any snapshot without any conditions. This broad permission raises several security concerns:
- It doesn't adhere to the principle of least privilege.
- It allows volume creation from any snapshot in any region, which may be unnecessarily permissive.
- It lacks the conditions present in other statements of this policy, such as tags that ensure the volumes are managed by Amazon ECS.
Consider refining this permission by:
Adding conditions to limit the scope, such as:
- Restricting to specific regions if applicable.
- Adding tag conditions similar to the "CreateEBSManagedVolume" statement.
Specifying a more restrictive resource ARN if possible, rather than allowing all snapshots.
Example of a more restrictive policy:
{ "Sid": "CreateEBSManagedVolumeFromSnapshot", "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:snapshot/*", "Condition": { "StringEquals": { "aws:RequestTag/AmazonECSManaged": "true" }, "ArnLike": { "aws:RequestTag/AmazonECSCreated": "arn:aws:ecs:*:*:task/*" } } }This change would align the new statement with the existing policy structure and improve overall security.
To ensure this change doesn't break existing functionality, please verify:
✅ Verification successful
Permissions update is secure and follows best practices
After verifying, there are no existing uses of
ec2:CreateVolumewithout conditions, and no ECS-related code is affected. The proposed changes to add conditions are safe and enhance security by adhering to the principle of least privilege.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any existing use of ec2:CreateVolume action without conditions rg --json -g '*.tf' -g '*.yaml' -g '*.yml' 'ec2:CreateVolume' | jq '.data.lines.text' | grep -v 'Condition' # Look for any ECS-related code that might be affected by this change rg --json -A 5 -B 5 'resource\s+"aws_ecs_' | jq '.data.lines.text'Length of output: 180
docs/source/_static/managed-policies/AmazonConnectCampaignsServiceLinkedRolePolicy.json (7)
5-11: Approve with clarification: Broad resource scope for ConnectCampaignAccessThe new statement allows listing campaigns across all resources, which is likely necessary for the service-linked role. However, the use of "*" for the Resource field grants this permission broadly.
Could you please clarify if this broad scope is intentional and necessary? If possible, consider restricting the resource scope to specific AWS regions or accounts.
13-22: Approve: Enhanced ConnectAccess permissionsThe updated statement appropriately adds permissions for describing contact flows and sending outbound emails, which align with the Connect service and campaigns functionality. The resource scope is correctly limited to Connect instances.
24-35: Approve: Secure EventBridge rule listingThis new statement grants permission to list EventBridge rules with appropriate security measures. The condition ensuring that the role can only list rules in its own account is a commendable security practice.
37-52: Approve: Well-scoped EventBridge rule managementThis statement provides necessary permissions for managing EventBridge rules related to Connect Campaigns. The security measures are commendable:
- Resource names are restricted to those starting with "ConnectCampaignsRule".
- Actions are limited to the same account.
- The "events:ManagedBy" condition ensures only rules managed by connect-campaigns can be modified.
These restrictions effectively minimize the potential for misuse.
54-65: Approve: Consistent EventBridge target listing permissionThis statement grants permission to list targets for EventBridge rules, maintaining consistency with the previous statement. The resource restriction to rules starting with "ConnectCampaignsRule" and the condition limiting access to the same account provide appropriate security boundaries.
67-78: Approve with suggestion: Wisdom permissions for tagged resourcesThis statement appropriately grants permissions for AWS Wisdom operations on resources tagged for Amazon Connect Campaigns. The use of a specific tag for access control is a good practice.
However, consider if it's possible to narrow down the resource scope from "*" to specific AWS Wisdom resource types or ARNs that are relevant to Connect Campaigns. This would further enhance the principle of least privilege.
Could you please verify if it's feasible to specify more precise resource ARNs for the Wisdom permissions, rather than using "*"?
Line range hint
1-80: Overall assessment: Comprehensive and security-conscious policy updateThis update to the AmazonConnectCampaignsServiceLinkedRolePolicy significantly enhances the capabilities of the service-linked role while maintaining strong security practices. The changes include:
- New permissions for Connect Campaigns and Connect services.
- Detailed EventBridge rule management capabilities with appropriate restrictions.
- Integration with AWS Wisdom for message templates.
Most additions follow the principle of least privilege, using specific resource ARNs, account restrictions, and tag-based conditions. There are a few instances where resource scopes could potentially be tightened further, which have been noted in individual comments.
These changes align well with the PR objective of updating AWS managed policies and should improve the functionality of Amazon Connect Campaigns while maintaining a strong security posture.
docs/source/_static/managed-policies/AWSCompromisedKeyQuarantineV2.json (6)
67-70: LGTM: Appropriate ECS and ECR restrictions addedThe addition of ECS actions (CreateService, CreateCluster, RegisterTaskDefinition) and ECR's GetAuthorizationToken is appropriate for a compromised key quarantine policy. These restrictions prevent the creation of new container resources and limit access to existing ones, which is crucial in containing potential threats.
71-75: LGTM: Comprehensive Bedrock service restrictions addedThe addition of Bedrock actions (CreateModelInvocationJob, InvokeModelWithResponseStream, CreateFoundationModelAgreement, PutFoundationModelEntitlement, InvokeModel) is a prudent measure for a compromised key quarantine policy. These restrictions prevent the creation, modification, and invocation of AI/ML models, effectively limiting the potential for misuse of these powerful resources in case of a security breach.
76-81: Approve S3 and SageMaker write restrictions, reconsider read operationsThe addition of S3 write actions (CreateBucket, PutBucketCors) and SageMaker actions (CreateEndpointConfig, CreateProcessingJob) is appropriate for a compromised key quarantine policy. These restrictions prevent the creation of new resources that could be exploited.
However, as noted in a previous comment, denying S3 read operations (GetObject, ListBucket) might hinder legitimate administrative tasks and incident response efforts. Unless there's a specific security concern, consider removing these read actions from the deny list.
82-85: Approve STS restrictions, reconsider SES read operationsThe addition of STS actions (GetSessionToken, GetFederationToken) is appropriate for a compromised key quarantine policy as it prevents obtaining new credentials that could be misused.
However, as noted in a previous comment, the SES actions (GetSendQuota, ListIdentities) are read-only operations that don't pose a direct security risk. Denying these might hinder legitimate administrative tasks or incident response efforts. Consider removing these SES actions from the deny list unless there's a specific security concern that justifies their inclusion.
86-92: Approve most additions, reconsider IAM:ListUsersThe additions for Amplify (CreateDeployment, CreateBackendEnvironment), CodeBuild (CreateProject), Glue (CreateJob), and most IAM actions (DeleteRole, DeleteAccessKey) are appropriate for a compromised key quarantine policy. These restrictions prevent the creation of new resources and destructive actions on access controls.
However, as noted in a previous comment, including "iam:ListUsers" in the deny list might hinder legitimate administrative tasks during incident response. Consider removing this action from the deny list, as it's a read-only operation that could be useful for security teams investigating the compromise.
93-95: Approve MediaPackage action, reconsider Lambda and SNS read operationsThe addition of "mediapackagev2:CreateChannel" is appropriate as it prevents the creation of new resources, aligning with the quarantine policy's purpose.
However, as noted in a previous comment, the inclusion of "lambda:GetEventSourceMapping" and "sns:GetSMSAttributes" raises questions:
- These are read-only actions that don't modify resources or escalate privileges.
- Denying these actions might hinder incident response efforts by restricting access to potentially useful information.
Consider removing these read-only actions from the deny list unless there's a specific security concern that justifies their inclusion.
docs/source/_static/managed-policies/AWSDataExchangeProviderFullAccess.json (10)
Line range hint
27-47: Well-defined job management permissions with security constraints.The "DataExchangeJobsActions" statement provides specific permissions for Data Exchange job operations. The condition that restricts job types is a good security practice, ensuring that only approved job types can be executed.
Line range hint
49-61: Secure S3 access for Data Exchange operations.The "S3GetActionConditionalResourceAndADX" statement implements strong security controls:
- It restricts S3 access to buckets containing "aws-data-exchange" in the name.
- It ensures that S3:GetObject actions are only allowed when called via the Data Exchange service.
These constraints align well with the principle of least privilege and help prevent unauthorized access.
Line range hint
104-123: Appropriate AWS Marketplace permissions for Data Exchange operations.The "AWSMarketplaceActions" statement provides necessary permissions for managing Data Exchange products in the AWS Marketplace. The permissions are specific and cover essential operations such as describing entities, managing change sets, and handling agreement approvals.
Line range hint
134-162: Well-scoped Redshift and API Gateway permissions.The new statements provide necessary permissions for Redshift and API Gateway operations:
- "RedshiftConditionalActions" allows data share authorization with a condition ensuring it's only for ADX (AWS Data Exchange).
- "RedshiftActions" permits describing data shares, which is essential for Data Exchange operations.
- "APIGatewayActions" is limited to GET requests, maintaining a read-only approach.
These permissions are appropriately scoped and include necessary conditions, adhering to the principle of least privilege.
Line range hint
1-164: Comprehensive and well-structured AWS Data Exchange provider policy.This updated
AWSDataExchangeProviderFullAccesspolicy provides a robust set of permissions necessary for managing AWS Data Exchange resources and related services. Key points:
- The policy implements several security best practices, including conditional access and service-specific actions.
- Permissions are generally well-scoped, with conditions applied where appropriate to limit potential misuse.
- The policy covers a wide range of services including Data Exchange, S3, AWS Marketplace, KMS, Redshift, and API Gateway, providing the necessary access for complex Data Exchange operations.
While the policy is comprehensive, there are a few areas where permissions could potentially be further restricted (e.g., S3 listing, KMS key access) if not all are necessary for your specific use case.
Overall, this policy provides a good balance between functionality and security for AWS Data Exchange providers.
Line range hint
94-103: Necessary S3 read permissions granted.The "S3ReadActions" statement provides essential S3 read permissions required for basic operations. These read-only actions don't pose significant security risks.
However, consider if listing all buckets (s3:ListAllMyBuckets) is necessary for your use case. If not, you might want to remove this permission to adhere more closely to the principle of least privilege. You can check for any existing use of this permission with:
rg '"s3:ListAllMyBuckets"' --type jsonIf this is the only occurrence, consider removing it unless it's explicitly required for your Data Exchange operations.
Line range hint
62-77: Flexible and secure S3 access based on object tags.The "S3GetActionConditionalTagAndADX" statement implements a flexible access control mechanism:
- It allows S3:GetObject on any resource, but only if tagged appropriately.
- It ensures the action is called via the Data Exchange service.
This approach provides granular control while maintaining flexibility.
Consider adding a condition to restrict access to specific AWS accounts if cross-account access is not required. You can verify the current setup with:
rg '"Principal":\s*{\s*"AWS":\s*".*"' --type jsonIf no results are found, cross-account access is not explicitly allowed in this policy.
Line range hint
78-93: Controlled S3 write access for Data Exchange operations.The "S3WriteActions" statement provides necessary write permissions while implementing security controls:
- It restricts S3 write access to buckets containing "aws-data-exchange" in the name.
- It ensures that S3 write actions are only allowed when called via the Data Exchange service.
These constraints help prevent unauthorized modifications.
However, be cautious with the S3:PutObjectAcl permission, as it allows changing object ACLs. Ensure this aligns with your security requirements. You can check for any existing use of this permission with:
rg '"s3:PutObjectAcl"' --type jsonConsider removing this permission if it's not strictly necessary for your use case.
Line range hint
124-133: Necessary KMS read permissions granted.The "KMSActions" statement provides essential KMS read permissions required for operations involving encrypted resources. These read-only actions don't pose significant security risks.
However, consider if you can restrict these permissions to specific KMS keys used by your Data Exchange resources. You can check for any existing key restrictions with:
rg '"kms:ResourceId"' --type jsonIf no results are found, consider adding a condition to limit these actions to specific KMS keys if possible.
Line range hint
5-25: Comprehensive permissions for Data Exchange operations.The new "DataExchangeActions" statement provides a wide range of permissions necessary for managing AWS Data Exchange resources. This is appropriate for a "FullAccess" policy.
However, consider the principle of least privilege. If possible, narrow down the wildcard permissions (e.g., "Get*", "Update*", "List*", "Delete*") to specific actions required for your use case. Run the following command to check for any existing, more specific Data Exchange permissions:
docs/source/_static/managed-policies/AmazonConnectServiceLinkedRolePolicy.json (4)
80-87: LGTM: Enhanced Customer Profiles capabilitiesThe new permissions added to the "AllowCustomerProfilesForConnectDomain" section expand the capabilities for managing customer profiles and segmentation. These additions include:
- Listing integrations and segment definitions
- Listing profile attribute values
- Creating and getting segment estimates
- Batch operations for profiles and calculated attributes
- Getting segment membership
These changes align with the PR objectives and enhance the functionality of the Amazon Connect service.
96-97: LGTM: Expanded read permissions for Customer Profile ObjectsThe addition of the "profile:ListObjectTypeAttributes" permission in the "AllowReadPermissionForCustomerProfileObjects" section is consistent with the overall updates to the Customer Profiles service. This change enhances the ability to read and list attributes of object types within customer profiles.
149-163: LGTM: Expanded Wisdom capabilities for message template managementThe "AllowWisdomForConnectEnabledTaggedResources" statement has been significantly enhanced with new permissions for managing message templates in Amazon Connect Wisdom. These additions allow for:
- Creating, updating, and deleting message templates
- Managing message template metadata and versions
- Activating and deactivating templates
- Creating and deleting template attachments
- Rendering message templates
These changes align with the PR objectives and greatly expand the functionality available for managing content within the Wisdom service.
As noted in a previous review, please ensure that the project documentation is updated to reflect these new Wisdom message template capabilities.
195-208: LGTM: New section for Customer Profiles segmentationA new section "AllowCustomerProfilesSegmentationForConnectDomain" has been added to the policy. This section introduces specific permissions for managing customer profile segmentation, including:
- Creating, getting, and deleting segment definitions
- Creating and getting segment snapshots
The resource is correctly scoped to the Amazon Connect domain, and this addition complements the earlier changes to the Customer Profiles permissions. This enhancement aligns with the PR objectives and provides more granular control over segmentation operations.
docs/source/_static/managed-policies/AmazonECS_FullAccess.json (9)
Line range hint
128-137: LGTM: SSMPolicy follows security best practicesThe
SSMPolicystatement is well-structured and follows security best practices:
- It allows only the necessary actions:
GetParameter,GetParameters, andGetParametersByPath.- The resource is restricted to ECS-related parameters:
arn:aws:ssm:*:*:parameter/aws/service/ecs*.This approach aligns with the principle of least privilege and provides secure access to ECS-related configuration in SSM Parameter Store.
169-180: LGTM: InfrastructurePassRolePolicy is well-definedThe
InfrastructurePassRolePolicystatement is well-structured and follows security best practices:
- It allows passing only the specific "ecsInfrastructureRole" to the ECS service.
- The condition ensures the role can only be passed to the ECS service.
This approach aligns with the principle of least privilege and provides secure access for ECS infrastructure management.
Line range hint
214-230: LGTM: ServiceLinkedRoleCreationPolicy is well-definedThe
ServiceLinkedRoleCreationPolicystatement is well-structured and follows security best practices:
- It allows creating service-linked roles only for specific AWS services related to ECS operations.
- The condition ensures that only roles for ECS, Auto Scaling, and Spot services can be created.
- The policy follows the principle of least privilege by specifying exact services.
This approach provides the necessary permissions for creating service-linked roles while maintaining tight control over which roles can be created.
Line range hint
231-248: LGTM: ELBTaggingPolicy is well-definedThe
ELBTaggingPolicystatement is well-structured and follows security best practices:
- It allows adding tags only to Elastic Load Balancer resources.
- The condition ensures that tags can only be added during specific resource creation actions.
- The policy follows the principle of least privilege by specifying exact actions and conditions.
This approach provides the necessary permissions for tagging ELB resources related to ECS while maintaining tight control over when these tags can be added.
Line range hint
156-168: Consider restricting roles in TasksPassRolePolicyThe
TasksPassRolePolicystatement allows passing any IAM role to ECS tasks. While the condition ensures roles can only be passed to ECS tasks, allowing any role to be passed could potentially lead to privilege escalation.Consider the following recommendations:
- Restrict the
Resourcefield to specific role ARNs or a naming pattern for roles intended for ECS tasks.- Implement a naming convention for ECS task roles (e.g.,
arn:aws:iam::*:role/ecs-task-*) and use it in the resource field.Example of a more restrictive policy:
{ "Sid": "TasksPassRolePolicy", "Action": "iam:PassRole", "Effect": "Allow", "Resource": "arn:aws:iam::*:role/ecs-task-*", "Condition": { "StringLike": { "iam:PassedToService": "ecs-tasks.amazonaws.com" } } }To help identify existing roles used for ECS tasks, you can use the following script:
#!/bin/bash # List roles used by ECS tasks aws ecs list-task-definitions --output json | jq -r '.taskDefinitionArns[]' | xargs -I {} aws ecs describe-task-definition --task-definition {} --query 'taskDefinition.taskRoleArn' --output text | sort | uniqThis will help you determine which roles should be included in a more specific resource ARN.
Line range hint
181-197: Review wildcard usage in InstancePassRolePolicyThe
InstancePassRolePolicystatement allows passing roles matching "ecsInstanceRole*" to EC2 instances. While this provides flexibility, it might allow passing unintended roles if not carefully managed.Consider the following recommendations:
- Review if the wildcard in "ecsInstanceRole*" is necessary. If possible, specify exact role names.
- If multiple roles are needed, consider listing them explicitly rather than using a wildcard.
- Implement a strict naming convention for ECS instance roles to prevent potential misuse of the wildcard.
Example of a more restrictive policy:
{ "Sid": "InstancePassRolePolicy", "Action": "iam:PassRole", "Effect": "Allow", "Resource": [ "arn:aws:iam::*:role/ecsInstanceRole", "arn:aws:iam::*:role/ecsInstanceRoleECS" ], "Condition": { "StringLike": { "iam:PassedToService": [ "ec2.amazonaws.com", "ec2.amazonaws.com.cn" ] } } }To help identify existing ECS instance roles, you can use the following script:
#!/bin/bash # List roles with names starting with "ecsInstanceRole" aws iam list-roles --query 'Roles[?starts_with(RoleName, `ecsInstanceRole`)].RoleName' --output textThis will help you determine which specific roles should be included in the policy.
Line range hint
198-213: Review wildcard usage in AutoScalingPassRolePolicyThe
AutoScalingPassRolePolicystatement allows passing roles matching "ecsAutoscaleRole*" to the Application Auto Scaling service. Similar to theInstancePassRolePolicy, this flexibility might allow passing unintended roles if not carefully managed.Consider the following recommendations:
- Review if the wildcard in "ecsAutoscaleRole*" is necessary. If possible, specify exact role names.
- If multiple roles are needed, consider listing them explicitly rather than using a wildcard.
- Implement a strict naming convention for ECS auto scaling roles to prevent potential misuse of the wildcard.
Example of a more restrictive policy:
{ "Sid": "AutoScalingPassRolePolicy", "Action": "iam:PassRole", "Effect": "Allow", "Resource": [ "arn:aws:iam::*:role/ecsAutoscaleRole", "arn:aws:iam::*:role/ecsAutoscaleRoleECS" ], "Condition": { "StringLike": { "iam:PassedToService": [ "application-autoscaling.amazonaws.com", "application-autoscaling.amazonaws.com.cn" ] } } }To help identify existing ECS auto scaling roles, you can use the following script:
#!/bin/bash # List roles with names starting with "ecsAutoscaleRole" aws iam list-roles --query 'Roles[?starts_with(RoleName, `ecsAutoscaleRole`)].RoleName' --output textThis will help you determine which specific roles should be included in the policy.
Line range hint
138-155: Review resource scope in ManagedCloudformationResourcesCleanupPolicyThe
ManagedCloudformationResourcesCleanupPolicystatement allows deletion of specific EC2 resources (Internet Gateways, Routes, Route Tables, and Security Groups) created by CloudFormation for ECS. While the condition helps ensure only ECS-related resources are affected, theResourcefield is set to"*", which might be broader than necessary.Consider the following recommendations:
- If possible, restrict the
Resourcefield to specific regions or account IDs where these resources are expected to be created.- Review if all these delete actions are necessary for the intended use case.
- Consider adding additional safeguards, such as requiring multi-factor authentication (MFA) for these destructive actions.
To help identify the regions where these resources are typically created, you can use the following script:
This will help you determine which regions to include in a more specific resource ARN.
Line range hint
5-127: Review broad permissions in ECSIntegrationsManagementPolicyThe
ECSIntegrationsManagementPolicystatement grants a wide range of permissions across multiple AWS services. While it follows the principle of least privilege for most services by specifying exact actions, it uses a wildcard (ecs:*) for ECS actions, which might be overly permissive. Additionally, all actions are allowed on all resources ("Resource": ["*"]).Consider the following recommendations:
- Review if all these permissions are necessary for ECS Full Access.
- Replace
"ecs:*"with specific ECS actions required for the intended use case.- Restrict the
Resourcefield to specific ARNs where possible, instead of using a wildcard.To help identify which ECS actions are actually being used, you can analyze CloudTrail logs. Here's a script to get you started:
This will list all unique ECS actions that have been used, helping you to narrow down the required permissions.
docs/source/_static/managed-policies/AWSSSMForSAPServiceLinkedRolePolicy.json (5)
Line range hint
120-126: Improved security for CreateServiceLinkedRole permissionThe changes to the CreateServiceLinkedRole statement enhance security by:
- Specifying a more precise Resource ARN.
- Adding a Condition to restrict the service name.
These modifications effectively limit the scope of the permission, reducing potential misuse.
299-316: Well-defined permission for managing SAP tags on EC2 instancesThe ManageSsmSapTagsOnEc2Instances statement is well-structured:
- It allows necessary actions for managing SAP-related tags on EC2 instances.
- The condition ensures only instances tagged as SSMForSAPManaged can be modified.
- The tag key restriction to "SystemsManagerForSAP-*" is a good security practice.
These permissions are appropriately scoped and align with the principle of least privilege.
Line range hint
1-353: Summary of AWSSSMForSAPServiceLinkedRolePolicy changesThe updates to this policy generally enhance security and specificity for managing SAP-related resources:
- The CreateServiceLinkedRole permission has been tightened.
- New statements for managing SAP resource groups and tags on EC2 instances are well-structured.
- Two new statements for managing tags on EBS volumes have been added, but could benefit from additional restrictions to ensure they only affect volumes associated with SSM-managed SAP instances.
Overall, these changes improve the policy's alignment with the principle of least privilege, with room for further refinement in EBS volume tagging permissions.
318-332:⚠️ Potential issuePotential over-permissive tagging on EBS volumes
I acknowledge the previous review comment on this segment. The concern about potential over-permissive tagging remains valid:
- The statement allows tagging any EBS volume, not just those associated with SSM-managed SAP instances.
- The only restriction is on the tag keys that can be managed.
To address this, consider adding a condition to restrict this action to EBS volumes associated with SSM-managed SAP instances. For example:
"Condition": { "StringEquals": { "ec2:ResourceTag/SSMForSAPManaged": "True" }, "ForAllValues:StringLike": { "aws:TagKeys": [ "SystemsManagerForSAP-*" ] } }This would ensure that only volumes related to SSM-managed SAP instances can be tagged, aligning with the principle of least privilege.
334-350:⚠️ Potential issueBroad permission for application tagging on EBS volumes
I acknowledge the previous review comment on this segment. The concern about broad permissions for application tagging remains valid:
- The statement allows tagging any EBS volume, not just those associated with SSM-managed SAP instances.
- There's no restriction on which volumes can be tagged, which might be too permissive.
To address this, consider adding a condition to restrict this action to EBS volumes associated with SSM-managed SAP instances. For example:
"Condition": { "StringEquals": { "ec2:ResourceTag/SSMForSAPManaged": "True" }, "ArnLike": { "aws:RequestTag/awsApplication": "arn:aws:resource-groups:*:*:group/*/*" }, "ForAllValues:StringEquals": { "aws:TagKeys": [ "awsApplication" ] } }This would ensure that only volumes related to SSM-managed SAP instances can be tagged with the
awsApplicationtag, aligning with the principle of least privilege.docs/source/_static/managed-policies/AWS_ConfigRole.json (6)
32-43: New AOSS permissions enhance AWS Config capabilitiesThese new Amazon OpenSearch Service (AOSS) permissions allow AWS Config to retrieve and list information about AOSS resources. This addition enhances AWS Config's ability to monitor and assess the configuration of AOSS resources, which is in line with the PR's objective of updating AWS managed policies.
The permissions are appropriately scoped to read-only operations, maintaining the principle of least privilege for the AWS Config role.
89-89: New AppStream permission for enhanced resource monitoringThe addition of
appstream:DescribeAppBlockBuilderspermission allows AWS Config to retrieve information about AppStream AppBlockBuilders. This enhances AWS Config's ability to monitor and assess the configuration of AppStream resources, which is in line with the PR's objective of updating AWS managed policies.This read-only permission maintains the principle of least privilege for the AWS Config role.
136-137: New AWS Backup permissions for restore testing monitoringThe addition of these AWS Backup permissions (
GetRestoreTestingPlan,GetRestoreTestingSelection,ListRestoreTestingPlans,ListRestoreTestingSelections) allows AWS Config to retrieve and list information about restore testing plans and selections. This enhancement enables AWS Config to monitor and assess the configuration of AWS Backup restore testing resources, aligning with the PR's objective of updating AWS managed policies.These read-only permissions maintain the principle of least privilege for the AWS Config role and improve its capability to oversee backup and recovery configurations.
Also applies to: 144-145
185-185: New CloudTrail permissions for channel monitoringThe addition of
cloudTrail:GetChannelandcloudTrail:ListChannelspermissions allows AWS Config to retrieve and list information about CloudTrail channels. This enhancement enables AWS Config to monitor and assess the configuration of CloudTrail channels, which aligns with the PR's objective of updating AWS managed policies.These read-only permissions maintain the principle of least privilege for the AWS Config role and improve its capability to oversee CloudTrail configurations, potentially enhancing security and compliance monitoring.
Also applies to: 189-189
354-354: Comprehensive update with new permissions across multiple AWS servicesThis update adds new permissions for various AWS services including EC2, ImageBuilder, IoT, IVS, MediaConnect, MediaTailor, Omics, Scheduler, and SSM-SAP. These additions significantly enhance AWS Config's ability to monitor and assess the configuration of a wide range of AWS resources. Key points:
- EC2: Added permission to describe VPC endpoints.
- ImageBuilder: New permissions for lifecycle policies.
- IoT: Extended permissions for billing groups.
- IVS: New permissions for encoder configurations, playback restriction policies, stages, and storage configurations.
- MediaConnect: Added permissions for bridges and gateways.
- MediaTailor: New permissions for channels, live sources, source locations, and VOD sources.
- Omics: Added permissions for workflows.
- Scheduler: New permissions for schedules.
- SSM-SAP: Added permission to list tags for resources.
These read-only permissions maintain the principle of least privilege for the AWS Config role while significantly expanding its capability to monitor and assess the configuration of various AWS resources. This comprehensive update aligns well with the PR's objective of updating AWS managed policies and enhances AWS Config's ability to support security, compliance, and operational assessments across a broader range of AWS services.
Also applies to: 659-659, 669-669, 676-676, 693-693, 769-782, 905-910, 917-926, 970-971, 1256-1257, 1308-1308
Line range hint
1-1391: Summary: Comprehensive and secure update to AWS Config Role permissionsThis update to the AWS Config Role policy significantly enhances its capabilities across a wide range of AWS services. The new permissions allow AWS Config to monitor and assess the configuration of additional resources in services such as AOSS, AppStream, AWS Backup, CloudTrail, EC2, ImageBuilder, IoT, IVS, MediaConnect, MediaTailor, Omics, and Scheduler.
Key points:
- All new permissions are read-only, maintaining the principle of least privilege.
- The additions align with the existing pattern of allowing AWS Config to describe, get, and list various resources.
- These changes enable more comprehensive security, compliance, and operational assessments.
- No potential security risks were identified in the added permissions.
Overall, this update successfully achieves the PR's objective of updating AWS managed policies, enhancing AWS Config's functionality while maintaining a secure posture.
docs/source/_static/managed-policies/AWSConfigServiceRolePolicy.json (8)
32-43: LGTM: New AOSS permissions enhance AWS Config capabilitiesThe addition of these Amazon OpenSearch Service (AOSS) permissions is appropriate. They allow AWS Config to retrieve and list information about AOSS resources, including collections, lifecycle policies, VPC endpoints, access policies, and security configurations. This enhancement enables AWS Config to effectively monitor and assess the configuration of AOSS resources, which is consistent with its primary function.
135-136: LGTM: New AWS Backup permissions enhance monitoring capabilitiesThe addition of these AWS Backup permissions is appropriate. They allow AWS Config to retrieve and list information about restore testing plans and selections. This enhancement enables AWS Config to monitor and assess the configuration of AWS Backup resources, particularly focusing on the restore testing aspect. This is in line with AWS Config's role in ensuring proper backup and recovery setups across AWS resources.
Also applies to: 143-144
88-88: LGTM: New AppStream permission adds monitoring capabilityThe addition of the
appstream:DescribeAppBlockBuilderspermission is appropriate. It allows AWS Config to retrieve information about AppStream 2.0 AppBlock builders. This enhancement enables AWS Config to monitor and assess the configuration of AppStream resources, specifically focusing on the AppBlock builders used for creating and managing application blocks. This addition is consistent with AWS Config's role in comprehensive resource monitoring.
566-566: LGTM: New Glue permissions enhance ETL monitoringThe addition of
glue:GetTriggerandglue:ListTriggerspermissions is appropriate. These permissions allow AWS Config to retrieve and list information about Glue triggers, which are used to initiate, schedule, and run Glue jobs. This enhancement enables AWS Config to monitor and assess the configuration of Glue resources, particularly focusing on the trigger mechanisms for ETL processes. This addition aligns with AWS Config's role in comprehensive monitoring of AWS resources, including data processing and ETL workflows.Also applies to: 572-572
767-772: LGTM: New IVS permissions enhance video streaming service monitoringThe addition of these Interactive Video Service (IVS) permissions is appropriate. They allow AWS Config to retrieve and list information about various IVS resources, including encoder configurations, playback restriction policies, stages, and storage configurations. This enhancement enables AWS Config to monitor and assess the configuration of IVS resources comprehensively. These additions align with AWS Config's role in providing insights into the setup and configuration of AWS services, now extending to video streaming services. This will help ensure proper configuration and compliance for IVS resources.
Also applies to: 775-780
903-903: LGTM: New MediaConnect permissions improve media service monitoringThe addition of these MediaConnect permissions is appropriate. They allow AWS Config to describe and list information about MediaConnect bridges and gateways. These components are crucial for live video transport in MediaConnect. This enhancement enables AWS Config to monitor and assess the configuration of MediaConnect resources more comprehensively. These additions align with AWS Config's role in providing insights into the setup and configuration of AWS services, now extending to important components of media services. This will help ensure proper configuration and compliance for MediaConnect resources.
Also applies to: 905-906, 908-908
915-918: LGTM: New MediaTailor permissions enhance video personalization service monitoringThe addition of these MediaTailor permissions is appropriate. They allow AWS Config to describe and list information about various MediaTailor resources, including channels, live sources, source locations, and VOD sources. These components are crucial for video personalization and monetization in MediaTailor. This enhancement enables AWS Config to monitor and assess the configuration of MediaTailor resources comprehensively. These additions align with AWS Config's role in providing insights into the setup and configuration of AWS services, now extending to important components of media personalization services. This will help ensure proper configuration and compliance for MediaTailor resources, supporting better management of video content delivery and monetization strategies.
Also applies to: 920-924
968-969: LGTM: New Omics and Scheduler permissions expand monitoring capabilitiesThe addition of these Omics and Scheduler permissions is appropriate.
For Omics, the permissions allow AWS Config to get and list information about Omics workflows. This enables monitoring and assessment of genomics and bioinformatics processing configurations, which is crucial for maintaining compliance and optimal performance in scientific computing environments.
For Scheduler, the permissions allow AWS Config to get and list information about schedules. This enables monitoring and assessment of task scheduling configurations across AWS services, which is important for ensuring proper resource utilization and workflow management.
These additions align with AWS Config's role in providing comprehensive insights into the setup and configuration of diverse AWS services. This expansion of monitoring capabilities will help ensure proper configuration, compliance, and efficient operation of both scientific workflows and scheduled tasks across the AWS ecosystem.
Also applies to: 1254-1255
docs/source/_static/managed-policies/ReadOnlyAccess.json (6)
111-111: Approval: Addition of "application-signals:ListServices" permissionThe addition of the "application-signals:ListServices" permission is appropriate for this read-only policy. It allows users to list services in the Application Signals service without granting any write or modify permissions, which is consistent with the policy's purpose.
222-225: Approval: Addition of Bedrock service read-only permissionsThe new permissions added for the AWS Bedrock service (GetEvaluationJob, GetGuardrail, ListEvaluationJobs, ListGuardrails, etc.) are appropriate for this read-only policy. These additions allow users to retrieve information about Bedrock resources without granting any write or modify permissions, maintaining the policy's read-only intent.
Also applies to: 239-242
275-275: Approval: Addition of "budgets:ListTagsForResource" permissionThe addition of the "budgets:ListTagsForResource" permission is appropriate for this read-only policy. It allows users to view tags associated with AWS Budgets resources, which is useful for cost allocation and organization purposes. This addition maintains the read-only nature of the policy.
318-328: Approval: Addition of Clean Rooms ML service read-only permissionsThe new permissions added for the AWS Clean Rooms ML service (GetAudienceGenerationJob, GetAudienceModel, ListAudienceExportJobs, etc.) are appropriate for this read-only policy. These additions allow users to retrieve information about Clean Rooms ML resources and operations without granting any write or modify permissions, maintaining the policy's read-only intent.
1922-1938: Approval: Addition of S3 on Outposts service read-only permissionsThe new permissions added for the AWS S3 on Outposts service (GetBucketVersioning, GetObject, ListBucket, etc.) are appropriate for this read-only policy. These additions allow users to retrieve information about S3 on Outposts resources and perform read operations without granting any write or modify permissions, maintaining the policy's read-only intent.
Line range hint
1-2175: Summary: Appropriate updates to ReadOnlyAccess policyThe changes made to the ReadOnlyAccess policy are appropriate and maintain its intended purpose. The additions expand the policy's coverage to include newer AWS services and operations while consistently adhering to read-only permissions. These updates ensure that users with this policy can view and list resources across a wide range of AWS services without the ability to modify or delete them. The policy remains a comprehensive and secure option for granting read-only access to AWS resources.
docs/source/_static/managed-policies/AWSSupportServiceRolePolicy.json (6)
87-88: New account service permissions look appropriate.The addition of "account:getRegionOptStatus" and "account:listRegions" permissions allows the AWS Support Service Role to query region-specific information. This is beneficial for diagnosing region-related issues and aligns with the role's support functions.
365-386: Comprehensive new permissions added for AWS Bedrock service.A significant number of new permissions have been added for the AWS Bedrock service, covering a wide range of operations including managing agents, models, knowledge bases, and customization jobs. While these may be necessary for providing comprehensive support for Bedrock-related issues, the extensive nature of these permissions warrants a careful review.
To ensure these permissions are necessary and used appropriately, please run the following script:
#!/bin/bash # Description: Check for Bedrock-related support cases or documentation echo "Searching for Bedrock-related support documentation:" rg -i "bedrock" --type md docs/support/ echo "Searching for Bedrock permissions in other AWS service roles:" for file in $(find . -name '*ServiceRolePolicy.json'); do if grep -q "bedrock:" "$file"; then echo "Found Bedrock permissions in $file" grep "bedrock:" "$file" fi done echo "Review the results to confirm if these extensive Bedrock permissions are consistent with other support-related policies and documented use cases."
589-600: New permissions added for AWS CodeConnections service.The policy now includes permissions for the AWS CodeConnections service, which is used for connecting to external source control providers. While these may be necessary for supporting CodePipeline or related services, the addition of a new service to the support role should be carefully considered.
To ensure these permissions are necessary for support operations, please run the following script:
#!/bin/bash # Description: Check for CodeConnections-related support cases or documentation echo "Searching for CodeConnections-related support documentation:" rg -i "codeconnections" --type md docs/support/ echo "Searching for CodeConnections permissions in other AWS service roles:" for file in $(find . -name '*ServiceRolePolicy.json'); do if grep -q "codeconnections:" "$file"; then echo "Found CodeConnections permissions in $file" grep "codeconnections:" "$file" fi done echo "Review the results to confirm if these CodeConnections permissions are consistent with support requirements and other support-related policies."
196-202: Multiple new permissions added across various AWS services.New permissions have been added for several services including:
- application-signals
- freetier
- inspector2
- osis
- workspaces
- xray
While these additions likely enhance the support role's ability to diagnose and resolve issues across a wide range of AWS services, it's important to ensure that each new permission is necessary and follows the principle of least privilege.
To validate the necessity of these new permissions, please run the following script:
#!/bin/bash # Description: Analyze new permissions across various services services=("application-signals" "freetier" "inspector2" "osis" "workspaces" "xray") for service in "${services[@]}"; do echo "Searching for $service-related support documentation:" rg -i "$service" --type md docs/support/ echo "Checking for $service permissions in other AWS service roles:" for file in $(find . -name '*ServiceRolePolicy.json'); do if grep -q "$service:" "$file"; then echo "Found $service permissions in $file" grep "$service:" "$file" fi done echo "---" done echo "Review the results to confirm if these new permissions across various services are consistent with support requirements and other support-related policies."Also applies to: 1401-1401, 1695-1696, 2357-2362, 3432-3435, 3447-3453
Line range hint
1-3453: Recommend comprehensive security review of extensive policy changes.This update significantly expands the AWSSupportServiceRolePolicy with numerous new permissions across a wide range of AWS services. While these additions generally align with the support role's purpose of providing comprehensive assistance, the extensive nature of these changes warrants a careful security review.
Key points to consider:
- The policy now includes permissions for several new services (e.g., Bedrock, CodeConnections).
- Many existing service permissions have been expanded.
- The overall complexity of the policy has increased substantially.
To ensure the principle of least privilege is maintained:
- Conduct a thorough review of each new permission to validate its necessity for support operations.
- Consider if any existing permissions can be removed or scoped down.
- Evaluate the potential security implications of granting such broad access to the support role.
- Ensure all additions are documented and justified in internal policy documentation.
To assist in this review, please run the following script to generate a summary of the changes:
#!/bin/bash # Description: Summarize changes to AWSSupportServiceRolePolicy echo "Analyzing changes in AWSSupportServiceRolePolicy.json" # Count total number of permissions total_permissions=$(jq '.Statement[0].Action | length' AWSSupportServiceRolePolicy.json) echo "Total number of permissions: $total_permissions" # List unique services echo "Unique services with permissions:" jq -r '.Statement[0].Action[]' AWSSupportServiceRolePolicy.json | cut -d: -f1 | sort | uniq # Count permissions per service echo "Number of permissions per service:" jq -r '.Statement[0].Action[]' AWSSupportServiceRolePolicy.json | cut -d: -f1 | sort | uniq -c | sort -nr echo "Review this summary to get an overview of the policy's scope and complexity."
117-132: Extensive new permissions for Amazon OpenSearch Serverless (aoss) added.The policy now includes a wide range of permissions for the Amazon OpenSearch Serverless service, covering operations like describing collections, policies, and configurations. While these may be necessary for comprehensive support, the broad scope of these permissions warrants a security review.
To ensure these permissions align with the principle of least privilege, please run the following script:
| "Sid": "AllowLicenseManagerActions", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "organizations:DescribeOrganization", | ||
| "license-manager:ListDistributedGrants", | ||
| "license-manager:GetGrant", | ||
| "license-manager:CreateGrantVersion", | ||
| "license-manager:DeleteGrant" | ||
| ], | ||
| "Resource": [ | ||
| "*" | ||
| ] |
There was a problem hiding this comment.
💡 Codebase verification
Review of Policy Permissions
The policy grants permissions for several actions. Based on the current codebase usage:
-
Retain:
"organizations:DescribeOrganization"is actively used in multiple files and should remain to support necessary functionality.
-
Consider Removing or Reviewing:
"license-manager:ListDistributedGrants""license-manager:GetGrant""license-manager:CreateGrantVersion""license-manager:DeleteGrant"
These actions are not referenced in the codebase and may be unnecessarily permissive. Removing them can enhance security by adhering to the principle of least privilege.
🔗 Analysis chain
Review and consider restricting permissions.
The policy grants broad permissions for license management tasks. Consider the following points:
-
The policy allows actions on all resources (
"Resource": ["*"]). It's recommended to restrict permissions to specific resources when possible. -
The inclusion of
organizations:DescribeOrganizationmight not be necessary for license management. Verify if this permission is required for the intended use case. -
Ensure that these broad permissions align with the principle of least privilege.
To help verify the necessity of these permissions, you can run the following command to check for usage of these actions in the codebase:
This will help determine if these permissions are actively used in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for usage of the allowed actions in the codebase
# Expected result: References to these actions in the code, if any
actions=(
"organizations:DescribeOrganization"
"license-manager:ListDistributedGrants"
"license-manager:GetGrant"
"license-manager:CreateGrantVersion"
"license-manager:DeleteGrant"
)
for action in "${actions[@]}"; do
echo "Checking usage of $action:"
rg "$action" --type python --type javascript --type typescript
echo
done
Length of output: 233
Script:
#!/bin/bash
# Description: Check for usage of the allowed actions in the codebase
# Expected result: References to these actions in the code, if any
actions=(
"organizations:DescribeOrganization"
"license-manager:ListDistributedGrants"
"license-manager:GetGrant"
"license-manager:CreateGrantVersion"
"license-manager:DeleteGrant"
)
for action in "${actions[@]}"; do
echo "Checking usage of $action:"
rg "$action" --type py --type js --type ts
echo
done
Length of output: 3592
Updates AWS managed policies
Summary by CodeRabbit
New Features
AWSDirectoryServiceDataFullAccessandAWSDirectoryServiceDataReadOnlyAccess.Bug Fixes
Documentation
Chores