fix(apiserver): probe SA permissions before loading admission-policy plugins#1842
Open
neel5481 wants to merge 1 commit into
Open
fix(apiserver): probe SA permissions before loading admission-policy plugins#1842neel5481 wants to merge 1 commit into
neel5481 wants to merge 1 commit into
Conversation
…plugins Fixes carvel-dev#1841 On Kubernetes 1.36+ the MutatingAdmissionPolicy admission plugin ships enabled by default. Its SharedInformer requires list+watch permission on mutatingadmissionpolicies and mutatingadmissionpolicybindings. If the deployed ClusterRole for the kapp-controller ServiceAccount lacks those permissions, the informer's cache never syncs, HasSynced() never returns true, and every mutating admission request into the aggregated apiserver fails permanently with 'not yet ready to handle request (reason: Forbidden)'. The existing serverResourceExists guard only confirms the API resource is present in cluster discovery, which is always true on k8s 1.36+ regardless of RBAC. This change extends the guard with a SelfSubjectAccessReview probe for both list and watch on the policy resource and its bindings resource before loading each admission-policy plugin. When the probe fails the plugin is skipped and an actionable warning is logged naming the missing (resource, verb) pair. The probe uses subjectaccessreviews/create, which is already granted in the shipped ClusterRole, no new RBAC required. Also applied to ValidatingAdmissionPolicy for symmetry; the same failure mode is possible on k8s 1.30+ if RBAC drifts. Signed-off-by: Neel Patel <neel5481@gmail.com>
b8bac11 to
4b45307
Compare
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
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.
Fixes #1841
On Kubernetes 1.36+ the MutatingAdmissionPolicy admission plugin ships enabled by default. Its SharedInformer requires list+watch permission on mutatingadmissionpolicies and mutatingadmissionpolicybindings. If the deployed ClusterRole for the kapp-controller ServiceAccount lacks those permissions, the informer's cache never syncs, HasSynced() never returns true, and every mutating admission request into the aggregated apiserver fails permanently with 'not yet ready to handle request (reason: Forbidden)'.
Signed-off-by: Neel Patel
What this PR does / why we need it:
The existing serverResourceExists guard only confirms the API resource is present in cluster discovery, which is always true on k8s 1.36+ regardless of RBAC. This change extends the guard with a SelfSubjectAccessReview probe for both list and watch on the policy resource and its bindings resource before loading each admission-policy plugin. When the probe fails the plugin is skipped and an actionable warning is logged naming the missing (resource, verb) pair.
The probe uses subjectaccessreviews/create, which is already granted in the shipped ClusterRole, no new RBAC required.
Also applied to ValidatingAdmissionPolicy for symmetry; the same failure mode is possible on k8s 1.30+ if RBAC drifts.
Which issue(s) this PR fixes:
Fixes #1841
Does this PR introduce a user-facing change?
Additional Notes for your reviewer:
Review Checklist:
a link to that PR
change
Additional documentation e.g., Proposal, usage docs, etc.: