# How to Set RoleBindings for Custom Roles

DigitalOcean Kubernetes (DOKS) is a Kubernetes service with a fully managed control plane, high availability, and autoscaling. DOKS integrates with standard Kubernetes toolchains and DigitalOcean’s load balancers, volumes, CPU and GPU Droplets, API, and CLI.

Access to resources within DigitalOcean Kubernetes clusters is controlled by [role-based access control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). RBAC defines bindings between roles (allowed actions) and subjects (groups, individual users, or service accounts). At DigitalOcean, roles assigned to users within teams translate to Kubernetes groups, and, therefore, determine the level of access within Kubernetes clusters.

## Predefined Roles Access

The following RBAC rules for [predefined team roles](https://docs.digitalocean.com/platform/teams/roles/predefined/index.html.md) are configured automatically:

| Role | Access level |
|---|---|
| Owner | `cluster-admin` |
| Member | `cluster-admin` |
| Modifier | Create, read, and update most resources, but not delete them. Cannot modify RoleBindings. |
| Biller | View resources, except secrets. |
| Billing Viewer | View resources, except secrets. |
| Resource Viewer | View resources, except secrets. |

**Warning**: Do not modify these rules and the corresponding RoleBindings. The reconciler may automatically revert such changes at any time.

## Custom Roles Access

When you [create a custom role within a team](https://cloud.digitalocean.com/account/access), the new role does not automatically bind to any Kubernetes role. This prevents users assigned to the new role from managing resources inside Kubernetes clusters.

To let users with the new role access cluster resources, a user with the owner role in the team should follow these steps:

1. Ensure that the custom role includes the `kubernetes:access_cluster` permission. This allows users with that role to download kubeconfig files and authenticate against kube-apiservers.

   With the kubeconfig downloaded, users can verify their ability to authenticate by running `kubectl auth whoami`:

   ```
   Authentication responses contain information about the user's identity and the groups they belong to, for example:

   ATTRIBUTE   VALUE
   Username    alice@mycompany.com
   ID          b4fa03bd-df61-4d36-a734-8f27f7fedd94
   Groups      [do-role-name:custom-kubernetes-reader k8saas:default]
   ```

   The groups associated with a custom role have the format `do-role-name:<role-name>`. Regardless of the user’s role in the team, the `k8saas:default` group is assigned to every user who is a member of the team that owns the cluster.
2. Optionally, create a Kubernetes [Role or ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) with the Kubernetes permissions you would like the custom role to provide. Alternatively, you can use a built-in ClusterRole, such as `view`, `edit`, `admin`, or `cluster-admin`.

   ```yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: pod-reader
   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "watch", "list"]
   ```
3. Create a [RoleBinding or ClusterRoleBinding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) for the selected Role or ClusterRole. Specify the `name` of the Role or ClusterRole, and the group or a username returned in the authentication response as the `name` of the subject:

   ```yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: custom-pod-reader
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: pod-reader
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: do-role-name:custom-kubernetes-reader
   - apiGroup: rbac.authorization.k8s.io
     kind: User
     name: alice@mycompany.com
   ```

   Use `kubectl apply` to apply the updated role bindings.