DevSecOps · April 14, 2023 0

Admission controllers and kyverno policies

What's an admission controller?
First of all, do you know what happens when you create a pod via Kubectl? Let's do that -
So when you create a pod, the API request goes to authentication and authorization. Then the pod object is checked against various admission controls before persisting to the etcd database. As per kubernetes.io document, "An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object".
Also, there are existing admission plugins in Kubernetes Admission Controllers Reference which can be enabled via the --enable-admission-plugins= flag inside kube-apiserver.
Common use cases-
  • Limit requests to create, delete, modify, and other specific operations
  • Allows enforcing granular rules
  • Highly effective in hardening Kubernetes clusters
OPA(Open Policy Agent) and Kyverno can be used as third-party Kubernetes plugins for the admission controller.
 
I use Kyverno extensively. I am going to show a few security use cases, where Kyverno was extremely helpful. I am not going to cover how Kyverno works, it is already well-documented here. Installation doc. You can install Kyverno using a stable yaml file or via helm chart. It installs a bunch of CRDs, creates Validating and mutating webhook, and creates a few roles to perform actions.
 
   1. Disable automount service Token

A new ServiceAccount called 'default' is created whenever a new Namespace is created. Pods spawned in that Namespace, by default will be mounting this ServiceAccountToken. With this service token, you can communicate with kube-Apiserver. 

According to security best practices it is recommended to disable mounting the ServiceAccountToken. There are 2 ways to do it. By attaching automountServiceAccountToken: false to the ServiceAccount itself or in the POD spec itself. Configure service account for pods.

Kyverno policy to implement disable service account token mount- here. Now due to the mutation-based webhook whenever a new namespace is created, it will automatically add automountServiceAccountToken: false. 

Now tokens are not mounted automatically.

    2. Only allow images to be pulled from the organization registry

Allowing images from other or public registry introduce the risk of having a backdoor image in Kubernetes infra. Usually, organization registry images are scanned periodically & most org have golden images. So we will use a policy that denies images from other registries than the org registry. policy. As of now, the policy is configured in audit mode which will only show a warning. You can put in "enforce"  mode to completely block, but before doing that make sure all the images including master component images are in your org registry.

As you can see it is showing error “ validation error : Unknown Image registry”.

3. Mutate the registry to our private registry.

"Security engineering should be a business enabler not a blocker for different teams". Let's create a policy if anyone mistakenly pulls images from the public registry, mutating webhook automatically changes to our private registry. policy.

Magic !! you can see the registry automatically changed to myregistry.corp.com .

Spread the love