Kube-hunter hunts for security weaknesses in Kubernetes clusters
View the Project on GitHub aquasecurity/kube-hunter
KHV051 - Exposed Existing Privileged Containers Via Secure Kubelet Port
Issue description
The kubelet is configured to allow anonymous (unauthenticated) requests to its HTTPs API. This may expose certain information and capabilities to an attacker with access to the kubelet API.
A privileged container is given access to all devices on the host and can work at the kernel level. It is declared using the Pod.spec.containers[].securityContext.privileged attribute. This may be useful for infrastructure containers that perform setup work on the host, but is a dangerous attack vector.
Furthermore, if the kubelet and the API server authentication mechanisms are (mis)configured such that anonymous requests can execute commands via the API within the containers (specifically privileged ones), a malicious actor can leverage such capabilities to do way more damage in the cluster than expected: e.g. start/modify process on host.
Remediation
Ensure kubelet is protected using --anonymous-auth=false kubelet flag. Allow only legitimate users using --client-ca-file or --authentication-token-webhook kubelet flags. This is usually done by the installer or cloud provider.
Minimize the use of privileged containers.
Use Pod Security Policies to enforce using privileged: false policy.
Review the RBAC permissions to Kubernetes API server for the anonymous and default service account, including bindings.
Ensure node(s) runs active filesystem monitoring.
Set --insecure-port=0 and remove --insecure-bind-address=0.0.0.0 in the Kubernetes API server config.
Remove AlwaysAllow from --authorization-mode in the Kubernetes API server config. Alternatively, set --anonymous-auth=false in the Kubernetes API server config; this will depend on the API server version running.