# Security Hardening and Compliance Assessment of Kubernetes Control Plane and Workloads
## 4 Security Hardening of Kubernetes Components
### Observability and Auditing
#### 4.5.2 Logging  
Kubernetes facilitates comprehensive logging methodologies at both the node and podtiers. Node-level agent logging consolidates log collection throughout the cluster, whereas sidecar containers within pods provide application-specific log management. Collectively, these logging approaches augment observability and operational insight. We will now assess these logging approaches' capabilities and architectural trade-offs in scalable and resilient Kubernetes environments.  
Kubernetes Node-Level Agent Logging typically entails the deployment of agents such as Fluentd, Filebeat, or Logstash directly on each node. These agents gather logs from diverse sources, including container stdout/stderr, system logs, and Kubernetes components such as kubelet and container runtime logs. They standardize, process, and transmit logs to centralized logging systems such as Elasticsearch or cloud-native alternatives. This approach guarantees the reliable capture of all node and container logs, even for ephemeral pods [22; 23]. It also improves observability by offering host-level context and facilitates consistent logging across environments. Contemporary designs integrate lightweight, scalable agents that diminish performance overhead and facilitate dynamic microservices [24]. The first part of the standard Fluentd deployment configuration is shown in Figure 14:  
Fluentd is a flexible tool that significantly improves Kubernetes logging through centralized log aggregation, efficient log forwarding, and log processing capabilities. It is exceptionally efficient in performance and adept at managing substantial quantities of  
Figure 14: Standard Fluentd DaemonSet configuration.  
log data with negligible overhead. That is crucial in Kubernetes environments, where thousands of pods and containers produce logs at scale.  
This paper utilizes Fluentd as a centralized logging agent, implemented as a DaemonSet to bolster Kubernetes security via consistent log aggregation and forwarding at the node level to Elasticsearch. This method guarantees uniform capture of all cluster activities, even amidst node failures or container crashes, thus enhancing observability and forensic capabilities. This configuration highlights Fluentd's contribution to a security-first architecture, in contrast to previous implementations like the CMSWEB infrastructure at CERN, which utilized Fluentd as a sidecar or node-level agent to transmit logs to both S3 and Elasticsearch [26]. It closely integrates with auditing and monitoring systems and customizes Fluentd's configuration to conform to security best practices, including role-based access control (RBAC), TLS encryption, and secure multi-tenancy. Using Fluentd in this context fosters a defense-in-depth approach, wherein improved logging underpins real-time alerting, incident response, and sustained audit compliance, representing a progression beyond conventional logging frameworks that frequently emphasize operational visibility at the expense of security robustness.  
A sidecar container is a companion container in the same pod as the main application and is responsible for handling logging. It captures or gathers application logs (e.g., from shared volumes or stdout) and transmits them to a logging backend. This pattern segregates log collection from business logic, enhances modularity, and facilitates the customization of application-specific log routing and formats [19; 23].