Already provided answers are correct and you cannot revoke certificates at the moment of writing this answer.
Somebody already mentioned using serviceaccount tokens and assigning RBAC Roles to users and not groups and I just want to add some details on why this approach works.
Let's start with some theory. The process of user verifiction consists of:
authentication - process of verifying who a user is. In your case client certificate is used, but other methods like bearer tokens, authentication proxy can also serve the very purpose.
When using certificates, user is defined by a certificate itself. Whoever holds the certificate can act as a user.
authorization - process of verifying what a user have access to. In case of kubernetes it is done using RBAC roles.
Rolebinding is used to add specific permissions (represented by an rbac role) to a user or group (represented by a certificate).
We know now that you can't make changes on authentication level, since signed certificate cannot be revoked.
You can although make changes on authorization level that is done by removing permissions from a user (by either removing rolebinding, or removing/altering rbac role; be carefull, the same RBAC Role can be assigned to different user/groups).
This approach, even though it's correct, can lead to some security issues that are worth to mention.
When signing certificates for new users you need to remember to never sing certificates with the same username. Once permissions are revoked you shoud not use the same username for new certificates and associated rolebinding (at least until the old cert expires) to make sure the old one when used, won't be allowed to access a cluster.
Alternatively I would like to suggest you another solution to already proposed ones: OpenID Connect Tokens
Although Kubernetes does not provide an OpenID Connect Identity Provider. You can use an existing public OpenID Connect Identity Provider (such as Google). Or, you can run your own Identity Provider, such as dex or Keycloak
OpenId tokens are very short lived tokens (e.g. 1 minute) and once your id_token expires, kubectl will attempt to refresh your id_token using your refresh_token and client_secret storing the new values for the refresh_token and id_token in your .kube/config.
Even if this solution is more complicated to configure, it is worth to consider when having a lot of users to manage.
Additionally, integrations with other authentication protocols (LDAP, SAML, Kerberos, alternate x509 schemes, etc) can be accomplished using an authenticating proxy or the authentication webhook
