匹配条件的文档不能使用命名空间对象或变量
作者: JaydipGabani创建于 2026年9月28日更新于 2026年9月28日
标签kind/documentationsig/api-machineryarea/admission-controlneeds-triage
What happened? The documentation implies that admission policy matchConditions can use every CEL variable that validation expressions can. Two of those variables don't work in match conditions: 1. namespaceObject compiles but is always null. The CEL environment declares namespaceObject for every expression type (compile.go#L256). So a match condition that references it passes API validation. At runtime, however, the shared match condition evaluator always passes a nil namespace (matcher.go#L85). This happens even for ValidatingAdmissionPolicy, where the namespace has already been fetched and is passed to validations (validator.go#L104 vs #L127). - With failurePolicy: Fail, every matching request is rejected with no such key: metadata. - With failurePolicy: Ignore, the policy is silently skipped. 2. variables is rejected when the policy is created. API validation compiles match conditions with a stateless compiler that has no variables declared (validateMatchConditionsExpression). This matches the API field docs for spec.variables ("…except MatchConditions because MatchConditions are evaluated before the rest of the policy"). It contradicts the website docs. Where the docs mislead: - ZZTERM24ZZ.io, ValidatingAdmissionPolicy › Matching requests: matchConditions (source): - Match conditions have access to the same CEL variables as validation expressions. - API reference for MatchCondition.expression (v1/types.go#L1570-L1583): the doc lists the available variables but doesn't say that namespaceObject is unavailable. Users reasonably assume the "Validation" variable list applies, since namespaceObject compiles. This has been the behavior since namespaceObject was introduced in v1.28 (#118267). It affects ValidatingAdmissionPolicy, …
内容来源: kubernetes/kubernetes