address comments and monitoring section.

Author: jiahuif

content/en/blog/_posts/2024-04-01-validating-admission-policy-ga/index.md renamed to content/en/blog/_posts/2024-04-24-validating-admission-policy-ga/index.md

@@ -2,21 +2,21 @@
 layout: blog
 title: "Kubernetes 1.30: Validating Admission Policy Is Generally Available"
 slug: validating-admission-policy-ga
-date: 2024-04-01
-canonicalUrl: https://www.k8s.dev/blog/2024/04/01/validating-admission-policy/
+date: 2024-04-24
 ---
 
 **Author:** Jiahui Feng (Google)
 
-We are excited to announce that Validating Admission Policy has reached its General Availability
+On behalf of the Kubernetes project, I am excited to announce that ValidatingAdmissionPolicy has reached
+**general availability**
 as part of Kubernetes 1.30 release. If you have not yet read about this new declarative alternative to
 validating admission webhooks, it may be interesting to read our
 [previous post](/blog/2022/12/20/validating-admission-policies-alpha/) about the new feature.
 If you have already heard about Validating Admission Policy and you are eager to try it out, there is no better time to do it now.
 
 Let's have a taste of Validating Admission Policy by replacing a simple webhook. 
 
-# The Webhook
+## Example admission webhook
 First, let's take a look at an example of a simple webhook. Here is an excerpt from a webhook that
 enforce `runAsNonRoot`, `readOnlyRootFilesystem`, `allowPrivilegeEscalation`, and `privileged` to be set to the least permissive values.
 
@@ -47,10 +47,9 @@ func verifyDeployment(deploy *appsv1.Deployment) error {
 }
 ```
 
-Check out [the doc](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
-for a refresher on how admission webhooks work. Or, see the [full code](https://gist.github.com/jiahuif/2653f2ce41fe6a2e5739ea7cd76b182b) of this webhook to follow along this walkthrough. 
+Check out [What are admission webhooks?](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) Or, see the [full code](https://gist.github.com/jiahuif/2653f2ce41fe6a2e5739ea7cd76b182b) of this webhook to follow along this walkthrough. 
 
-# The Policy
+## The policy
 Now let's try to recreate the validation faithfully with a ValidatingAdmissionPolicy.
 ```yaml
 apiVersion: admissionregistration.k8s.io/v1
@@ -127,8 +126,9 @@ Next, let's create a namespace for our tests.
 ```shell
 kubectl create namespace policy-test
 ```
-Then, bind the policy to the namespace. But at this point, we set the action to `Warn` 
-so that the policy prints out warnings instead of rejecting the requests.
+Then, I bind the policy to the namespace. But at this point, I set the action to `Warn`
+so that the policy prints out [warnings](/blog/2020/09/03/warnings/) instead of rejecting the requests.
+This is especially useful to collect results from all expressions during development and automated testing.
 ```yaml
 apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingAdmissionPolicyBinding
@@ -178,12 +178,12 @@ Error from server: error when creating "STDIN": admission webhook "webhook.examp
 Looks great! The policy and the webhook give equivalent results.
 After a few other cases, when we are confident with our policy, maybe it is time to do some cleanup.
 
-- For every expression, we repeat access to `object.spec.template.spec.containers` and each `securityContext` in every expression;
+- For every expression, we repeat access to `object.spec.template.spec.containers` and to each `securityContext`;
 - There is a pattern of checking presence of a field and then accessing it, which looks a bit verbose.
 
-Fortunately, with the release of Kubernetes 1.28, we have new solutions for both issues.
+Fortunately, since Kubernetes 1.28, we have new solutions for both issues.
 Variable Composition allows us to extract repeated sub-expressions into their own variables.
-CEL library has also added support for [optionals](https://github.com/google/cel-spec/wiki/proposal-246), which are excellent to work with fields that are, well, optional. 
+Kubernetes enables [the optional library](https://github.com/google/cel-spec/wiki/proposal-246) for CEL, which are excellent to work with fields that are, you guessed it, optional. 
 
 With both features in mind, let's refactor the policy a bit.
 ```yaml
@@ -213,4 +213,71 @@ spec:
     message: 'all containers must NOT set allowPrivilegeEscalation to true'
   - expression: variables.securityContexts.all(c, c.?privileged != optional.of(true))
     message: 'all containers must NOT set privileged to true'
-```
+```
+The policy is now much cleaner and more readable. Update the policy, and you should see
+it function the same as before.
+
+Now let's change the policy binding from warning to actually denying requests that fail validation.
+```yaml
+apiVersion: admissionregistration.k8s.io/v1
+kind: ValidatingAdmissionPolicyBinding
+metadata:
+  name: "pod-security.policy-binding.example.com"
+spec:
+  policyName: "pod-security.policy.example.com"
+  validationActions: ["Deny"]
+  matchResources:
+    namespaceSelector:
+      matchLabels:
+        "kubernetes.io/metadata.name": "policy-test"
+```
+And finally, remove the webhook. Now the result should include only messages from 
+the policy.
+```shell
+kubectl create -n policy-test -f- <<EOF
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app: nginx
+  name: nginx
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: nginx
+        name: nginx
+        securityContext:
+          privileged: true
+          allowPrivilegeEscalation: true
+EOF
+```
+```text
+The deployments "nginx" is invalid: : ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com' denied request: all containers must set runAsNonRoot to true
+```
+Please notice that, by design, the policy will stop evaluation after the first expression that causes the request to be denied.
+This is different from what happens when the expressions generate only warnings.
+
+## Set up monitoring
+Unlike a webhook, a policy is not a dedicated process that can expose its own metrics.
+Instead, you can use metrics from the API server in their place.
+
+Here are some examples in Prometheus Query Language of common monitoring tasks.
+
+To find the 95th percentile execution duration of the policy shown above. 
+```text
+histogram_quantile(0.95, sum(rate(apiserver_validating_admission_policy_check_duration_seconds_bucket{policy="pod-security.policy.example.com"}[5m])) by (le)) 
+```
+
+To find the rate of the policy evaluation.
+```text
+rate(apiserver_validating_admission_policy_check_total{policy="pod-security.policy.example.com"}[5m])
+```
+
+You can read [the metrics reference](/docs/reference/instrumentation/metrics/) to learn more about the metrics above.