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:

Raylenerayless

Answer 1

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.

Serrated

Answer 2

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:

Mccandless

But system:kube-scheduler is not a group, it is a user as its kind is User. If you will try the same thing on system:masters you will see that they have kind of Group and I want to know what are the users inside it, in my case, system:masters. – Raylenerayless

But it still doesn't show who are the users inside the group system:masters. When you list the names only, it will show you the of the ClusterRoleBindings, not the names of the users. Basically your command is searching for ClusterRoleBinding with group named system:masters but you won't see the members of system:masters inside the ClusterRoleBinding cluster-admin. – Raylenerayless

It seems that you have no other ways in Kubernetes to do it. 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. kubernetes.io/docs/reference/access-authn-authz/rbac kubernetes.io/docs/reference/access-authn-authz/authentication – Mccandless

As @Mccandless stated those commands show the names of the ClusterRoleBinding not the names of users. – Brainstorming

I've put all important information from the discussion to the answer. – Mccandless

Answer 3

In EKS the system:masters group is mapped to IAM roles in the aws-auth ConfigMap

kubectl get cm -n kube-system aws-auth -oyaml | yq '.data.mapRoles' | yq -P

Sputnik

Answer 4

Take a look at this line of code in the apiserver source code:

return &authenticator.Response{
        User: &user.DefaultInfo{
            Name:   chain[0].Subject.CommonName,
            Groups: chain[0].Subject.Organization,
        },

When a user authenticates, the code fills an authenticator.Response as such:

1. The name of the user is whatever the common name of the first certificate in the chain specifies (in your case kube-apiserver-kubelet-client)
2. The group of the user is whatever organization of the first certificate in the chain specifies (in you case system:masters)

So, you can be sure that the user authenticated with the certificate you decoded belongs to the group system:masters.

Cartage