Checks

Kubernetes Pods configured with hostNetwork: true are identified, meaning they share the node's network namespace and use the host's IP stack, interfaces, and ports.

Kubernetes Pods are evaluated for volumes of type hostPath, which mount paths from the node filesystem into a pod.

Kubernetes Pods configured with hostPID: true are identified, indicating the container shares the node's host PID namespace.

Kubernetes pods where any container's security context adds the NET_RAW Linux capability are identified.

The inspection evaluates container securityContext.capabilities.add entries to detect explicit requests for NET_RAW.

Kubernetes Pods are evaluated for containers configured with securityContext.privileged: true, indicating execution in privileged mode.

Kubernetes Pods are assessed for containers configured to run as the root user. The evaluation identifies containers whose security context sets runAsUser: 0.

Kubernetes Pods containers define environment variables sourced from Secrets via secretKeyRef instead of mounting them as files.

Ensure each regular pod container has a readiness probe configured to signal when it is ready to serve traffic.

Kubernetes Pods are evaluated to ensure every container sets readOnlyRootFilesystem: true in its securityContext. A writable root filesystem lets an attacker who gains code execution modify binaries, drop tools, or persist malicious files inside the container.

Kubernetes Pods and their containers specify the runtime default seccomp profile using seccompProfile.type: RuntimeDefault in the security context.

The evaluation looks for this setting at the Pod level or per container.

Etcd is configured to require TLS client certificate authentication when the etcd container includes --client-cert-auth, so client access is validated with trusted certificates.

Etcd configuration is reviewed for the --auto-tls option, which enables automatically generated self-signed certificates for client TLS.

Presence of this flag indicates self-signed TLS is used; absence indicates client TLS relies on externally managed certificates.

Etcd peer TLS configuration is evaluated by checking etcd containers for the --peer-auto-tls flag. Presence of --peer-auto-tls indicates peers use automatically generated self-signed certificates for inter-peer connections.

Etcd requires peer client certificate authentication for inter-member traffic via --peer-client-cert-auth=true set in the etcd container command

Etcd peer communication is treated as secure when TLS is configured with a peer certificate and key (e.g., --peer-cert-file and --peer-key-file). The assessment inspects etcd containers for these options to determine whether server-to-server traffic is encrypted and authenticated.

Etcd pods are assessed for TLS-enabled client communication, indicated by --cert-file and --key-file in container arguments, showing that Kubernetes API state traffic is encrypted in transit.

Etcd configuration is assessed to ensure it trusts a unique Certificate Authority via --trusted-ca-file, distinct from the API server's --client-ca-file. If the same CA file is used, etcd shares the cluster CA; differing files imply separation, though CA content should still be verified.

Kubernetes Kubelet authorization configuration is inspected to confirm the mode is not AlwaysAllow.

If authorization settings are absent, the effective mode requires manual verification.

Kubernetes Kubelet is evaluated for X.509 client certificate authentication by checking if its config sets authentication.x509.clientCAFile to validate clients on the HTTPS endpoint.

Kubernetes Node kubeconfig at /etc/kubernetes/kubelet.conf is evaluated for file ownership root:root. The check focuses on who owns the file that defines the kubelet's API client settings and certificates.

Kubernetes Kubelet kubeconfig at /etc/kubernetes/kubelet.conf must have owner-only permissions (0600 or stricter). The check evaluates the file mode to ensure it is not more permissive than 0600.

Kubernetes Kubelet configuration file config.yaml (e.g., /var/lib/kubelet/config.yaml) is evaluated to confirm ownership by root:root when the kubelet uses a config file via --config.

Kubernetes Kubelet configuration file (/var/lib/kubelet/config.yaml) is evaluated for restrictive file permissions. When kubelet uses --config, the file is expected to be owner-only readable/writable (600) or more restrictive.

Kubernetes Kubelet configuration for its HTTPS endpoint is evaluated to ensure anonymous authentication is disabled, requiring authenticated requests (authentication.anonymous.enabled=false).