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.
