<p>Even after granting cluster roles to user, I get <code>Error from server (Forbidden): User "system:anonymous" cannot list nodes at the cluster scope. (get nodes)</code></p>

<p>I have the following set for the user:</p>

<pre><code>- context:
    cluster: kubernetes
    user: user@gmail.com
  name: user@kubernetes`  set in the ~/.kube/config file
</code></pre>

<p>and the below added to admin.yaml to create cluster-role and cluster-rolebindings:</p>

<pre><code>kind: CluserRouster: kubernetes    user: nsp@gmail.com  name: nsp@kubernetese
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
  name: admin-role
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
---
oidckind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
  name: admin-binding
subjects:
  - kind: User
    name: nsp@gmail.com
roleRef:
  kind: ClusterRole
  name: admin-role
</code></pre>

<p>When I try the command I still get error.</p>

<pre><code>kubectl --username=user@gmail.com get nodes
Error from server (Forbidden): User "system:anonymous" cannot list nodes at the cluster scope. (get nodes)
</code></pre>

<p>Can someone please suggest on how to proceed.</p>

NSP
<p>Your problem is not with your ClusterRoleBindings but rather with user authentication. Kubernetes tells you that it identified you as <code>system:anonymous</code> (which is similar to *NIX's nobody) and not nsp@example.com (to which you applied your binding).</p>

<p>In your specific case the reason for that is that the <code>username</code> flag uses HTTP Basic authentication and needs the <code>password</code> flag to actually do anything. But even if you did supply the password, you'd still need to actually tell the API server to accept that specific user.</p>

<p>Have a look at <a href="https://kubernetes.io/docs/admin/authentication/" rel="nofollow noreferrer">this</a> part of the Kubernetes documentation which deals with different methods of authentication. For the <code>username</code> and <code>password</code> authentication to work, you'd want to look at the Static Password File section, but I would actually recommend you go with X509 Client Certs since they are more secure and are operationally much simpler (no secrets on the Server, no state to replicate between API servers). </p>
