Skip to main content

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.

  • 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.

For clarity, this guide refers to the downloaded Kubeconfig file as rbac-kubeconfig.

Example
$
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.
Example
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.

Example
$
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.
Example
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.

Example
$
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.

Example
$
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.

Example
$
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.

Example
$
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.

Note

To learn more about RBAC access tokens, see the following resources:

Last updated on