<p>When run <code>kubectl get cs</code> on centos 7 I got below error message. </p>

<pre><code>No resources found.
Error from server (Forbidden): componentstatuses is forbidden: 
User "system:node:&lt;server-name&gt;" cannot list componentstatuses at the cluster scope
</code></pre>

<p>I can confirm the api server is running <code>kubectl cluster-info</code></p>

<pre><code>Kubernetes master is running at https://&lt;server-IP&gt;:6443
KubeDNS is running at https://&lt;server-IP&gt;:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
</code></pre>

<p>Also I have below in <code>~/.bash_profile</code></p>

<pre><code>export http_proxy=http://&lt;proxy-server-IP&gt;:3128
export https_proxy=http://&lt;proxy-server-IP&gt;:3128
export no_proxy=$no_proxy,127.0.0.1,localhost,&lt;server-IP&gt;,&lt;server-name&gt;
export KUBECONFIG=/etc/kubernetes/kubelet.conf
</code></pre>

<p>Not only <code>kubectl get cs</code> yield the error message, <code>kubectl apply -f kubernetes-dashboard.yaml</code> yield similar error message</p>

<pre><code>Error from server (Forbidden): error when retrieving current configuration of:
Resource: "/v1, Resource=secrets", GroupVersionKind: "/v1, Kind=Secret"
Name: "kubernetes-dashboard-certs", Namespace: "kube-system"
Object: &amp;{map["kind":"Secret" "metadata":map["labels":map["k8s-app":"kubernetes-dashboard"] "name":"kubernetes-dashboard-certs" "namespace":"kube-system" "annotations":map["kubectl.kubernetes.io/last-applied-configuration":""]] "type":"Opaque" "apiVersion":"v1"]}
from server for: "https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml": 
secrets "kubernetes-dashboard-certs" is forbidden: 
User "system:node:&lt;server-name&gt;" cannot get secrets in the namespace "kube-system": 
no path found to object
</code></pre>

Antelope
<blockquote>
  <p><code>export KUBECONFIG=/etc/kubernetes/kubelet.conf</code></p>
</blockquote>

<p>Is completely incorrect; you are, as the error message is cheerfully trying to inform you, attempting to perform cluster operations as a <code>Node</code>, not as one of the Users or <code>ServiceAccount</code>s. RBAC is almost explicitly designed to stop you from doing exactly what you are currently doing. You would never want a <code>Node</code> to be able to read sensitive credentials nor create arbitrary <code>Pod</code>s at cluster scope. </p>

<p>If you want to be all caviler about it, then ssh into a master Node and use the <code>cluster-admin</code> credentials usually found in <code>/etc/kubernetes/admin.conf</code> (or a similar file -- depending on how your cluster was provisioned). If you don't already <em>have</em> a <code>cluster-admin</code> credential, then create an X.509 certificate that is signed by a CA that the apiserver trusts with an Organization (<code>O=</code> in X.509 parlance) of <code>cluster-admin</code> and then create yourself a <code>ServiceAccount</code> (or whatever) with a <code>ClusterRoleBinding</code> of <code>cluster-admin</code> and go from there.</p>
