---
title: "Kubernetes User Access Management | Hostman Docs"
description: "Set up secure Kubernetes access for individual users using RBAC. Learn how to create ServiceAccounts, assign roles, generate tokens, build kubeconfig files, and properly revoke access when needed."
---

> For the complete documentation index for AI agents, see [llms.txt](https://hostman.com/llms.txt).

In Kubernetes clusters, access control is handled natively by Kubernetes itself. The `kubeconfig` file you download from the dashboard 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 dashboard, and [kubectl](https://hostman.com/docs/kubernetes/connect-to-clusters/kubectl/) installed.

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

![Charming Grosbeak 05 22 2026 01 28 Pm](https://content.hostman.com/assets/cf290d1b-0319-4c92-b9a1-c0bf2d1fbdd4.png?width=1557&height=863)

Verify connectivity to the cluster:

```shell
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`:

```shell
kubectl create namespace kube-users
```

We will create a `ServiceAccount` for the user `newuser`:

```shell
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:

```shell
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:

| **Role** | **Description** |
| --- | --- |
| `view` | Read-only access to resources in the namespace. |
| `edit` | Create and modify most resources in the namespace. |
| `admin` | Full management of namespace resources, including roles and role bindings. |
| `cluster-admin` | Full administrative access to the entire cluster. |

These are the standard Kubernetes `ClusterRoles`. If none of them fit your requirements, you can [create custom ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#kubectl-create-clusterrole) with specific rules.

To verify that permissions were applied correctly:

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

If access is configured correctly, the command returns:

```shell
yes
```

### Access to the Entire Cluster

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

```shell
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:

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

View the token value:

```shell
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`:

```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:

```shell
kubectl apply -f newuser-token-secret.yaml
```

Retrieve the token value:

```shell
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`:

```shell
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:

```shell
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:

```shell
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.

```yaml
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`:

```shell
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:

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

Kubernetes will return an access error:

```shell
Error from server (Forbidden): pods is forbidden
```

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

```shell
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`:

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

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

```shell
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:

```shell
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`:

```shell
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.