Kubernetes Admission Controllers

Kubernetes supports over 30 Admission Controllers. Subsequent to Authorization and Authentication, Admission Controllers are the final step in a 3-step process before Kubernetes persists the resource in etcd (a consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data). Some relevant Admission Controllers to secure running containers are:

• PodSecurityPolicy: this option implements pod admission based on security context and available policies.
• DenyEscalatingExec: when hackers open shells in privileged containers, they have access to the host. This option ensures that exec and attach commands from privileged containers are blocked.
• AlwaysPullImages: while there is a performance advantage to storing and reusing image on a node, hygiene and the assurance that you always run up-to-date container images may be important. Since vulnerabilities are patched upstream, pulling images ensures that the latest remediation are always downloaded.
• LimitRange and ResourceQuota: to prevent denial of service attacks, and any spawning of unauthorized processes from established pods, this option observes incoming requests for violation of these limits.
• NodeRestriction: this limits the permissions of each kubelet, ensuring that it can only modify pods that are bound to it and its own Node object.

NodeRestriction

This admission controller limits the Node and Pod objects a kubelet can modify. In order to be limited by this admission controller, kubelet must use credentials in the system:node group, with a username in the form system:node:<NodeName>. Such kubelet will only be allowed to modify their own Node API object.

NodeRestriction admission plugin prevents kubelet from deleting its Node API object, and enforces kubelet modification of labels under the kubernetes.io/ or k8s.io/ prefixes as follows:

• Allows kubelet to add/remove/update these labels and label prefixes:
• Prevents kubelet from adding/removing/updating labels with a node-restriction.kubernetes.io/ prefix. This label prefix is reserved for administrators to label their Node objects for workload isolation purposes, and kubelet will not be allowed to modify labels with that prefix.

Use of any other labels under the kubernetes.io or k8s.io prefixes by kubelet is reserved, and may be disallowed or allowed by the NodeRestriction admission plugin in the future.

Future version may add additional restrictions to ensure kubelets have the minimal set of permissions required to operate correctly.

Do we need them?

Many advanced features in Kubernetes require an Admission Controller to be enabled in order to properly support the feature. As a result, a Kubernetes API server, that is not properly configured with the right set of Admission Controllers is an incomplete server and will not support all the features you expect.

Turn on an Admission Controller

The Kubernetes API server flag enable-admission-plugins takes a comma-delimited list of admission control plugins to invoke prior to modifying objects in the cluster. For instance, the following command line enables the NamespaceLifecycle and the LimitRanger admission control plugins:

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

Note: Depending on the way your Kubernetes cluster is deployed and how the API server is started, you may need to apply the setting in different ways. For instance, you may have to modify the systemd unit file if the API is deployed as a systemd service; while you may have to modify the manifest file for the API server if Kubernetes is deployed in a self-hosted way.

Recommended set of Admission Controllers

For Kubernetes version 1.10 and later, it is recommended running the set of Admission Controllers using the --enable-admission-plugins flag.

For Kubernetes 1.9 and earlier, it is recommended running the set of Admission Controllers using the --admission-control flag.

In the next article, we will walk through Kubernetes Authorization and RBAC in detail.