> For the complete documentation index, see [llms.txt](https://docs.cloudeka.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cloudeka.ai/reference/kubernetes-user-creation-with-rbac/grant-a-built-in-rbac-role.md).

# Grant a Built-In RBAC Role

### cluster-admin

{% hint style="danger" %}
`cluster-admin` grants unrestricted access across the cluster. Use it only when a user\
truly needs full cluster control.
{% endhint %}

**Create the binding:**

```
kubectl create clusterrolebinding <USERNAME>-cluster-admin \
>-clusterrole=cluster-admin \
Verify it:
2.2 admin
admin is intended for namespace administrators. It allows broad management of namespace
scoped resources and can create Role and RoleBinding objects inside that namespace.
Single namespace:
Multiple namespaces:
2.3 edit
  >-user=<USERNAME> \
  >-dry-run=client -o yaml | kubectl apply -f 
```

**Verify it :**

```
kubectl get clusterrolebinding <USERNAME>-cluster-admin
```

### admin

`admin` is intended for namespace administrators. It allows broad management of namespace\
scoped resources and can create `Role` and `RoleBinding` objects inside that namespace.

**Single namespace:**

```
kubectl create rolebinding <USERNAME>-admin \
  >-clusterrole=admin \
  >-user=<USERNAME> \
  >-namespace=<NAMESPACE> \
  >-dry-run=client -o yaml | kubectl apply -f 
```

```
kubectl get rolebinding <USERNAME>-admin -n <NAMESPACE>
```

**Multiple namespaces:**

```
for ns in <NAMESPACE1> <NAMESPACE2>; do
  kubectl create rolebinding <USERNAME>-admin \
    >-clusterrole=admin \
    >-user=<USERNAME> \
    >-namespace="${ns}" \
    >-dry-run=client -o yaml | kubectl apply -f 
done
```

```
kubectl get rolebinding <USERNAME>-admin -n <NAMESPACE1>
kubectl get rolebinding <USERNAME>-admin -n <NAMESPACE2>
```

### edit

`edit` is intended for developers who need read and write access to most namespaced\
resources but should not manage RBAC policy.\
**Single namespace:**

```
kubectl create rolebinding <USERNAME>-edit \
  >-clusterrole=edit \
  >-user=<USERNAME> \
  >-namespace=<NAMESPACE> \
  >-dry-run=client -o yaml | kubectl apply -f -
```

```
kubectl get rolebinding <USERNAME>-edit -n <NAMESPACE>
```

**Multiple Namespace:**

```
for ns in <NAMESPACE1> <NAMESPACE2>; do
  kubectl create rolebinding <USERNAME>-edit \
    >-clusterrole=edit \
    >-user=<USERNAME> \
    >-namespace="${ns}" \
    >-dry-run=client -o yaml | kubectl apply -f -
done
```

```
kubectl get rolebinding <USERNAME>-edit -n <NAMESPACE1>
kubectl get rolebinding <USERNAME>-edit -n <NAMESPACE2>
```

### view

`view` is intended for read-only access to most namespaced resources

{% hint style="info" %}
Note : By default, `view` does not allow reading `Secret` objects
{% endhint %}

**Single Namespace:**

```
kubectl create rolebinding <USERNAME>-view \
  >-clusterrole=view \
  >-user=<USERNAME> \
  >-namespace=<NAMESPACE> \
  >-dry-run=client -o yaml | kubectl apply -f -
```

```
kubectl get rolebinding <USERNAME>-view -n <NAMESPACE>
```

**Multiple Namespace:**

```
for ns in <NAMESPACE1> <NAMESPACE2>; do
  kubectl create rolebinding <USERNAME>-view \
    >-clusterrole=view \
    >-user=<USERNAME> \
    >-namespace="${ns}" \
    >-dry-run=client -o yaml | kubectl apply -f -
done
```

```
kubectl get rolebinding <USERNAME>-view -n <NAMESPACE1>
kubectl get rolebinding <USERNAME>-view -n <NAMESPACE2>
```