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
andattach
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 anode-restriction.kubernetes.io/
prefix. This label prefix is reserved for administrators to label theirNode
objects for workload isolation purposes, andkubelet
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 asystemd
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.