OCPBUGS-87107: Scope minted AWS IAM policies to cluster-owned resources #1051
OCPBUGS-87107: Scope minted AWS IAM policies to cluster-owned resources #1051amitesh1201 wants to merge 1 commit into
Conversation
Add an implicit StringEquals condition to every Allow statement in minted IAM user policies, requiring the standard kubernetes.io/cluster infraName tag (with a value of "owned"). This restricts minted credentials to resources tagged as belonging to the cluster, reducing the blast radius if credentials are compromised (CVE-2026-10843). The CVE advisory suggests tightening Resource ARNs from "*" to specific ARNs, but this isn't feasible: CredentialsRequest manifests are authored before cluster infrastructure exists, so resource ARNs for specific clusters are not known when the CR is authored. Not all AWS actions support the aws:ResourceTag condition. Actions that create new resources fail (because the resource doesn't exist yet). Describe and List actions lack resource-level permissions. Some services don't support it at all. However, within the payload, the list is both finite and rarely changed. As such, we can easily classify the entire list into supported/incompatible categories. Unrecognized actions produce an error state, with directions pointing the developer to update the classification list in the CCO. The condition is not applied to Deny statements (this would actually narrow and weaken the policy), nor is it applied to the auto-generated iam:GetUser self-lookup statement, which is already scoped to just the own user's ARN. Co-authored-by: Cursor <cursoragent@cursor.com>
|
@amitesh1201: This pull request references Jira Issue OCPBUGS-87107, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository: openshift/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: amitesh1201 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## release-4.18 #1051 +/- ##
================================================
+ Coverage 46.70% 46.96% +0.26%
================================================
Files 97 97
Lines 11970 12018 +48
================================================
+ Hits 5590 5644 +54
+ Misses 5763 5756 -7
- Partials 617 618 +1
🚀 New features to boost your workflow:
|
|
@amitesh1201: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
xref: OCPBUGS-87107
Backport of #1043 from master to release-4.18 to fix CVE-2026-10843
Add an implicit
StringEqualscondition to everyAllowstatement in minted IAM user policies, requiring the standardkubernetes.io/clusterinfraNametag (with a value of"owned"). This restricts minted credentials to resources tagged as belonging to the cluster, reducing the blast radius if credentials are compromised (CVE-2026-10843).The CVE advisory suggests tightening
ResourceARNs from "*" to specific ARNs, but this isn't feasible:CredentialsRequestmanifests are authored before cluster infrastructure exists, so resource ARNs for specific clusters are not known when the CR is authored.Not all AWS actions support the
aws:ResourceTagcondition. Actions that create new resources fail (because the resource doesn't exist yet). Describe and List actions lack resource-level permissions. Some services don't support it at all. However, within the payload, the list is both finite and rarely changed. As such, we can easily classify the entire list into supported/incompatible categories. Unrecognized actions produce an error state, with directions pointing the developer to update the classification list in the CCO.The condition is not applied to
Denystatements (this would actually narrow and weaken the policy), nor is it applied to the auto-generatediam:GetUserself-lookup statement, which is already scoped to just the own user's ARN.Backport Notes
pkg/aws/actuator/actuator.go(line 913) — SDK v1 vs v2 type mismatch intagUser: resolved by keepingaws-sdk-gov1 types (*iam.Tag,aws.String()) with the newccaws.InfraResourceTagValueconstantpkg/aws/actuator/actuator_test.go(line 21) — import conflict: added"encoding/json"(needed by new tests), removed"errors"(unused on this branch)go test ./pkg/aws/...hack/verify-action-maps.shadjusted to 4.18.0 nightly stream