Short Answer:

Create a RoleBinding or a ClusterRoleBinding (depending on your needs) where the subjects: include an object of kind: User and name: username:

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cluster-admin-users
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: starseed

Explanation:

This explanation assumes you are talking about a cluster with RBAC enabled, which should pretty much always be the case if you're on a recent version.

It's easy to be confused by this topic. Users and Groups exist only within the context of RoleBindings and ClusterRoleBindings as "subjects" as seen above.

The above code is a YAML object on which you could perform kubectl apply -f thisfile.yml. It would create a CluserRoleBinding which would bind the "user" (which is really just a string) starseed to the ClusterRole called "cluster-admin". "cluster-admin" is one of the default ClusterRoles. ClusterRoles (and Roles) are collections of API permissions, as described here: https://kubernetes.io/docs/admin/authorization/rbac/#default-roles-and-role-bindings

There is no creation or deletion of users or groups - there are no API objects for a user or a group, and there is no way to list all users or all groups.

To understand why this is, there's a fundamental concept that you must wrap your head around - authentication and authorisation are completely separate concerns in kubernetes. Authentication deals with verifying "this user is who they say they are". As described here: https://kubernetes.io/docs/admin/authentication/ - there are many valid methods of authentication. Common ones include tokens, username/password, x509 client certificates, but there are more. If a user presents a username and password that's present in the kube-apiserver's --basic-auth=somefile.csv flag, the kube-apiserver knows you're that user. If you use an x509 client certificate where the CommonName=starseed, and that cert is signed by a CA that kube-apiserver trusts, it knows you are that user.

At that point, when you try to make an API call like kubectl get pods, the kube-apiserver checks which authorisation methods are enabled (Node,RBAC is common). It'll find that the subject of a ClusterRoleBinding called cluster-admin-users is the user "starseed" and that therefore starseed can do anything the associated ClusterRole allows.

To connect to Kubernetes cluster in GCP, you can use either user or service account.

If you choose user account, run this command:

gcloud init 

or

gcloud init --console-only

This will bring up GCP authentication dialog. When you pass authentication, you'll be able to operate with permission of the authenticated user.

If you choose service account, you need to create it and generate a new key for it.

You can do it using GPC console -> IAM & admin -> IAM -> Service accounts.
Click on Create service account, select name for the account, select the appropriate role, and click Create.
You can generate the key by selecting Furnish a new private key in the account creation dialog box, or generate a new key by clicking on three dots on the right side of existed service account row and selecting Create key. Select JSON format and save the file on disk.

Then run the command:

gcloud auth activate-service-account <service@account.name>  --key-file=<previously_saved_file.json>

At this stage, you are authenticated with CGP and ready to connect to your Kubernetes cluster:

Next command will update your kubectl configuration to work with your cluster.

gcloud container clusters get-credentials <cluster_name> --zone <gcp_availability_zone> --project <gcp_project_name>

You can extend or decrease the account's permissions by selecting another role for it in GCP IAM management interface.

Official documentation:
gcloud auth activate-service-account
gcloud init
gcloud container clusters get-credentials