Admission Controllers in Kubernetes

Admission Controllers and Restrict Operations in Kubernetes

Admission controllers and restrictions are an important part of securing a Kubernetes cluster. In this blog post, we’ll give an overview of what admission controllers are, what restrictions are available, and how to configure them. We’ll also discuss the benefits of using admission controllers and some strategies for restricting operations in Kubernetes.

Overview of Admission Controllers and Restrictions in Kubernetes.

In Kubernetes, an admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object. Admission controllers can deny or approve an operation for a number of reasons. For example, an admission controller might deny a request based on insufficient privileges or it might approve a request but add some default values for fields that were not specified in the original request.

There are two types of admission controllers:

1) ValidatingAdmissionWebhook

2) MutatingAdmissionWebhook

ValidatingAdmissionWebhook admission controllers evaluate and validate operations without modifying them. These admission controllers can reject requests that do not satisfy certain conditions such as pod security policies, namespace creation, and resource quotas.

MutatingAdmissionWebhook admission controllers have the ability to modify or mutate operations. For example, a mutating webhook could automatically inject labels into all pods created in a namespace. Other use cases for mutating webhooks include adding sidecar containers, changing container images, and configuring environment variables.

What Are Admission Restrictions?

In addition to validating and mutating requests, admission controllers can also be used to impose restrictions on what operations are allowed in a cluster. For example, an administrator might want to prevent users from creating new pods in the production namespace or from accessing secrets in any namespace. To implement these kinds of restrictions, administrators can use one or more of the following:

* A whitelist that only allows certain operations

* A blacklist that blocks specific operations

* A policy file that defines rules for allowing or denying specific operations

By default, Kubernetes has several built-in admission controllers that provide basic validation and mutation capabilities out-of-the-box. In addition, there are many community-developed admission controllers that can be installed and used to further customize the behavior of a Kubernetes cluster.

Key Concepts of Admission Controllers in Kubernetes.

Kubernetes admission controllers are installed as part of the API server. To install all available admission controllers, use the –enable-admission-plugins flag when starting the API server. The following example installs all available admission controllers on a node:

kube-apiserver -h | grep enable-admission-plugins

Some admission controllers are disabled by default. To enable a specific controller, use the –enable-admission-plugins flag and specify the name of the controller. The following example enables the LimitRanger controller:

kube-apiserver --enable-admission-plugins=LimitRanger

Configuration of Admission Controllers.

Admission controllers are configured using command line flags or an admission control configuration file. The following table lists the command line flags that can be used to configure admission controllers:

–admission-control-config-file string Path to an admission control configuration file.

–disable-admission-plugins strings Comma separated list of admission controllers to disable in addition to those specified by –enable-admission-plugins (default “AlwaysPullImages”). Valid controller names are AlwaysPullImages, DefaultStorageClass, DenyEscalatingExec, InitialResources, NamespaceLifecycle, NonResourceURLs, PersistentVolumeClaimResize, PodSecurityPolicy, ResourceQuota, ServiceAccount, StorageObjectInUseProtection””.

–enable-admission–plugins strings Comma separated list of admissions controllers to enable in addition to those specified by –disable–admission–plugins (default “*”). Valid controller names are AlwaysPullImages，DefaultStorageClass，DenyEscalatingExec，InitialResources，NamespaceLifecycle，NonResourceURLs，PersistentVolumeClaimResize，PodSecurityPolicy，ResourceQuota，ServiceAccount，StorageObjectInUseProtection. Only these admitted will be enabled plus any that may be explicitly enabled via individual plugin’s configuration files.

So with that out of the way let’s start working with admission controllers and take a look at the clusters current admission controllers.

cd /etc/kubernetes/manifests

Now this folder as we are familiar with holds the kube-apiserver file along with a few others that encompass our cluster run a “ls” command to list them

So now we will run the following command and inspect the admission controller plugins on our cluster

cat kube-apiserver.yaml | grep admission*

So we can see we have a NodeRestriction that is enabled on our cluster currently now we will start the setup for our Image Policy.

{
    "apiVersion": "apiserver.config.k8s.io/v1",
    "kind": "AdmissionConfiguration",
    "plugins": [
       {
          "name": "ImagePolicyWebhook",
          "configuration": {
             "imagePolicy": {
                "kubeConfigFile": "/etc/kubernetes/policywebhook/kubeconf",#edit
                "allowTTL": 100,
                "denyTTL": 50,
                "retryBackoff": 500,
                "defaultAllow": false
             }
          }
       }
    ]
 }

Our kubeconfig file should look like the code listed below

# clusters refers to the remote service.
clusters:
  - name: admission_configuration
    cluster:
      certificate-authority: etc/kubernetes/pki/ca.pem    # CA for verifying the remote service.
      server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.

# users refers to the API server's webhook configuration.
users:
  - name: api-server
    user:
      client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use
      client-key: /path/to/key.pem          # key matching the cert

Status of Admission Controllers.

The status of an installed but not enabled admission controller is Unknown. The status of an enabled but unconfigured admission controller is Uninitialized. After an initial successful startup and initialization step (performed at most once per apiserver), all remaining active plugins should report as Healthy.”

