<p>using <code>kubectl</code> and <code>kops</code> <code>1.8</code></p>

<p>When spinning of a cluster in <code>aws</code> using <code>kops</code> the client certificate (present as string in the <code>client-certificate-data</code> field of  <code>~/.kube/config</code>) created has the following values:</p>

<pre><code>    Subject: O=system:masters, CN=kubecfg
</code></pre>

<p>Unless I am wrong, starting from <code>kubernetes 1.4</code>, the value for <code>O</code>rganitazion is interpeted as <code>group</code> information (string associated with <code>CN</code> value is the so-called user, since <code>k8s</code> does not inherently have such a concept)</p>

<p><strong>1</strong>: How can I see what permissions are associated with the <code>system:masters</code> group and/or the <code>kubecfg</code> user? </p>

<ul>
<li>(related to the above): what is the out-of-the-box authorization method I am using now? <code>RBAC</code>? How can I check this?</li>
</ul>

<p><strong>2</strong>: Why the entries in my <code>~/.kube/config</code> do <strong>not</strong> incorporate a <code>kubecfg</code> user? (but rather a user bearing my cluster name and another user named <code>admin</code>?)</p>

<pre><code>$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: &lt;server_url&gt;
  name:  &lt;my_cluster_name&gt;
contexts:
- context:
    cluster:  &lt;my_cluster_name&gt;
    user:  &lt;my_cluster_name&gt;
  name:  &lt;my_cluster_name&gt;
current-context:  &lt;my_cluster_name&gt;
kind: Config
preferences: {}
users:
- name: &lt;my_cluster_name&gt;
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    password: &lt;some_pass&gt;
    username: admin
- name: &lt;my_cluster_name&gt;.local-basic-auth
  user:
    password: &lt;some_pass&gt;
    username: admin
</code></pre>

<p>At the end of the day, what user I am performing api calls with, when executing <code>kubectl</code> commands?</p>

<p><strong>update</strong>: I tried to mess up the value of <code>client-certificate-data</code> in my <code>~/.kube/config</code> and I got </p>

<blockquote>
  <p>error: tls: private key does not match public key</p>
</blockquote>

<p>I am assuming this means I am using a <code>x509</code> based auth (?)</p>

<p>So I am making api calls as <code>kubecfg</code> ?</p>

<p>Note that there is a <a href="https://stackoverflow.com/questions/6556522/authentication-versus-authorization">difference</a> between <strong>authentication</strong> and <strong>authorization</strong>.</p>

<ul>
<li>Authentication ensures that a user is who they say they are.  Calls to the Kubernetes API always requires successful authentication.</li>
<li>Authorization determines whether a user has access to specific Kubernetes API resources (via RBAC).  RBAC must be explicitly enabled as a configuration option to the <a href="https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/" rel="nofollow noreferrer">kube-apiserver</a> server.</li>
</ul>

<p>Kubernetes <strong>Authentication</strong></p>

<ul>
<li><p>In Kubernetes, there are many <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/" rel="nofollow noreferrer">mechanisms</a> which may be used to to authenticate a user such as tokens, passwords, OIDC connect tokens, and SSL x509 client certs.</p></li>
<li><p>As you have discovered above, <code>kops</code> will auto-generate a ~/.kube/config file with an embedded SSL x509 client certificate.
Presenting the client certificate along with any REST call to the kube-apiserver allows the kube-apiserver to authenticate the caller by validating that the client certificate has been signed by the cluster Certificate Authority (CA).  If the client cert has been properly signed, then the caller is who they say they are.</p></li>
<li><p>The identity of the holder of the client certificate is determined by the Subject field of the SSL x509 client certificate.</p>

<ul>
<li>Subject Common Name determines the user identity.  (e.g. CN=Bob)</li>
<li>Subject Organization determines the user's groups. (e.g. O=admins, O=system:masters).  Note that multiple organizations (i.e. groups) may be specified.</li>
</ul></li>
<li>Please note that <code>user</code> name in the kubeconfig file is just an opaque value user for the convenience of the kubectl tool.  The real identity of the <code>user</code> is that which has been embedded in the SSL x509 client certificate or any other token.</li>
<li>Be aware that each instance of every component (e.g. kubelet, scheduler, etcd) in a typical Kubernetes deployment has its own SSL x509 client certificate, which it uses to authenticate when communicating with other components.  See this <a href="https://kubernetes.io/docs/concepts/cluster-administration/certificates/" rel="nofollow noreferrer">link</a></li>
</ul>

<p>Kubernetes <strong>Authorization</strong></p>

<ul>
<li>In Kubernetes, RBAC <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings" rel="nofollow noreferrer">roles and rolebindings</a> determine exactly what kube-apiserver REST endpoints a particular user may access, and what <code>verb</code> operations are allowed (e.g. "get", "list", "watch", "create", "update", "patch", "delete"). </li>
<li>One may create a <code>role</code> which is a set of permissions that define access to kube-apiserver REST endpoints.</li>
<li>One may then create a <code>rolebinding</code> which binds a user id or a group id to a specific <code>role</code>.</li>
<li>Please note there are both cluster-wide and namespace-wide rolebindings available.</li>
<li>Here's an example:</li>
</ul>

<pre><code>
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: role-grantor
    rules:
    - apiGroups: ["rbac.authorization.k8s.io"]
      resources: ["rolebindings"]
      verbs: ["create"]
    - apiGroups: ["rbac.authorization.k8s.io"]
      resources: ["clusterroles"]
      verbs: ["bind"]
      resourceNames: ["admin","edit","view"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: role-grantor-binding
      namespace: user-1-namespace
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: role-grantor
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: user-1
</code></pre>

<ul>
<li>RBAC is only one possible authorization mechanism.  Kubernetes <a href="https://kubernetes.io/docs/reference/access-authn-authz/abac/" rel="nofollow noreferrer">ABAC</a> is less popular.</li>
</ul>

<p><strong>Checking if you have RBAC enabled</strong></p>

<p>Simply verify the kube-apiserver startup options.  If kube-apiserver is running as a pod, you can check it like this:</p>

<pre><code>$ kubectl get po kube-apiserver-ubuntu-18 -n kube-system -o name |grep api
pod/kube-apiserver-ubuntu-18

$ kubectl get po kube-apiserver-ubuntu-18 -n kube-system  -o yaml
# THEN SEARCH FOR RBAC
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=Node,RBAC
</code></pre>
