How to list groups

[alleb]

While doing the DO280 course one of the guided labs has us remove the self-provisioners cluster role from the system:authenticated:oauth virtual group and then later add it back.

Is there a way to find these system groups with the oc command?  oc get group doesn't list them, and oc adm groups doesn't have a list option.

I'm not sure if I'm missing something or if this type of group is something that you can only know about through documentation?

[Natalie_Lind · Accepted solution]

These "groups" are a part of cluster roles and cluster role bindings. As a cluster admin, you can retrieve a list of cluster roles with the oc get clusterrole command. To retrieve only the "system:" cluster roles, you can use the oc get clusterrole | grep system: command.

If you want to view the cluster role bindings (the service accounts that are linked to the cluster roles), you can use the oc get clusterrolebindings command.

Finally, for a list of all cluster role bindings that contain "system:authenticated", you can output the oc get clusterolebindings command to JSON and then parse with JQ. More specifically, the oc get clusterrolebindings -o json | jq '.items[] | select(.subjects[].name | startswith("system:authenticated"))' command will return all cluster role bindings where the subject (or service account) contains "system:authenticated".

[flozano · Accepted solution]

Unfortunately there's no way of listing all groups (nor all users) in Kubernetes. "Subjects", be they users, groups, or something else, are not managed by standard Kubernetes APIs and are just string fields in many resources. It is up to the controllers enabled in your cluster how to interpret these strings and up to external authentication and authorization plugins how to define "valid" subjects and how they map to each other, for example which groups a user is member of.

OpenShift includes an OAuth server and the group, user, and identity resources that exist in OpenShift relate to that internal OAuth server and are not standard Kubernetes resource. You might not be using any of them, for example if your cluster is configured to delegate authentication to an external OIDC server.

Natalie shows an indirect way of getting such lists of users and groups, by finding the string values in other resources. As a Kubernetes administrator, you can assign whatever string value to the attributes of these resources. If no controller understand that string, it'll be just ignored so you could easy create a role binding that grants no one any permission because no one is mapped to these strings. Kubernetes would not know you're referencing a non-existent user or group.

Some users and groups with the 'system:" prefix are hard-coded in Kubernetes, that is, by the standard set of controllers that you get with Kubernetes. You can see partials listing of them scattered around the Kubernetes documentation, for example:

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-subjects

Some roles and rolebindings are also hardcoded in Kubernetes and extension controllers, so just listing all clusterrolebindings and project-scoped rolebindins will not give you the complete picture of what a user (or app service account) can do and cannot do.

If can list what you can do, at a somewhat low level, using the command:

$ kubectl auth can-i --list

And of course you could use "oc" in place of "kubectl" above.