Benefits of Admission Controllers in Securing a Kubernetes Cluster.

Admission controllers provide an additional layer of security to your Kubernetes cluster by validating incoming requests and enforcing policies. This can help to prevent accidental or malicious modifications to your cluster resources. Admission controllers can also be used to enforce compliance with company or regulatory policies. For example, you could use an admission controller to ensure that all containers in your cluster are run with a specific security profile such as AppArmor or SELinux.

Automated Policies for Restricting Access.

Admission controllers can be used to automatically enforce policies for restricting access to your Kubernetes cluster. For example, you could use an admission controller to limit who can create new pods in your cluster, or what kind of pods can be created. This can help to prevent unauthorized access or modifications to your cluster resources.

Improved System Visibility and Analytics.

Admission controllers can also be used to improve system visibility and analytics by providing detailed logs of all incoming requests. This information can be useful for auditing or debugging purposes. Additionally, some admission controllers allow you to specify what kind of information should be logged, which can help you troubleshoot issues more quickly.

How to Configure Admission Controllers in Kubernetes.

Admission controllers are implemented as Kubernetes plugins and are invoked during the admission review process. This process happens when a client attempts to create, update, or delete a resource in the cluster. The request is first validated and then sent to each admit- tance controller for processing. After all of the controllers have processed the request, it is either admitted or rejected.

There are two types of admission controllers:

1) ValidatingAdmissionWebhook

2) MutatingAdmissionWebhook

ValidatingAdmissionWebhook admission controllers can validate and/or mutate incoming requests to Kubernetes resources (validation is performed first, followed by mutation). For example, a validating webhook might check that an incoming Pod does not use an invalid image name. A mutating webhook might automatically inject labels into all Pods created in a Namespace.

MutatingAdmissionWebhook admission controllers can only mutate incoming requests. They cannot validate them. For example, a mutating webhook might automatically inject labels into all Pods created in a Namespace.

Editing or Adding Admission Controllers in the API Server.

You can enable or disable admission controllers by editing the kube-apiserver binary file that starts your API server instance. The –enable-admission-plugins and –disable-admission-plugins command line arguments take comma separated lists of admission controller plugin names, e.g., NodeRestriction . These two arguments are mutually exclusive; you cannot provide both on the same kube-apiserver invocation.

If you do not explicitly enable or disable an admission controller plugin, it is enabled by default. The following table lists the default status of each admission controller plugin:

ValidatingAdmissionWebhook: enabled

MutatingAdmissionWebhook: disabled

Initializers: enabled

Priority: disabled

LimitRanger: enabled

ServiceAccount: enabled

ResourceQuota: enabled

Configuring Admission Controllers with the Kubernetes API.

In addition to being able to enable or disable admission controllers using the kube-apiserver binary file, you can also configure them using Kubernetes API objects. This can be done by creating or updating a ClusterRole that has rules granting the apiservices.admissionregistration.k8s.io resource for the desired subresources. For example, to enable the ValidatingAdmissionWebhook and MutatingAdmissionWebhook admission controller plugins, you would create or update a ClusterRole like the following:

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

name: my-cluster-role

rules:

- apiGroups: ["apiservices.admissionregistration.k8s.io"]

resources: ["validatingwebhookconfigurations", "mutatingwebhookconfigurations"]

verbs: ["get", "create", "update", "patch", "delete"]

Strategies for Restricting Operations in Kubernetes.

Using Service Accounts to Limit Access with RBAC Policies.

In a multi-tenant environment, it is often desirable to restrict access to certain namespaces or resources within a namespace. This can be accomplished by using Admission Controllers and setting up proper RBAC policies.

There are a few different ways of restricting operations in Kubernetes: using namespaces, service accounts, and RBAC policies. Each of these has its own benefits and drawbacks, so it’s important to choose the right strategy for your particular use case.

Using namespaces is a good way to limit access to certain resources within a cluster. For example, you could create a namespace for each team or project, and then only allow members of that team or project to access the resources in that namespace. This approach is simple and easy to understand, but it can be difficult to manage at scale if you have many teams or projects.

Service accounts are another way of restricting access to certain parts of a cluster. With service accounts, you can create separate accounts for each team or project, and then limit what each account can access. This approach is more flexible than using namespaces, but it can be more difficult to set up and manage properly.

Finally, you can use RBAC policies to restrict operations in Kubernetes. RBAC stands for role-based access control, and it allows you to define fine-grained permissions for users and groups within a cluster. This approach is very flexible and powerful, but it can be challenging to configure correctly.

Conclusion

Overall, the evidence suggests that the impact of technology on our lives is undeniable. Technology has become an integral part of our lives, allowing us to stay connected, access information, and automate everyday tasks. While there are potential risks associated with technology, the benefits far outweigh them. As kubernetes continues to integrate changes and add features we will likely see the admission controller expanding to more control of validation to increase security. This is a strong native option of the kubernetes features out of the box consider utilizing this in your cluster.