Introducing the AdmissionPolicy
Up till now, the only way to define a policy in Kubewarden was to use the
ClusterAdmissionPolicy resource that would be 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 only process 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
Why should you use AdmissionPolicies?
It was possible to restrict the namespaces where a
ClusterAdmissionPolicy evaluated resources using a
namespaceSelector. However there was no way for Kubernetes administrators to restrict users from creating
ClusterAdmissionPolicies that evaluate resources just in a particular namespace.
Moreover, 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.
Which is why, as a Kubernetes administrator, you probably want to allow tenants to deploy policies only in the namespaces they have access to. That’s where
AdmissionPolicies come into play!
AdmissionPolicies combined with Role-Based Access Control (RBAC) in Kubernetes allow you to enforce this restriction by delimiting the tenants to deploy resources only across namespaces they have access to.
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
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:
kubectl create ns development kubectl create ns production
Once the namespaces are created, create a new
AdmissionPolicy resource in the
apiVersion: policies.kubewarden.io/v1alpha2 kind: AdmissionPolicy metadata: name: ns-privileged-pods namespace: production spec: module: registry://ghcr.io/kubewarden/policies/pod-privileged:v0.1.9 rules: - apiGroups: [""] apiVersions: ["v1"] resources: ["pods"] operations: - 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 metadata: name: privileged-pod spec: containers: - name: nginx image: nginx:latest securityContext: privileged: true
Try to create a privileged pod in the
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
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.