CoreWeave
Search
K

Custom RBAC Access Tokens

Create fine-grained permissions to Namespaces with Roles and RoleBindings
As explained in Manage API Access Tokens, Org Admins usually assign Namespaces to Kubeconfig access tokens.
However, for more flexibility, they can also use role-based access control (RBAC) in CoreWeave Cloud. To do so, the Org Admin creates the access token without any namespace assignment, and then uses a RoleBinding to assign it a Role.

About Roles and RoleBindings

This diagram illustrates the relationship between a Role, a RoleBinding, an Access Token, and a Namespace.
Relationship of Role, RoleBinding, Access Token, and Namespace
Relationship of Role, RoleBinding, Access Token, and Namespace
  • An Access Token, usually stored in a Kubeconfig, is the credential that identifies the user.
  • An Role defines a set of permissions in a namespace.
  • A RoleBinding connects the Access Token and the Role to grant access in the Namespace.
This is a simplified description. Roles and RoleBindings are also used for other Kubernetes subjects.

Prerequisites

To complete this guide, the Org Admin must configure a Kubeconfig and set the desired namespace in the current context. All the commands below run in this default configuration, unless overridden with command-line parameters to illustrate RBAC access.

Get started

The first step is to create a new access token without any namespace assignments. Follow the same steps described in Manage API Access Tokens, but do not assign any namespaces. This is the key to creating an RBAC token.
Create a new token with no namespace assignment
Create a new token with no namespace assignment
For clarity, this guide refers to the downloaded Kubeconfig file as rbac-kubeconfig.
$ mv cw-kubeconfig rbac-kubeconfig

Create a Role

Next, create a Role that can read Pods, but cannot deploy new Pods or read any other resources, such as Secrets.
  • Paste the code below into pod-reader.yaml.
  • Change my-namespace to the desired namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: my-namespace # The desired namespace
name: pod-reader # The Role name, which must match in the RoleBinding
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
Create the Role in the Namespace, using the Org Admin's Kubeconfig.
$ kubectl apply -f pod-reader.yaml
role.rbac.authorization.k8s.io/pod-reader created

Create a RoleBinding

Finally, create a RoleBinding that connects the access token to the Role.
  • Paste the code below into pod-reader-rolebinding.yaml.
  • Change my-namespace to the same namespace in the Role.
  • Change my-user to the name found in rbac-kubeconfig, downloaded earlier.
apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows a user to read pods in the namespace.
# You need to already have created a Role named "pod-reader" in the namespace.
kind: RoleBinding
metadata:
name: pod-reader-rolebinding
namespace: my-namespace # change this to the desired namespace
subjects:
# You can specify more than one "subject"
- kind: User
name: my-user # Change this to the case-sensitive user name found in Kubeconfig
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader # The Role name, defined in the Role
apiGroup: rbac.authorization.k8s.io
Apply the RoleBinding to the Namespace, using the Org Admin's Kubeconfig.
$ kubectl apply -f pod-reader-rolebinding.yaml
rolebinding.rbac.authorization.k8s.io/pod-reader-rolebinding created

Test the access token

Test the RBAC access token to verify that get pods is allowed.
$ kubectl get pods --kubeconfig rbac-kubeconfig --namespace my-namespace
  • --kubeconfig overrides the Org Admin's configuration.
  • --namespace must be declared because rbac-kubeconfig has no Namespace assigned.
If successful, the result should be similar to this, assuming that Pods are deployed in the Namespace.
$ kubectl get pods --kubeconfig rbac-kubeconfig --namespace my-namespace
NAME READY STATUS RESTARTS AGE
example1-123456-abcd 1/1 Running 0 12d
example2-123456-abcd 1/1 Running 0 50d
example3-123456-abcd 1/1 Running 1 75d
Test to make sure get secrets is forbidden.
$ kubectl get secrets --kubeconfig rbac-kubeconfig --namespace my-namespace
Error from server (Forbidden): secrets is forbidden: User "my-user" cannot list resource "secrets" in API group "" in the namespace "my-namespace"
If these tests pass, the RBAC access token is configured properly. Further modification is possible by modifying or creating new Roles, and then changing the RoleBinding as desired. To learn more about the options available for Roles and RoleBindings with RBAC, see these resources at kubernetes.io and cncf.io.