<p>I am trying to understand how kubectl gets permissions to run the commands. 
I understand that all interactions with kubernetes clusters go through the kube-apiserver. So when we run a kubectl command, say <code>kubectl get pods</code> from the master node, the request will go via kube-apiserver. </p>

<p>The apiserver does the authentication and authorization and provide the results back. 
kubectl like any other user or resource should also be associated with a role and rolebinding to acquire the permissions for accessing the resources on the cluster. How can I check to which role and rolebinding is the kubectl associated to ?</p>

<p>Apologies if this is a ridiculous question.</p>

<p>This answer is an extension to the other ones and helps you with scripts when are using <strong>client certificates</strong>:</p>

<h2>Get user and group from current-context:</h2>

<p>If you are using client certificates, your <code>~/.kube/config</code> file contains <code>client-certificate-data</code> for the user of the current context. This data is a <code>base64</code> encoded certificate which can be displayed in text form with <code>openssel</code>. The interesting information for your question is in the <code>Subject</code> section. </p>

<p>This script will print the <code>Subject</code> line of the client certificate:</p>

<pre class="lang-sh prettyprint-override"><code>$ kubectl config view --raw -o json \
    | jq ".users[] | select(.name==\"$(kubectl config current-context)\")" \
    | jq -r '.user["client-certificate-data"]' \
    | base64 -d | openssl x509 -text | grep "Subject:"
</code></pre>

<p>Output on my Mac when running kubernetes via Docker for Mac:</p>

<p><code>Subject: O=system:masters, CN=docker-for-desktop</code></p>

<p><code>O</code> is the organization and represents a <strong>group</strong> in kubernetes.</p>

<p><code>CN</code> is the common name and is interpreted as <strong>user</strong> by kubernetes.</p>

<h2>Find corresponding clusterrole and clusterrolebinding:</h2>

<p>Now you know which user and group you are using with kubectl at the moment. 
To find out which (cluster)rolebinding you are using, you have to look for the identified group/user:</p>

<pre class="lang-sh prettyprint-override"><code>$ group="system:masters"
$ kubectl get clusterrolebindings -o json \
    | jq ".items[] | select(.subjects[].name==\"$group\")"
</code></pre>

<pre><code>{
  "apiVersion": "rbac.authorization.k8s.io/v1",
  "kind": "ClusterRoleBinding",
  "metadata": {
    "annotations": {
      "rbac.authorization.kubernetes.io/autoupdate": "true"
    },
    "creationTimestamp": "2020-03-31T14:12:13Z",
    "labels": {
      "kubernetes.io/bootstrapping": "rbac-defaults"
    },
    "name": "cluster-admin",
    "resourceVersion": "95",
    "selfLink": "/apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin",
    "uid": "878fa48b-cf30-42e0-8e3c-0f27834dfeed"
  },
  "roleRef": {
    "apiGroup": "rbac.authorization.k8s.io",
    "kind": "ClusterRole",
    "name": "cluster-admin"
  },
  "subjects": [
    {
      "apiGroup": "rbac.authorization.k8s.io",
      "kind": "Group",
      "name": "system:masters"
    }
  ]
}
</code></pre>

<p>You can see in the output that this group is associated with the <code>ClusterRole</code> <code>cluster-admin</code>. You can take a closer look at this clusterrole to see the permissions in detail:</p>

<pre class="lang-sh prettyprint-override"><code>$ kubectl get clusterrole cluster-admin -o yaml
</code></pre>

<pre class="lang-yaml prettyprint-override"><code>apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2020-03-31T14:12:12Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "42"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-admin
  uid: 9201f311-4d07-46c3-af36-2bca9ede098f
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*'
</code></pre>
