Critical security vulnerability in instructions on z2jh.jupyter.org to set up a Amazon EKS based k8s cluster

JupyterHub Zero to JupyterHub on Kubernetes
1

The documentation for how to setup a Amazon EKS based k8s cluster has since its introduction included an insecure instruction, that if followed, provided anyone with access to control the k8s cluster.

If you have setup a Amazon EKS k8s cluster following the instructions between 0.7.0-beta.1 and 1.11.1 in the https://z2jh.jupyter.org documentation, you should check if you are affected.

Are you affected?

# If this returns a resource, you are affected
kubectl get clusterrolebinding cluster-system-anonymous

If you are affected

Start by removing anonymous access to the k8s api-server.

kubectl delete clusterrolebinding cluster-system-anonymous

After this you need to make a decision by yourself.

Consequences

Anyone able to establish a network connection to the k8s api-server, for example from inside a container in the k8s cluster, would be able to do anything in the k8s cluster.

Consider that:

  • A malicious user could have established access to the k8s cluster by creating additional k8s ClusterRoleBinding resources and k8s ServiceAccount resources.
  • A malicious user could have mounted storage and inserted malicious code, making a transfer of storage to another cluster a risky operation as well.

For reference - the insecure step

For reference, this was the final instruction that was insecure and now have been removed from all versions of the published documentation.

  1. Preparing authenticator for Helm

    There might be a better way to configure this

    Since the described helm deployment in the next section uses RBAC, system:anonymous user must be given access to administer the cluster. This can be done by the following command

    kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous
1 Like