# Security Hardening and Compliance Assessment of Kubernetes Control Plane and Workloads
## 4 Security Hardening of Kubernetes Components
### Control Plane Security
#### 4.1.3 Securing Kube-Scheduler  
Given the kube-scheduler role in workload placement, it must be adequately secured to prevent unauthorized access or disruptions in cluster operations. Compromising the kube-scheduler component can affect the cluster's pod performance and availability. To safeguard the kube-scheduler, Figure 4 shows the security actions to be considered:  
The configuration file in the figure contains the following measures to turn off profiling and restrict external connection requests. Since profiling exposes system-specific details, setting the --profiling option to false in /etc/kubernetes/scheduler.conf helps minimize the attack surface. Profiling endpoints typically expose detailed runtime information such as CPU and memory usage, stack traces, and other debugging data. Attackers can analyze this data to gain insights into the system, identify potential weaknesses, or plan further attacks. Next, external access to the kube-scheduler should be restricted in the scheduler. The conf file is located in the/etc/kubernetes directory.  
Furthermore, the \"AllowExtTrafficLocalEndpoint\" feature gate, when set to \"false\" (\"--feature-gates=AllowExtTrafficLocalEndpoint=false\"), removes the ability for Services  
Figure 4: Kube-scheduler security measures.  
Figure 3: Restoring etcd state from its snapshot.  
with the externalTrafficPolicy set to \"Local\" to use a local endpoint for external traffic [20]. By turning this feature off, the cluster will not allow traffic from outside the cluster to be routed exclusively to nodes that have a local Pod endpoint for that Service. This configuration can be necessary in environments where preserving the source IP of external traffic is either unnecessary or undesirable, or where uniform distribution of incoming traffic across all nodes is preferred over local endpoint routing.  
The certificates and keys for TLS are also implemented and are specified in the kubecheduler static pod manifest. Here is an explanation of TLS configuration:  
* \(-\)tls-cert-file\(=\)/etc/kubernetes/pki/scheduler.crt: specifies the kube-scheduler's TLS certificate for secure communication.
* \(-\)tls-private-key-file\(=\)/etc/kubernetes/pki/scheduler.key: specifies the private key associated with the TLS certificate.
* \(-\)client-ca-file\(=\)/etc/kubernetes/pki/ca.crt: CA file for validating incoming client certificates.  
By enforcing certificate-based authentication, administrators can ensure that only authorized components interact with the scheduler. TLS protects sensitive data between the scheduler and other components like the API server. Securing the Kubernetes kubecheduler is critical, as it decides on the placement of pods across the cluster based on scores and resource availability. If compromised, an attacker could manipulate pod scheduling, leading to resource exhaustion, unauthorized workload deployments, or denial of service.  
The control plane manages the orchestration of the cluster, while the application workloads are executed on worker nodes. These nodes operate containerized services and are frequently more susceptible to external traffic, making them vital in a defense-in-depth strategy. The subsequent section emphasizes node-level security, specifically, the fortification of the Kubelet and the runtime environment it oversees. Effectively securing the nodes prevents unauthorized users from directly manipulating workloads or establishing a foothold that could compromise the control plane.