How to view members of subject with Group kind

Question

There is a default ClusterRoleBinding named cluster-admin.
When I run kubectl get clusterrolebindings cluster-admin -o yaml I get:

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

In the subjects field I have:

- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

How can I see the members of the group system:masters ?
I read here about groups but I don't understand how can I see who is inside the groups as the example above with system:masters.

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

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:

Answer 1

Answer updated:

It seems that there is no way to do it using kubectl. There is no object like Group that you can "get" inside the Kubernetes configuration.

Group information in Kubernetes is currently provided by the Authenticator modules and usually it's just string in the user property.

Perhaps you can get the list of group from the subject of user certificate or if you use GKE, EKS or AKS the group attribute is stored in a cloud user management system.

https://kubernetes.io/docs/reference/access-authn-authz/rbac/ https://kubernetes.io/docs/reference/access-authn-authz/authentication/

Information about ClusterRole membership in system groups can be requested from ClusterRoleBinding objects. (for example for "system:masters" it shows only cluster-admin ClusterRole):

Using jq:

kubectl get clusterrolebindings -o json | jq -r '.items[] | select(.subjects[0].kind=="Group") | select(.subjects[0].name=="system:masters")'

If you want to list the names only:

kubectl get clusterrolebindings -o json | jq -r '.items[] | select(.subjects[0].kind=="Group") | select(.subjects[0].name=="system:masters") | .metadata.name'

Using go-templates:

kubectl get clusterrolebindings -o go-template='{{range .items}}{{range .subjects}}{{.kind}}-{{.name}} {{end}} {{" - "}} {{.metadata.name}} {{"\n"}}{{end}}' | grep "^Group-system:masters"

Some additional information about system groups can be found in GitHub issue #44418 or in RBAC document:

Answer 2

Admittedly, late to the party here.

Have a read through the Kubernetes 'Authenticating' docs. 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).

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

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)

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.