Introducing the AdmissionPolicy


Post originally published on Kubewarden’s blog by Raul Cabello Martin

Up until now, the only way to define a policy in Kubewarden was to use a ClusterAdmissionPolicy which is applied to cluster-wide resources across all namespaces.

That’s why we’re thrilled to announce the new AdmissionPolicy resource. This new resource is created inside a namespace and the policies will process only the requests that are targeting the namespace where the AdmissionPolicy is defined. Except from being a “namespaced” resource, AdmissionPolicy works exactly the same as the ClusterAdmissionPolicy.

Why should you use AdmissionPolicies?

It’s possible to restrict the namespaces where a ClusterAdmissionPolicy evaluates resources using a namespaceSelector. However there’s no way for Kubernetes administrators to restrict users from creating ClusterAdmissionPolicies that evaluate resources just in a particular namespace.

Allowing all tenants to deploy ClusterAdmissionPolicies is risky. A tenant could apply policies that affect resources in all namespaces, even if they don’t have access to all of them. You probably want to allow tenants to deploy policies only in the namespaces they have access to. That’s where AdmissionPolicies come into play! We can achieve this restriction with AdmissionPolicies and Role-Based Access Control (RBAC) in Kubernetes.

As an example, let’s say you want a tenant who can deploy resources just to the development namespace. You can allow this tenant to deploy AdmissionPolicies just in this namespace using RBAC. However, if you allowed them to create ClusterAdmissionPolicies, they could block other resources from being handled in other namespaces.

AdmissionPolicy in Action!

Let’s create an AdmissionPolicy that rejects privileged pods from being created in the production namespace. For this example, a Kubernetes cluster with Kubewarden already installed is required. The installation process is described in the quick start guide.

First, create two namespaces: development and production

kubectl create ns development 
kubectl create ns production

Once the namespaces are created, create a new AdmissionPolicy resource in the production namespace:

kind: AdmissionPolicy
  name: ns-privileged-pods
  namespace: production
  module: registry://
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    - CREATE
  mutating: false

Wait for the policy to be active:

kubectl wait --for=condition=PolicyActive admissionpolicies ns-privileged-pods -n production

Create a file named privileged-pod.yaml with the following pod specification:

apiVersion: v1
kind: Pod
  name: privileged-pod
    - name: nginx
      image: nginx:latest
        privileged: true

Try to create a privileged pod in the production namespace:

kubectl apply -f privileged-pod.yaml -n production

You will get the following error:

Error from server: error when creating "privileged-pod.yaml": admission webhook "namespaced-kubewarden-privileged-pods.kubewarden.admission" denied the request: User 'my-user' cannot schedule privileged containers

Finally, verify you can successfully create a privileged pod in a different namespace:

kubectl apply -f privileged-pod.yaml -n development


As evidenced in the above example, Kubewarden provides you with two different choices for deploying policies.

If your policy needs to be applied to resources across all namespaces or cluster-wide resources, then you can use ClusterAdmissionPolicies.

On the other hand, if your cluster is shared by multiple users or teams, uses different namespaces or your policy needs to be applied only to resources within a namespace, then the new AdmissionPolicy would be the right choice.

You can find the AdmissionPolicy specification here.

As a community, we strive on feedback and welcome your suggestions! Feel free to open an issue against our GitHub repository or get in touch on the #kubewarden Slack channel!

(Visited 8 times, 1 visits today)
Avatar photo