User "system:anonymous" cannot get path "/"

Question

I just setup a kubenetes cluster base on this link https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#multi-platform I check with kubectl get nodes, then the master node is Ready, but when I access to the link https://k8s-master-ip:6443/ it show the error: User "system:anonymous" cannot get path "/". What is the trick I am missing ?

Answer 1

Hope you see something like this:

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
    
  },
  "code": 403
}

This is good as not everyone should be able to access the cluster, if you want to see the services run "kubectl proxy", this should enable access to the services from the outside world.

C:\dev1> kubectl proxy
Starting to serve on 127.0.0.1:8001

And when you hit 127.0.0.1:8001 you should see the list of services.

Answer 2

The latest kubernetes deployment tools enable RBAC on the cluster. Jenkins is relegated to the catch-all user system:anonymous when it accesses https://192.168.70.94:6443/api/v1/.... This user has almost no privileges on kube-apiserver.

The bottom-line is, Jenkins needs to authenticate with kube-apiserver - either with a bearer token or a client cert that's signed by the k8s cluster's CA key.

Method 1. This is preferred if Jenkins is hosted in the k8s cluster:

1. Create a ServiceAccount in k8s for the plugin
2. Create an RBAC profile (ie. Role/RoleBinding or ClusterRole/ClusterRoleBinding) that's tied to the ServiceAccount
3. Config the plugin to use the ServiceAccount's token when accessing the URL https://192.168.70.94:6443/api/v1/...

Method 2. If Jenkins is hosted outside the k8s cluster, the steps above can still be used. The alternative is to:

1. Create a client cert that's tied to the k8s cluster's CA. You have to find where the CA key is kept and use it to generate a client cert.
2. Create an RBAC profile (ie. Role/RoleBinding or ClusterRole/ClusterRoleBinding) that's tied to the client cert
3. Config the plugin to use the client cert when accessing the URL https://192.168.70.94:6443/api/v1/...

Both methods work in any situation. I believe Method 1 will be simpler for you because you don't have to mess around with the CA key.