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.

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

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.

note

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