In a Kubernetes ValidatingAdmissionPolicy, what does messageExpression give you that a static message cannot?

## The message is the product A policy decision reaches a developer as one string. Everything the engine knows - which expression fired, which field was wrong, what the acceptable value is - is thrown away unless it is put into that string. A ValidatingAdmissionPolicy gives you two fields for building it, and they differ in one important way: whether the text can see the object. ### message: a fixed sentence `message` is a static string attached to a validation. It must be a single line - line breaks are not allowed in it - and it is the same for every request the validation ever refuses. That is fine for a rule with one possible failure: 'CronJob must be submitted as batch/v1' says everything there is to say. It stops being fine the moment the rule quantifies over a collection. A validation whose expression walks every container, every volume or every rule in a list knows precisely which element failed while it is evaluating, and a static message throws that knowledge away. The developer gets 'one or more containers violate the policy' and then has to find the one. ### messageExpression: text computed from the request `messageExpression` is a CEL expression that must evaluate to a string, evaluated with the same variables available to the validation expression - typically `object` (the incoming object), `oldObject` (its previous state on an update), `request` (the request metadata), and `params` if the policy binds a parameter resource. So the failure text can be built out of the thing being refused: `messageExpression: "'PodDisruptionBudget ' + object.metadata.name + ' must be submitted as policy/v1'"` That single change turns a generic refusal into one a developer can act on without opening the policy. Two mechanical points matter: - **It runs only on failure.** The API server evaluates the message expression when the validation expression has already failed, so the cost is paid only by rejected requests. - **It is expression-only.** CEL here has no I/O: it cannot look up another object, call a service, or read cluster state. The message can only be built from what was already handed to the policy. If the useful context is not in the request, no message expression can conjure it. ### The fallback chain, which you should be able to recite If `messageExpression` produces a runtime error, an empty string, a whitespace-only string, or a string containing line breaks, the API server logs the problem and produces the message **as if messageExpression were unset**. It falls back to the static `message`. If that is also unset, the API server generates a default that quotes the failed expression itself. The consequence is worth stating plainly: **a broken message expression never changes the decision.** The request is still refused; the developer just gets worse text. This is a nice property - text generation cannot accidentally admit something - but it also means a bug here is silent from the outside, and the only place it surfaces is the API server log. The other consequence is the failure mode you see most often in real clusters: a policy shipped with neither field usefully set, so developers are handed a raw CEL expression as their explanation. It is technically accurate and practically useless, and it is the single fastest way to make a guardrail feel hostile. ### Where the same text goes when the rule only warns The message a validation produces is not tied to refusal. If the binding lists `Warn` rather than `Deny` in its `validationActions`, that same computed string is what gets emitted as the warning the client sees. So writing a good message pays off twice: once for the person you are blocking, once for the person you are only telling. The same string is also what lands in the audit annotation when the binding uses `Audit`. ### Contrast with a webhook A validating admission webhook has no equivalent field, and does not need one: it builds the status message in code, with the whole object in hand, and can format it however it likes. `messageExpression` exists because a declarative policy has nowhere else to compute text - the expression language is the only code there is. ### Writing the text itself Aim for one line that answers three questions: which object, which field or value, and what to do instead. Name the rule so a developer knows what to search for and whom to ask. Resist the temptation to format a bulleted list into the string - line breaks disqualify the message and drop you back to the fallback, which is worse than the plain sentence you started with.