Understanding Anonymous Access in Kubernetes API Server and How to Disable It

This week there were articles about the Dero cryptojacking operation, and one detail caught my attention: attackers targeting clusters that allow anonymous access to the Kubernetes API. How and why anonymous access is possible is an interesting topic spanning several areas, so I will write about it.

How does anonymous access work?

The ability for a cluster to be accessed anonymously is controlled by the --anonymous-auth flag of the kube‑apiserver component, which defaults to true. Therefore, if you do not see this flag explicitly set in the server’s argument list, anonymous access is enabled.

However, this setting alone does not grant attackers many permissions because it only covers one of the three steps a request passes through before being processed (Authentication → Authorization → Admission Control). As the Kubernetes access control documentation shows, after authentication a request must also pass through authorization and admission control.

Authorization and anonymous access

The next step is that the request must match an authorization policy (usually RBAC, but other policies are possible). To do this, the request must be assigned an identity, at which point the system:anonymous and system:unauthenticated groups come into play. These identities are assigned to any request without a valid authentication token and are used to match authorization policies.

You can inspect the

system:public-info-viewer

clusterrolebinding

on a Kubeadm cluster to see how this works.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:public-info-viewer
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:public-info-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:unauthenticated

How common is anonymous access

Now that we know how anonymous access works, the question becomes “how common is it?”. The answer is that most major distributions enable anonymous access by default, typically via the

system:public-info-viewer

clusterrole

which grants access to /version and several other endpoints.

To gauge how many clusters this applies to, we can use Censys or Shodan to find clusters that return version information. For example, a Censys query shows over a million hosts returning version data, indicating this is a fairly common configuration.

A more serious angle, as highlighted in the Dero article, is how many of those clusters allow an attacker to create workloads. While Censys cannot give an exact number, it does have a query that enumerates pods anonymously; at the time of writing it returned 302 cluster nodes. Some may be honeypots, but many could be high‑risk, vulnerable clusters.

Disabling anonymous access

On self‑managed clusters (e.g., Rancher, Kubespray, Kubeadm) you can disable anonymous access by passing the flag --anonymous-auth=false to the kube-apiserver component.

On managed clusters (e.g., EKS, GKE, AKS) you cannot change this flag, but you can delete any RBAC rules that allow anonymous users to act. For example, on a Kubeadm cluster you can remove the

system:public-info-viewer

clusterrolebinding

and the associated

system:public-info-viewer

clusterrole

to effectively block anonymous information gathering.

Of course, if you have applications that depend on those endpoints (such as health checks), they will break, so it is important to test any changes you make to your cluster. One approach is to review your audit logs for any anonymous requests to the API server.

Conclusion

Allowing some level of anonymous access is a common default in Kubernetes. While not a severe security issue by itself, it means that in many configurations the only line of defense against an attacker compromising your cluster is the RBAC policy, and a single misconfiguration can lead to major problems, especially when the cluster is exposed to the internet.