Namespaces allow dividing a Kubernetes cluster on logical segments with an isolated set of resources. This mechanism enables creation of multi-tenant environments within one cluster, enabling multiple teams to use one infrastructure. At the same time it raises the problem of granular access to cluster resources.


In this article I will demonstrate how to grant user access to a specific namespace by using an authorization token and define their permissions with the Role-Based Access Control (RBAC) policies.

Granting user access with token

To create a user within a Kubernetes namespace and grant them access to specific resources, you begin by creating a ServiceAccount in your desired namespace. This ServiceAccount acts as the “user” for your applications or services running in Kubernetes. Next, define a ClusterRole that specifies the permissions you want to grant, such as access to pods, services, and other resources. Although cluster roles are cluster-wide, you can scope the permissions to a specific namespace by creating a RoleBinding within that namespace, linking the ClusterRole to your ServiceAccount. This setup ensures that the ServiceAccount has the necessary permissions only in the designated namespace, effectively creating a namespace-scoped user with access to particular resources.

Diagram of granting user access with token

Step 1: Define a ClusterRole

Define a ClusterRole with the permissions you want to grant. This cluster role does not specify namespaces because it’s designed to be applicable cluster-wide.

kind: ClusterRole
  name: kube-dc-user-clusterrole
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets", "statefulsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["datavolumes"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["virtualmachineinstances", "virtualmachines"]
  verbs: ["get", "list", "watch"]

Step 2: Create a ServiceAccount

Users should be kept in permanent namespace users, and access would be granted for particular namespace by setting RoleBinding in particular namespace:

apiVersion: v1
kind: Namespace
  name: users

apiVersion: v1
kind: ServiceAccount
  name: kube-dc-user
  namespace: users


Also a secret token should be created:

apiVersion: v1
kind: Secret
  name: kube-dc-user-token
  namespace: users
  annotations: "kube-dc-user"

Step 3: Create RoleBindings in Specific Namespaces

kind: RoleBinding
  name: kube-dc-user-clusterrole-binding
  namespace: demo
- kind: ServiceAccount
  name: kube-dc-user
  namespace: users
  kind: ClusterRole
  name: kube-dc-user-clusterrole

Step 4: Retrieve the ServiceAccount Token

Created token name is with the suffix -token added to existing user:

# Get the token for the user
kubectl get secret kube-dc-user-token -n users -o=jsonpath='{.data.token}' | base64 --decode

Using curl to Query the API

Here’s an example using curl to query virtual machines in a specific namespace:

SA_TOKEN=$(kubectl get secret kube-dc-user-token -n users -o=jsonpath='{.data.token}' | base64 --decode)
curl -k -H "Authorization: Bearer $SA_TOKEN" \

Create a kubeconfig from token

If you’re using kubectl on your local machine, you can temporarily set the KUBECONFIG environment variable or modify your kubeconfig file to use the Service Account token. This approach is useful for manual inspections or when scripting interactions with Kubernetes.


First, create a new kubeconfig file or modify an existing one to include the Service Account token. Here’s a basic example of how to set up a context that uses the Service Account token.


Get the API server address:

APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')

Get the CA certificate (if needed):

kubectl get secret <service-account-secret-name> -n <namespace> -o jsonpath='{\.crt}' | base64 --decode > ca.crt


Replace <service-account-secret-name> and <namespace> with the actual secret name and namespace.


Create a kubeconfig file.


Here’s an example of adding a new user, context, and cluster in your kubeconfig. You might want to add this to an existing kubeconfig file or create a new one specifically for this purpose.

apiVersion: v1
kind: Config
- name: my-cluster
    certificate-authority: /path/to/ca.crt  # Adjust the path as needed
    server: https://<api-server-address>    # Use the APISERVER variable
- name: kube-dc-user
    token: <your-service-account-token>
- name: kube-dc-user@my-cluster
    cluster: my-cluster
    namespace: <namespace>  # Specify the namespace if desired
    user: kube-dc-user
current-context: kube-dc-user@my-cluster

Replace <api-server-address>, <your-service-account-token>, and <namespace> with your actual API server address, the token you retrieved, and the namespace you want to use.


The RBAC policies and authorization via tokens are critical features of Kubernetes cluster security that allow you to control who can do what in each namespace. Following the steps described in this article will help you define user permissions within a certain namespace granting granular user access to cluster resources.