> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scitix.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Create CKS cluster access roles

> Create a regular role or cluster role based on the scope of Kubernetes resources that users need to manage.

Access roles define the Kubernetes resources that users can manage and the actions they can perform. Before creating a role, select either a standard role or a cluster role based on the permission scope required for your business.

## Select Role Type

| Role Type | Scope of Permissions | Applicable Scenarios |
| - | - | - |
| Regular role (`Role`) | Resources within a specified namespace. | The user only needs to manage workloads, configurations, or storage resources in a specific namespace. |
| Cluster role (`Cluster Role`) | Cluster-level resources or resources across namespaces. | The user needs to manage cluster-level resources such as nodes and namespaces, or perform the same operations across multiple namespaces. |

> [!WARNING]
>
> The permission scope of a cluster role may cover the entire cluster. Configure roles with the minimum permissions required for users to complete their tasks, and avoid granting permissions to operate unrelated resources.

## Create Role

1. Log in to the [GPU Cloud console](https://console.scitix.ai/gpu-cloud/home) and go to the **Clusters** page.

2. Click the name of the target cluster to access the cluster workspace.

3. In the left navigation pane, go to the **Permissions** page.

4. Switch to the **Custom Roles** tab and click **Create**.

5. Configure the role in the **Create Custom Role** dialog box.

   | Configuration Item | Description |
   | - | - |
   | **Name** | Enter a display name that makes the role's purpose easy to identify. |
   | **Role Type** | Select **Role** to create a standard role, or select **Cluster Role** to create a cluster role. |
   | **YAML** | Enter the Kubernetes YAML for the role. The `kind` in the YAML must match the selected role type. |

   **Standard Role Example**

   The following example allows viewing Pods, Pod logs, and Deployments in the `default` namespace. Modify the role name, namespace, resources, and actions as needed.

   ```yaml theme={null}
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: workload-reader
     namespace: default
   rules:
     - apiGroups: [""]
       resources: ["pods", "pods/log"]
       verbs: ["get", "list", "watch"]
     - apiGroups: ["apps"]
       resources: ["deployments"]
       verbs: ["get", "list", "watch"]
   ```

   **Cluster Role Examples**

   The following example allows viewing nodes and namespaces in the cluster. Modify the role name, resources, and actions as needed. `ClusterRole` does not require a namespace.

   ```yaml theme={null}
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: cluster-resource-reader
   rules:
     - apiGroups: [""]
       resources: ["nodes", "namespaces"]
       verbs: ["get", "list", "watch"]
   ```

6. Click **OK**.

After creation is complete, verify that the role is displayed on the **Custom Roles** tab.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.