What role and rolebinding is kubectl associated to?

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 kubectl get pods from the master node, the request will go via kube-apiserver.

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 ?

Apologies if this is a ridiculous question.

Solution

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

Get user and group from current-context:

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

This script will print the Subject line of the client certificate:

$ 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:"

Output on my Mac when running kubernetes via Docker for Mac:

Subject: O=system:masters, CN=docker-for-desktop

O is the organization and represents a group in kubernetes.

CN is the common name and is interpreted as user by kubernetes.

Find corresponding clusterrole and clusterrolebinding:

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:

$ group="system:masters"
$ kubectl get clusterrolebindings -o json \
    | jq ".items[] | select(.subjects[].name==\"$group\")"

{
  "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"
    }
  ]
}

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

$ kubectl get clusterrole cluster-admin -o yaml

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:
  - '*'