You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context dev Context: A CIS Benchmark tool was run against the kubeadm created cluster and

This CKS/CIS Benchmark remediation task requires hardening a kubeadm cluster by fixing insecure authorization settings on the API server and Kubelet. The core issue is that the cluster was deployed with permissive defaults (AlwaysAllow authorization) that must be replaced with No

Submitted by kev92· May 4, 2026Cluster Hardening

Question

You can switch the cluster/configuration context using the following command:
[desk@cli] $ kubectl config use-context dev
Context:
A CIS Benchmark tool was run against the kubeadm created cluster and found multiple issues that must be addressed.
Task:
Fix all issues via configuration and restart the affected components to ensure the new settings take effect.
Fix all of the following violations that were found against the API server:
1.2.7 authorization-mode argument is not set to AlwaysAllow FAIL
1.2.8 authorization-mode argument includes Node FAIL
1.2.7 authorization-mode argument includes RBAC FAIL
Fix all of the following violations that were found against the Kubelet:

Explanation

Approach. For the API server violations, edit /etc/kubernetes/manifests/kube-apiserver.yaml and change the --authorization-mode flag from 'AlwaysAllow' to 'Node,RBAC'. Since this is a static Pod manifest, the kubelet will automatically restart the kube-apiserver container once the file is saved - no manual restart is needed. For Kubelet violations (commonly 4.2.1/4.2.2 in CIS), edit /var/lib/kubelet/config.yaml to set 'authorization.mode: Webhook' and 'authentication.anonymous.enabled: false', then restart the kubelet service with 'systemctl restart kubelet'. The CIS Benchmark requires Node authorizer to allow kubelets to read their own node/pod objects, and RBAC to enforce role-based access control for all other API consumers - AlwaysAllow bypasses all authorization checks entirely and must never be used in production.

Concept tested. Kubernetes CIS Benchmark hardening - specifically securing the kube-apiserver --authorization-mode flag (replacing AlwaysAllow with Node,RBAC) and locking down Kubelet authentication/authorization via its config file. Tests knowledge of where kubeadm stores static Pod manifests (/etc/kubernetes/manifests/), the Kubelet config file location (/var/lib/kubelet/config.yaml), and that static Pod changes self-restart while Kubelet changes require 'systemctl restart kubelet'.

Reference. CIS Kubernetes Benchmark v1.8 - Controls 1.2.7, 1.2.8, 1.2.9 (API Server authorization-mode), 4.2.1, 4.2.2 (Kubelet anonymous auth and authorization mode). Kubernetes docs: kube-apiserver reference flags, Kubelet configuration file.

Topics

#CIS Benchmarks#API Server Hardening#Kubelet Hardening#Kubernetes Authorization

Community Discussion

No community discussion yet for this question.

Full CKS Practice