DigitalOcean Kubernetes (DOKS) is a managed Kubernetes service. Deploy Kubernetes clusters with a fully managed control plane, high availability, autoscaling, and native integration with DigitalOcean Load Balancers and volumes. You can add node pools using shared and dedicated CPUs, and NVIDIA H100 GPUs in a single GPU or 8 GPU configuration. DOKS clusters are compatible with standard Kubernetes toolchains and the DigitalOcean API and CLI.
Access to resources within DigitalOcean Kubernetes clusters is controlled by role-based access control (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.
The following RBAC rules for predefined team roles 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. |
When you create a custom role within a team, 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:
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
.> kubectl auth whoami
Authentication responses contain information about the user's identity and the groups they belong to, for example:
ATTRIBUTE VALUE
Username [email protected]
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.
view
, edit
, admin
, or cluster-admin
.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
name
of the Role or ClusterRole, and the group or a username returned in the authentication response as the name
of the subject:
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: [email protected]
Use kubectl apply
to apply the updated role bindings.