aws: Restrict KMS permissions to service-mediated calls - #18671
Merged
kubernetes-prow[bot] merged 4 commits intoAug 8, 2026
Merged
Conversation
Member
Author
|
/retest |
Member
Author
|
/test pull-kops-scenario-aws-karpenter |
All supported flows that need KMS grants on customer managed keys (etcd volumes, EBS CSI volumes, Karpenter root volumes) have EC2 create the grant on the role's behalf, so kms:CreateGrant can be guarded with the kms:GrantIsForAWSResource condition key instead of being unconditional. This prevents a compromised role from delegating itself access to unrelated keys whose key policies defer authorization to account IAM. kms:DescribeKey is likewise only called through EC2 or S3 in these flows, so it joins the data-plane actions guarded by kms:ViaService, falling back to unconditional only for the EncryptionConfig kms-plugin path where KMS is called directly.
hakman
force-pushed
the
kms-scoped-permissions
branch
from
August 8, 2026 12:51
6c1cd05 to
ca9483f
Compare
Member
Author
|
/test pull-kops-scenario-aws-karpenter |
rifelpet
approved these changes
Aug 8, 2026
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rifelpet The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Member
Author
|
/test pull-kops-e2e-cni-cilium |
Member
Author
|
/retest |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Roles that use customer managed KMS keys (etcd volumes, EBS CSI volumes, Karpenter root volumes, state store SSE-KMS) previously received
kms:CreateGrantandkms:DescribeKeyunconditionally onResource: "*". A compromised role could useCreateGrantto authorize itself on any key in the account whose key policy defers to IAM.In all supported flows an AWS service makes the KMS calls on the role's behalf, so
kms:CreateGrantis now allowed only for grants created by an AWS service (kms:GrantIsForAWSResource), andkms:DescribeKeyjoins the data-plane actions restricted to calls made through EC2 and S3 (kms:ViaService). With EncryptionConfig, control-plane roles keep unconditional data actions for kms-plugins, which do not create grants.The comment claiming the EBS CSI driver calls
CreateGrantdirectly was outdated: neither aws-ebs-csi-driver v1.58.0 nor karpenter-provider-aws v1.13.0 makes any direct KMS calls. Workloads that do needspec.additionalPoliciesor a service account IAM role; a release note documents this. The policy tests now compare complete rendered statements instead of only action presence./cc @rifelpet @ameukam