diff --git a/content/en/blog/_posts/2022-11-29-validating-admission-policies-alpha/index.md b/content/en/blog/_posts/2022-11-29-validating-admission-policies-alpha/index.md
new file mode 100644
index 0000000000000..793e2e2ae400a
--- /dev/null
+++ b/content/en/blog/_posts/2022-11-29-validating-admission-policies-alpha/index.md
@@ -0,0 +1,150 @@
+---
+layout: blog
+title: "Kubernetes 1.26: Introducing Validating Admission Policies"
+date: 2022-11-29
+slug: validating-admission-policies-alpha
+---
+
+**Authors:** Joe Betz (Google), Cici Huang (Google)
+
+In Kubernetes 1.26, the 1st alpha release of validating admission policies is
+available!
+
+Validating admission policies use the [Common Expression
+Language](https://github.com/google/cel-spec) (CEL) to offer a declarative,
+in-process alternative to validating admission webhooks.
+
+CEL was first introduced to Kubernetes for the [Validation rules for
+CustomResourceDefinitions](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules)
+enhancement. This enhancement expands the use of CEL in Kubernetes to support a
+far wider range of admission use cases.
+
+Admission webhooks are burdonsome to develop. Each webhook requires the
+development and maintenance of a binary to handle webhook requests. Also,
+admission webhooks are complex to operate. Each webhook must be deployed,
+monitored and have a well defined upgrade and rollback plan. To make matters
+worse, if a webhook times out or is unavailable, the Kubernetes control plan can
+become unavailable. This enhancement eliminates much of this complexity of
+admission webhooks by embedding logic into the Kubernetes resources using CEL
+instead of calling out to a remote webhook binary.
+
+For example, to set a limit on deployment replicas, declare a policy:
+
+```yaml
+apiVersion: admissionregistration.k8s.io/v1alpha1
+kind: ValidatingAdmissionPolicy
+metadata:
+  name: "demo-policy.example.com"
+spec:
+  matchConstraints:
+    resourceRules:
+    - apiGroups:   ["apps"]
+      apiVersions: ["v1"]
+      operations:  ["CREATE", "UPDATE"]
+      resources:   ["deployments"]
+  validations:
+    - expression: "object.spec.replicas <= 5"
+```
+
+Note that the `expression` field contains a CEL expression that will be
+evaluated by all resources matching the `matchConstraints`.
+
+Next bind the policy the the appropriate resources:
+
+```yaml
+apiVersion: admissionregistration.k8s.io/v1alpha1
+kind: ValidatingAdmissionPolicyBinding
+metadata:
+  name: "demo-binding-test.example.com"
+spec:
+  policy: "replicalimit-policy.example.com"
+  matchResources:
+    namespaceSelectors:
+    - key: environment,
+      operator: In,
+      values: ["test"]
+```
+
+This `ValidatingAdmissionPolicyBinding` resource binds the policy we just
+defined only to for namespaces where the `environment` label is set to `test`.
+
+Compared to an admission webhook, admission policies are far simpler. The entire
+policy is declared in Kubernetes resources. Unlike webhooks, there are no
+external binaries or remote requests involved.
+
+Validation admission policies are highly configurable, enabling policy authors
+to define policies that can be parameterized and scoped to resources as needed
+by cluster administrators.
+
+For example, the above admission policy can be modified to make it configurable:
+
+```yaml
+apiVersion: admissionregistration.k8s.io/v1alpha1
+kind: ValidatingAdmissionPolicy
+metadata:
+  name: "replicalimit-policy.example.com"
+Spec:
+  paramKind:
+    apiVersion: rules.example.com/v1
+    kind: ReplicaLimit
+  matchConstraints:
+    resourceRules:
+    - apiGroups:   ["apps"]
+      apiVersions: ["v1"]
+      operations:  ["CREATE", "UPDATE"]
+      resources:   ["deployments"]
+  validations:
+    - expression: "object.spec.replicas <= params.maxReplicas"
+```
+
+Here, `paramKind` defines the resources used to configure the policy and the
+`expression` uses the `params` variable to access the parameter resource.
+
+This allows multiple bindings to be defined, each configured differently. For
+example:
+
+```yaml
+apiVersion: admissionregistration.k8s.io/v1alpha1
+kind: ValidatingAdmissionPolicyBinding
+metadata:
+  name: "replicalimit-binding-production.example.com"
+spec:
+  policy: "replicalimit-policy.example.com"
+  paramsRef:
+    name: "replica-limit-production.example.com"
+  matchResources:
+    namespaceSelectors:
+    - key: environment,
+      operator: In,
+      values: ["production"]
+```
+
+```yaml
+apiVersion: rules.example.com/v1
+kind: ReplicaLimit
+metadata:
+  name: "replica-limit-production.example.com"
+maxReplicas: 1000
+```
+
+This binding and parameter resource configure deployments in namespaces with the
+`environment` label set to `production` to a max limit of 1000 replicas.
+
+A seperate binding can then be configured to set a lower limit for `test`
+namespaces.
+
+I hope this has given you a glimpse of what is possible with validating
+admission policies! There are many features that we have not yet touched on.
+Have a look at the [feature
+documentation](content/en/docs/reference/access-authn-authz/validating-admission-policy.md)
+to learn more.
+
+We are working hard to add more features to admission policies and make the
+enhancement easier to use. Try it out, send us your feedback and help us build
+a simpler alternative to admission webhooks!
+
+## How do I get involved?
+
+If you want to get involved in development of admission policies, discuss enhancement
+roadmaps, or report a bug, you can get in touch with developers at
+[SIG-API-Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
\ No newline at end of file