No. The Kubernetes docs say admission webhooks are not called for non persisted virtual authentication and authorization resources such as TokenReviews and SubjectAccessReviews, and that interception of these is deprecated as of v1.37. A feature gate can restore the old behavior temporarily.
Which resources are affected
The docs list TokenReviews, SelfSubjectReviews, LocalSubjectAccessReviews, SelfSubjectAccessReviews, SelfSubjectRulesReviews and SubjectAccessReviews. These are virtual: they are requests to ask a question, and nothing is stored.
Why the rule exists
The docs explain that a failing webhook which matches subjectaccessreviews can block the authorization checks the cluster itself depends on. In other words, a broken policy webhook could lock the control plane out of deciding anything.
If a webhook rule names one of these resources explicitly, the API server returns a warning that the rule has no effect. Rules that reach them only through a wildcard are not flagged.
What to check in your cluster
| Check | Why |
|---|---|
| Search webhook rules for the review resources | A rule that names them has no effect |
| Look for wildcard rules on everything | They may have matched these resources before |
| Read the ExcludeAdmissionWebhookVirtualResources gate on your version | The docs name it as a temporary switch |
| Check your upgrade notes | The behavior is tied to a specific release |
Steps
- Export all validating and mutating webhook configurations.
- Search for the six resource names and for wildcards on resources.
- For each hit, decide whether the webhook was doing something you rely on. Auditing authorization checks through a webhook is the likely case.
- Move that need elsewhere, such as the audit log or the authorizer configuration, rather than switching the gate back on.
- Test in a non production cluster on the target version before upgrading.
The wider lesson
Admission is powerful and also bounded. Policies written as wildcards can behave differently across releases. Keep policy rules explicit, and test them after every Kubernetes upgrade. See Kubernetes API request path: authn, authz and admission for where admission sits.
How this fits a policy review
Many teams write a catch all webhook rule, with a star for the group, version and resource, because it feels safest. The page's own wording shows why that is fragile: rules that match these resources only through a wildcard are not flagged with a warning. So a wildcard rule can behave differently from one release to the next without any message telling you so.
Write rules as lists of the resources you mean. Review them whenever you review a Kubernetes upgrade. If you want a record of who asked the cluster what, the audit log is the better place for it than an admission webhook. See Kubernetes audit logging policy starter.
Quick check
Does this affect ordinary pods and deployments?
No. The change concerns virtual authentication and authorization review resources only.
Is the feature gate a long term fix?
The docs describe it as a temporary way to restore the previous behavior.
Safeguard policies and gates enforce rules in your pipeline, where behavior does not depend on cluster API versions.
Sources
Last reviewed: 19 October 2026.
