<p>There is a default <code>ClusterRoleBinding</code> named <code>cluster-admin</code>.<br>
When I run <code>kubectl get clusterrolebindings cluster-admin -o yaml</code> I get:  </p>

<pre><code>apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: 2018-06-13T12:19:26Z
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "98"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin
  uid: 0361e9f2-6f04-11e8-b5dd-000c2904e34b
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>In the <code>subjects</code> field I have:  </p>

<pre><code>- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters
</code></pre>

<p>How can I see the members of the group <code>system:masters</code> ?<br>
I read <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-subjects" rel="noreferrer">here</a> about groups but I don't understand how can I see who is inside the groups as the example above with <code>system:masters</code>.  </p>

<p>I noticed that when I decoded <code>/etc/kubernetes/pki/apiserver-kubelet-client.crt</code> using the command: <code>
openssl x509 -in apiserver-kubelet-client.crt -text -noout</code> it contained the subject <code>system:masters</code> but I still didn't understand who are the users in this group:  </p>

<pre><code>Issuer: CN=kubernetes
Validity
    Not Before: Jul 31 19:08:36 2018 GMT
    Not After : Jul 31 19:08:37 2019 GMT
Subject: O=system:masters, CN=kube-apiserver-kubelet-client
Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
        Public-Key: (2048 bit)
        Modulus:
</code></pre>

E235
<p>Admittedly, late to the party here.</p>

<p>Have a read through <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/" rel="noreferrer">the Kubernetes 'Authenticating' docs</a>. Kubernetes does not have an in-built mechanism for defining and controlling users (as distinct from ServiceAccounts which are used to provide a cluster identity for Pods, and therefore services running on them).</p>

<p>This means that Kubernetes does not therefore have any internal DB to reference, to determine and display group membership.</p>

<p>In smaller clusters, x509 certificates are typically used to authenticate users. The API server is configured to trust a CA for the purpose, and then users are issued certificates signed by that CA. As you had noticed, if the subject contains an 'Organisation' field, that is mapped to a Kubernetes group. If you want a user to be a member of more than one group, then you specify multiple 'O' fields. (As an aside, to my mind it would have made more sense to use the 'OU' field, but that is not the case)</p>

<p>In answer to your question, it appears that in the case of a cluster where users are authenticated by certificates, your only route is to have access to the issued certs, and to check for the presence of the 'O' field in the subject. I guess in more advanced cases, Kubernetes would be integrated with a centralised tool such as AD, which could be queried natively for group membership.</p>
