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.
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 proider.
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.