Let's start with some context:
I'm studying CKS and reading CIS_Kubernetes_Benchmark_v1.6.0.pdf and there's a confusing section:
1.2.17 Ensure that the admission control plugin NodeRestriction is set (Automated)
...
Verify that the --enable-admission-plugins argument is set to a value that includes
NodeRestriction.
Remediation:
Follow the Kubernetes documentation and configure NodeRestriction plug-in on kubelets.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-
apiserver.yaml on the master node and set the --enable-admission-plugins parameter
to a value that includes NodeRestriction.
The part about check if /etc/kubernetes/manifests/kube-apiserver.yaml
has an entry for - --enable-admission-plugins=NodeRestriction
,... makes sense, the annoying part is
"Follow the Kubernetes documentation and configure NodeRestriction plug-in on kubelets."
Is extremely hard to google, and the Kubernetes official docs aren't clear about how to do this.
So now that the context is there the question is:
After setting - --enable-admission-plugins=NodeRestriction
on the kube-apiserver, how do you verify that the NodeRestriction plug-in on the kubelet has been correctly configured?
To properly enable NodeRestrictions Admission Controller Plugin, you actually need to update kubernetes configuration in 3 different places:
--enable-admission-plugins=NodeRestriction,...
--authorization-mode=Node,RBAC
(You must have Node specified)/var/lib/kubelet/config.yaml
should haveauthorization.mode: Webhook
(Other kubernetes distributions may substitute/var/lib/kubelet/config.yaml
with another method of configuring it, but I'm sure there'd be a matching value)When kubelet's authorization.mode is set to Webhook, instead of it's default of
AlwaysAllow
, it offloads authorization decisions to the kubernetes api-server. The Node Authorization mode is a special-purpose authorization mode that specifically authorizes API requests made by kubelet.(The giantswarm article below is a great read, and does a good job explaining why you should implement this setting, I'll try to summarize it by saying that's generic hardening that helps prevent privilege escalation by a compromised workload or bad actor.)
Sources:
1.) Kubernetes Security Essentials (LFS260)
2.) Securing the Configuration of Kubernetes Cluster Components
3.) Using Node Authorization