Updates AWS managed policies #1806
Conversation
WalkthroughUpdates to four AWS managed policy JSON files to include new IAM actions. Changes add SSM OpenDataChannel access to CodeBuild policy, EC2 LockSnapshot capability to EBS CSI driver policy, multiple read-only actions across AWS services to ReadOnlyAccess policy, and X-Ray read-only actions to ViewOnlyAccess policy. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@docs/source/_static/managed-policies/AmazonEBSCSIDriverPolicy.json`:
- Around line 171-172: The policy currently includes ec2:LockSnapshot (alongside
ec2:DeleteSnapshot) but lacks the related snapshot-lock actions; update
AmazonEBSCSIDriverPolicy.json to either remove ec2:LockSnapshot if snapshot
locking is not intended, or add the full set of lock-management
permissions—ec2:LockSnapshot, ec2:UnlockSnapshot, and
ec2:DescribeLockedSnapshots—so that any automation managing locks has the
necessary permissions; additionally, add a brief comment/documentation next to
the action list clarifying whether snapshot lock management is expected to be
handled by the CSI driver or external automation to avoid over-provisioning.
In `@docs/source/_static/managed-policies/AWSCodeBuildDeveloperAccess.json`:
- Around line 48-55: The IAM statement with Sid "SSMOpenDataChannelAccess" uses
Action "ssmmessages:OpenDataChannel" but sets Resource to
"arn:aws:ssm:*:*:session/*", which is invalid; update the statement referenced
by Sid "SSMOpenDataChannelAccess" so that the Resource value is "*" (i.e., set
Resource to "*" for the "ssmmessages:OpenDataChannel" action) to comply with the
AWS Service Authorization Reference.
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
docs/source/_static/managed-policies/AWSCodeBuildDeveloperAccess.jsondocs/source/_static/managed-policies/AmazonEBSCSIDriverPolicy.jsondocs/source/_static/managed-policies/ReadOnlyAccess.jsondocs/source/_static/managed-policies/ViewOnlyAccess.json
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Test cdk-iam-floyd
- GitHub Check: Automerge CI
🔇 Additional comments (3)
docs/source/_static/managed-policies/ViewOnlyAccess.json (1)
342-349: Confirm X-Ray additions match the latest ViewOnlyAccess policy.
Please verify these new X-Ray read actions align with the current AWS ViewOnlyAccess managed policy (default version v28, edited Jan 8, 2026). (docs.aws.amazon.com)docs/source/_static/managed-policies/ReadOnlyAccess.json (2)
86-95: Verify ReadOnlyAccess sync for the new/changed actions.
The AWS-managed ReadOnlyAccess policy’s default version is v138 (edited Jan 8, 2026). Please confirm the new API Gateway, arc-region-switch, Cost Explorer, DSQL, Network Firewall, and Service Quotas actions align with the upstream JSON so this file stays in sync. (docs.aws.amazon.com)Also applies to: 222-222, 426-427, 887-888, 1858-1874, 2382-2382
2564-2569: Confirm AWS Transform custom action names.
The service authorization reference for AWS Transform custom liststransform-customactions includingGetCampaign,GetKnowledgeItem,ListKnowledgeItems,ListTagsForResource, andListTransformationPackageMetadata; please confirm these additions align with that list (and optional resource scoping, if desired). (docs.aws.amazon.com)
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| "ec2:DeleteSnapshot", | ||
| "ec2:LockSnapshot" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n docs/source/_static/managed-policies/AmazonEBSCSIDriverPolicy.json | sed -n '165,190p'Repository: udondan/iam-floyd
Length of output: 178
🌐 Web query:
AWS EBS CSI driver snapshot lock permissions UnlockSnapshot DescribeLockedSnapshots
💡 Result:
Short answer
- The EBS snapshot-lock APIs require these IAM actions: ec2:LockSnapshot, ec2:UnlockSnapshot, and ec2:DescribeLockedSnapshots. Add them to whatever role the EBS CSI driver (or users/scripts) uses when you want the driver to read/modify snapshot locks. [1][2]
Minimal example IAM policy to allow listing and unlocking a specific snapshot (adjust Resource ARNs and conditions as needed):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeLockedSnapshots",
"ec2:UnlockSnapshot",
"ec2:DescribeSnapshots"
],
"Resource": "*"
}
]
}
Notes
- For console use you may also want ec2:DescribeSnapshots. Use condition keys (ec2:SnapshotLockDuration, ec2:CoolOffPeriod) to restrict lock behavior if required. [1]
Sources
- AWS docs — Control access to Amazon EBS snapshot lock. [1]
- AWS docs — Amazon EBS snapshot lock overview. [2]
🌐 Web query:
AWS snapshot lock IAM permissions ec2:LockSnapshot ec2:UnlockSnapshot ec2:DescribeLockedSnapshots requirements
💡 Result:
Summary — required IAM actions and related condition keys
-
Required actions to manage EBS snapshot locks:
- ec2:LockSnapshot — lock or modify a snapshot lock. [1]
- ec2:UnlockSnapshot — unlock a snapshot when allowed (governance or compliance during cooling-off). [1][3]
- ec2:DescribeLockedSnapshots — view snapshot lock status and metadata. [1][2]
-
Notes / common requirements:
- Console users typically also need ec2:DescribeSnapshots to see snapshots in the console. [1]
- Use condition keys to constrain lock parameters:
- ec2:SnapshotLockDuration — restrict allowed lock duration. [1]
- ec2:CoolOffPeriod — restrict allowed cooling-off period for compliance mode. [1]
- Lock behavior differences (governance vs compliance) affect whether UnlockSnapshot is permitted (compliance locks cannot be unlocked after cooling-off expires). [2][3]
Sources:
[1] AWS Docs — Control access to Amazon EBS snapshot lock (IAM).
[2] AWS CLI / DescribeLockedSnapshots reference.
[3] AWS API — UnlockSnapshot / LockSnapshot documentation.
🌐 Web query:
AWS EBS CSI driver snapshot lock functionality capabilities what it does
💡 Result:
Summary — what AWS EBS Snapshot Lock (used by EBS/C SI snapshots) does and its capabilities:
- Purpose: prevents deletion or modification of EBS snapshots for a specified period to meet retention, compliance, and WORM-like requirements. [1][2]
- Two lock modes:
- Governance — prevents deletion by most users but users with specific IAM permissions can modify/unlock or change duration immediately. No mandatory cooling-off. [2][4]
- Compliance — stronger protection: after the cooling-off period (up to 72 hours) the lock and its duration cannot be shortened or removed; only extensions allowed (and root/IAM cannot bypass). Deleting before expiry is effectively impossible except by closing the AWS account. [2][4][8]
- Lock duration: fixed duration or until a specific date (from 1 day up to many years). Duration starts when snapshot is completed if locked while pending. [2][4][9]
- Cooling-off period: optional (1–72 hours) when placing a snapshot into compliance mode; during cooling-off some changes are still possible. [4]
- Actions allowed on locked snapshots: can still be used, copied, shared, archived, associated with AMIs, and restored; normal snapshot read/restore workflows continue. [1][2][9]
- IAM control: APIs and permissions — ec2:LockSnapshot, ec2:UnlockSnapshot, ec2:DescribeLockedSnapshots; you can restrict who may manage locks via IAM. [5]
- APIs/CLI/console: LockSnapshot, UnlockSnapshot, DescribeLockedSnapshots; available across commercial regions and via console/CLI/SDK. [2][3]
- Interaction with Kubernetes/EBS CSI snapshots: snapshot lock is an EBS service capability applied to EBS snapshots. To use Kubernetes CSI snapshotting you must use the EBS CSI driver + CSI snapshot controller; locks apply to the resulting EBS snapshots but are managed via EBS APIs (not the CSI API). Ensure snapshots are created by the CSI driver (provisioner ebs.csi.aws.com) to be eligible. [3][6]
Key caveats:
- AWS Backup-managed snapshots: don't generally recommend locking those (use Backup Vault Lock instead). [2]
- A compliance-locked snapshot can only be deleted early by closing the AWS account (subject to account closure behavior). [9]
Sources:
- AWS announcement / blog and EBS docs on Snapshot Lock. [1] [2] [4] [5] [8] [9]
🌐 Web query:
Amazon EBS CSI driver snapshot locking create backup lock unlock snapshots
💡 Result:
Short answer
- Snapshot Lock is an EBS feature (LockSnapshot / UnlockSnapshot / DescribeLockedSnapshots) that prevents snapshot deletion (governance or compliance modes). Manage locks via AWS APIs/CLI/console — the EBS CSI driver does not automatically lock/unlock snapshots. [1][2][3]
Key details and implications for the EBS CSI driver
- The CSI driver (and CSI snapshot controller) creates snapshots/backups using the EC2 snapshot APIs; locking is a separate EC2 API call (LockSnapshot). If you want snapshots created by the driver to be locked, you must call LockSnapshot after creation (or run an automation that does so). The driver itself doesn’t perform LockSnapshot/UnlockSnapshot by default. [5][1]
- You can only lock snapshots in allowed states (docs note restrictions such as pending/completed and also say you can’t lock “during creation” / during AMI registration — follow the Considerations doc when automating). If you lock while pending and creation fails, the lock is canceled. [2]
- Unlocking is allowed only for governance-mode locks (or compliance-mode within the cooling-off period); compliance-mode after the cooling-off period is effectively irreversible until expiry. Don’t rely on unlocking to bypass compliance-mode locks. [3][2]
Permissions and automation
- If you automate locking/unlocking, grant the IAM actions ec2:LockSnapshot, ec2:UnlockSnapshot, ec2:DescribeLockedSnapshots (and the usual snapshot creation permissions). The EBS CSI Driver’s managed policy may need updates if you automate snapshot restores/creates—see recent IAM policy notes for the driver. [4][1]
Practical recommendations
- Create snapshot (via CSI driver), wait for snapshot to reach completed state, then call LockSnapshot (or run Lambda/Step Function/job to do this). Verify lock state with DescribeLockedSnapshots before assuming protections. Use governance mode if you need reversible locks; use compliance mode only when irreversible retention is required. [2][3][5]
References
[1] Amazon EBS snapshot lock (overview & APIs).
[2] Considerations for Amazon EBS snapshot lock (states, pending/completed, cooling-off).
[3] Unlock an Amazon EBS snapshot (when unlock is allowed).
[4] aws-ebs-csi-driver GitHub — IAM policy updates / driver-related notes.
[5] EKS / CSI snapshot controller and EBS CSI driver snapshot usage.
Clarify snapshot lock permission scope.
AWS snapshot lock management requires three IAM actions: ec2:LockSnapshot, ec2:UnlockSnapshot, and ec2:DescribeLockedSnapshots. The EBS CSI driver does not automatically lock or unlock snapshots; locking is a separate operation performed via external automation after snapshot creation. If the CSI driver or dependent automation needs to manage locks, include all three actions. If ec2:LockSnapshot was added for a different purpose, clarify the intent or remove it to avoid over-provisioning permissions.
Also applies to: 184-185
🤖 Prompt for AI Agents
In `@docs/source/_static/managed-policies/AmazonEBSCSIDriverPolicy.json` around
lines 171 - 172, The policy currently includes ec2:LockSnapshot (alongside
ec2:DeleteSnapshot) but lacks the related snapshot-lock actions; update
AmazonEBSCSIDriverPolicy.json to either remove ec2:LockSnapshot if snapshot
locking is not intended, or add the full set of lock-management
permissions—ec2:LockSnapshot, ec2:UnlockSnapshot, and
ec2:DescribeLockedSnapshots—so that any automation managing locks has the
necessary permissions; additionally, add a brief comment/documentation next to
the action list clarifying whether snapshot lock management is expected to be
handled by the CSI driver or external automation to avoid over-provisioning.
| { | ||
| "Sid": "SSMOpenDataChannelAccess", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ssmmessages:OpenDataChannel" | ||
| ], | ||
| "Resource": "arn:aws:ssm:*:*:session/*" | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
ssmmessages OpenDataChannel resource ARN AWS service authorization reference
💡 Result:
Short answer
- The AWS Service Authorization Reference for the Amazon Message Gateway Service (service prefix: ssmmessages) states you cannot scope ssmmessages resources by ARN and must use "Resource": "*" for its actions (including OpenDataChannel). [1]
- However, some AWS managed policies (e.g., AmazonSSMAutomationRole) include ssmmessages:OpenDataChannel with a resource pattern like arn::ssm:::session/; that appears in managed-policy JSON but the Service Authorization Reference is the authoritative guidance for writing IAM policy statements. [2]
Recommendation
- When creating IAM policies, follow the Service Authorization Reference and use "Resource": "" for ssmmessages:OpenDataChannel. If you see managed policies that list arn::ssm:::session/*, treat those as AWS-managed artifacts; do not assume you can always restrict ssmmessages by ARN in custom policies. [1][2]
Sources
- AWS Service Authorization Reference — Amazon Message Gateway Service (ssmmessages). [1]
- AmazonSSMAutomationRole managed policy (shows ssmmessages:OpenDataChannel with arn::ssm:::session/). [2]
🏁 Script executed:
# Check the current file and context around the lines mentioned
cat -n docs/source/_static/managed-policies/AWSCodeBuildDeveloperAccess.json | sed -n '40,60p'Repository: udondan/iam-floyd
Length of output: 715
🏁 Script executed:
# Search for other occurrences of ssmmessages in the codebase
rg "ssmmessages" --type jsonRepository: udondan/iam-floyd
Length of output: 6335
🏁 Script executed:
# Check what resource patterns are used with ssmmessages:OpenDataChannel across the codebase
rg -A2 'ssmmessages:OpenDataChannel' docs/source/_static/managed-policies/ | grep -E '(ssmmessages:OpenDataChannel|Resource)'Repository: udondan/iam-floyd
Length of output: 3743
🏁 Script executed:
# Let's look at a few specific files to see the patterns used
for file in docs/source/_static/managed-policies/AmazonSSMAutomationRole.json docs/source/_static/managed-policies/AmazonSSMFullAccess.json docs/source/_static/managed-policies/AmazonEC2RoleforSSM.json; do
echo "=== $file ==="
rg -B2 -A2 'ssmmessages:OpenDataChannel' "$file" | head -15
doneRepository: udondan/iam-floyd
Length of output: 688
Use "Resource": "*" for ssmmessages:OpenDataChannel.
The AWS Service Authorization Reference for the Amazon Message Gateway Service indicates that ssmmessages:OpenDataChannel does not support resource-level ARNs and requires "Resource": "*". The current resource pattern "arn:aws:ssm:*:*:session/*" is invalid for this action and will fail to grant access.
✅ Proposed fix
{
"Sid": "SSMOpenDataChannelAccess",
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
- "Resource": "arn:aws:ssm:*:*:session/*"
+ "Resource": "*"
},📝 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": "SSMOpenDataChannelAccess", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ssmmessages:OpenDataChannel" | |
| ], | |
| "Resource": "arn:aws:ssm:*:*:session/*" | |
| }, | |
| { | |
| "Sid": "SSMOpenDataChannelAccess", | |
| "Effect": "Allow", | |
| "Action": [ | |
| "ssmmessages:OpenDataChannel" | |
| ], | |
| "Resource": "*" | |
| }, |
🤖 Prompt for AI Agents
In `@docs/source/_static/managed-policies/AWSCodeBuildDeveloperAccess.json` around
lines 48 - 55, The IAM statement with Sid "SSMOpenDataChannelAccess" uses Action
"ssmmessages:OpenDataChannel" but sets Resource to "arn:aws:ssm:*:*:session/*",
which is invalid; update the statement referenced by Sid
"SSMOpenDataChannelAccess" so that the Resource value is "*" (i.e., set Resource
to "*" for the "ssmmessages:OpenDataChannel" action) to comply with the AWS
Service Authorization Reference.
Updates AWS managed policies
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.