Managing User Access

In Kubernetes clusters, access control is handled natively by Kubernetes itself. The kubeconfig file you download from the control panel contains administrative credentials and is suitable for initial cluster setup.

If multiple team members need access to the same cluster, sharing a single admin kubeconfig is not a good practice. If that file is leaked or stays with a former employee, there is no way to revoke access for just that one person. The safer approach is to create a separate account for each user and grant the necessary permissions through RBAC.

This guide covers how to set up per-user access using a ServiceAccount, a RoleBinding or ClusterRoleBinding, and a dedicated kubeconfig with a token.

Prerequisites

You will need a running Kubernetes cluster, the admin kubeconfig downloaded from the control panel, and kubectl installed.

To download the kubeconfig, go to the Kubernetes cluster management page in the control panel. On the Dashboard tab, click the "download configuration file" link. The downloaded file will be named twc-cluster_name.yaml.

Verify connectivity to the cluster:

kubectl --kubeconfig=twc-cluster_name.yaml get nodes

If the command returns a list of nodes, you are ready to create user accounts.

Create a Namespace for User Accounts

It is convenient to manage all user accounts in a dedicated namespace, for example kube-users:

kubectl create namespace kube-users

We will create a ServiceAccount for the user newuser:

kubectl create serviceaccount newuser -n kube-users

This account name will be used when assigning permissions and generating tokens.

Grant Permissions

Permissions in Kubernetes are managed through RBAC using two resource types:

• RoleBinding grants permissions within a single namespace
• ClusterRoleBinding grants permissions across the entire cluster

Always follow the principle of least privilege. If a user only needs access to one namespace, use a RoleBinding rather than a ClusterRoleBinding.

Access to a Single Namespace

To restrict a user to a single namespace, create a RoleBinding in that namespace. The example below grants newuser edit permissions in the app-prod namespace:

kubectl create namespace app-prod
 
kubectl create rolebinding newuser-app-prod-edit \
  --namespace app-prod \
  --clusterrole edit \
  --serviceaccount kube-users:newuser

You can replace edit with any other built-in role:

These are the standard Kubernetes ClusterRoles. If none of them fit your requirements, you can create custom ClusterRoles with specific rules.

To verify that permissions were applied correctly:

kubectl auth can-i create deployments \
  --as system:serviceaccount:kube-users:newuser \
  -n app-prod

If access is configured correctly, the command returns:

yes

Access to the Entire Cluster

If a user needs full administrative access to the cluster, create a ClusterRoleBinding:

kubectl create clusterrolebinding newuser-cluster-admin \
  --clusterrole cluster-admin \
  --serviceaccount kube-users:newuser

Only assign the cluster-admin role to cluster administrators. For development teams, namespace-scoped access is a safer default.

Create a Token

Users need a token to connect with kubectl. Kubernetes supports two token types: short-lived tokens and long-lived tokens stored in a Secret.

Short-Lived Token

Create a short-lived token using kubectl create token. The example below generates a token valid for 24 hours:

TOKEN=$(kubectl create token newuser -n kube-users --duration=24h)

View the token value:

echo "${TOKEN}"

The token will stop working automatically after the expiry time.

Short-lived tokens do not create any object in the cluster, so there is no way to revoke a specific token before it expires. If you need to cut off access immediately, delete the user's permissions or the ServiceAccount itself.

Long-Lived Token

If you need a token without an expiry, create a Secret of type kubernetes.io/service-account-token. You can revoke this token at any time by deleting the Secret.

Create a file named newuser-token-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: newuser-token
  namespace: kube-users
  annotations:
    kubernetes.io/service-account.name: newuser
type: kubernetes.io/service-account-token

Apply the manifest:

kubectl apply -f newuser-token-secret.yaml

Retrieve the token value:

TOKEN=$(kubectl get secret newuser-token \
  -n kube-users \
  -o jsonpath='{.data.token}' | base64 -d)

Only use long-lived tokens where short-lived tokens are not practical. Treat them as sensitive credentials and store them accordingly.

Create a kubeconfig for the User

Create a separate kubeconfig file that contains the cluster connection details and the newuser token.

First, retrieve the cluster parameters from the admin kubeconfig:

CLUSTER_NAME=$(kubectl config view --minify -o jsonpath='{.clusters[0].name}')
CLUSTER_SERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
kubectl config view --raw --minify -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d > ca.crt

Create the new configuration file:

kubectl config --kubeconfig=newuser.kubeconfig set-cluster "${CLUSTER_NAME}" \
  --server="${CLUSTER_SERVER}" \
  --certificate-authority=ca.crt \
  --embed-certs=true
 
kubectl config --kubeconfig=newuser.kubeconfig set-credentials newuser \
  --token="${TOKEN}"
 
kubectl config --kubeconfig=newuser.kubeconfig set-context newuser-context \
  --cluster="${CLUSTER_NAME}" \
  --user=newuser
 
kubectl config --kubeconfig=newuser.kubeconfig use-context newuser-context

If the user should work in a specific namespace by default, add it to the context:

kubectl config --kubeconfig=newuser.kubeconfig set-context newuser-context \
  --cluster="${CLUSTER_NAME}" \
  --user=newuser \
  --namespace=app-prod

Once the file is ready, you can hand newuser.kubeconfig over to the user.

Example kubeconfig

Below is an example of a user kubeconfig using token-based authentication. The values for certificate-authority-data, server, and token will be different in your cluster.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <CA_DATA>
    server: https://<API_SERVER>:6443
  name: twc-example-cluster
contexts:
- context:
    cluster: twc-example-cluster
    namespace: app-prod
    user: newuser
  name: newuser-context
current-context: newuser-context
kind: Config
preferences: {}
users:
- name: newuser
  user:
    token: <TOKEN>

The final file must not contain the admin user, client certificate, or private key from the original kubeconfig. Before sharing the file, verify that the users section contains only the user's token-based account.

Verify Access

Test the new kubeconfig:

kubectl --kubeconfig=newuser.kubeconfig get pods -n app-prod

If the user only has access to the app-prod namespace, requests to other namespaces will be denied:

kubectl --kubeconfig=newuser.kubeconfig get pods -n default

Kubernetes will return an access error:

Error from server (Forbidden): pods is forbidden

To check whether a specific action is permitted, use kubectl auth can-i:

kubectl --kubeconfig=newuser.kubeconfig auth can-i update deployments -n app-prod

Revoke Access

How you revoke access depends on what you need to disable.

Remove Namespace Permissions

To prevent a user from performing actions in a namespace, delete the corresponding RoleBinding:

kubectl delete rolebinding newuser-app-prod-edit -n app-prod

If the user was granted cluster-wide access, delete the ClusterRoleBinding:

kubectl delete clusterrolebinding newuser-cluster-admin

After the binding is deleted, the token may remain technically valid, but the user will no longer have permission to perform any actions.

Revoke a Long-Lived Token

If the token was created via a Secret, delete that Secret:

kubectl delete secret newuser-token -n kube-users

Once the Secret is deleted, the token will no longer authenticate.

Delete the Account Entirely

To fully remove a user, delete their ServiceAccount:

kubectl delete serviceaccount newuser -n kube-users

When a ServiceAccount is deleted, all tokens issued for it stop working. Revocation may not be instantaneous, as Kubernetes can cache token validation results for a short period.

After deleting the account, also remove any associated RoleBindings and ClusterRoleBindings if they are no longer needed.