See "Comparing Kubernetes Authentication Methods" by Etienne Dilocker

A possible solution is the x509 client certs:

Advantages

operating the Kubernetes cluster and issuing user certificates is decoupled much more secure than basic authentication

Disadvantages

x509 certificates tend to have a very long lifetime (months or years). So, revoking user access is nearly impossible. If we instead choose to issue short-lived certificates, the user experience drops, because replacing certificates involves some effort.

But Etienne recommends OpenID:

Wouldn’t it be great if we could have short-lived certificates or tokens, that are issued by a third-party, so there is no coupling to the operators of the K8s cluster.
And at the same time all of this should be integrated with existing enterprise infrastructure, such as LDAP or Active Directory.

This is where OpenID Connect (OIDC) comes in.

For my example, I’ve used Keycloak as a token issuer. Keycloak is both a token issuer and an identity provider out-of-the box and quite easy to spin up using Docker.

To use RBAC with that kind of authentication is not straight-forward, but possible.
See "issue 118; Security, auth and logging in"

With 1.3 I have SSO into the dashboard working great with a reverse proxy and OIDC/OAuth2. I wouldn't create an explicit login screen, piggy back off of the RBAC model and the Auth model that is already supported. It would be great to have something that says who the logged in user is though.

Note that since 1.3, there might be simpler solution.

The same thread includes:

I have a prototype image working that will do what I think you're looking for: https://hub.docker.com/r/mlbiam/openunison-k8s-dashboard/

I removed all the requirements for user provisioning and stripped it down to just:

• reverse proxy
• integration with openid connect
• display the user's access token
• simple links page

It includes the role binding:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
  name: admin-role
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
  nonResourceURLs: ["*"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
  name: admin-binding
subjects:
- kind: Group
  name: admin
- kind: ServiceAccount
  name: default
  namespace: kube-system
- kind: ServiceAccount
  name: openunison
  namespace: default
roleRef:
  kind: ClusterRole
  name: admin-role

Again, this was specific to the dashboard RBAC access, and has since been improved with PR 2206 Add log in mechanism (to dashboard).

It still can give you some clues in order to link a regular user to kubernetes RBAC.