Kubernetes Admission Controllers
Kubernetes Admission Controllers
With over thirty admission controllers supported, this article goes into some of the details for the controllers that can be used for running containers securely.
Join the DZone community and get the full member experience.Join For Free
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
attachcommands 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.
This admission controller limits the
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
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
k8s.io/ prefixes as follows:
kubeletto add/remove/update these labels and label prefixes:
kubeletfrom adding/removing/updating labels with a
node-restriction.kubernetes.io/prefix. This label prefix is reserved for administrators to label their
Nodeobjects for workload isolation purposes, and
kubeletwill not be allowed to modify labels with that prefix.
Use of any other labels under the
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:
Recommended Set of Admission Controllers
For Kubernetes version 1.10 and later, it is recommended running the set of Admission Controllers using the
For Kubernetes 1.9 and earlier, it is recommended running the set of Admission Controllers using the
In the next article, we will walk through Kubernetes Authorization and RBAC in detail.
Published at DZone with permission of Sudip Sengupta . See the original article here.
Opinions expressed by DZone contributors are their own.