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

# Organizational identity

> How CoreWeave organizations, users, and groups map to CKS

CoreWeave [organizations and users](/security/authn-authz/orgs-users) map directly to CKS through IAM roles and Kubernetes RBAC. This page summarizes how platform-level identity concepts apply within CKS.

## CKS users

CKS designates two IAM roles that correspond to the platform [user types](/security/authn-authz/orgs-users#user-types).

### CKS administrators

CKS administrators have the `CKS Admin` IAM role. This role grants broad access to cluster management, including creating clusters, managing API Access Tokens, configuring SAML SSO, and viewing metrics and logs.

### CKS viewers

CKS viewers have the `CKS Viewer` IAM role. This role grants more limited permissions, which must be allocated by administrators.

## CKS user permissions

Within a CKS cluster, user permissions are defined as follows:

* **Read** permissions grant the user the ability to use all [`watch`, `get`, and `list` verbs](https://kubernetes.io/docs/reference/using-api/api-concepts/#api-verbs) on cluster resources within their cluster.
* **Write** permissions grant the user the ability to [`create`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_create/) and [`patch`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_patch/) cluster resources within their cluster.

<Info>
  For the full permissions model, see [IAM Access Policies](/security/iam/access-policies) and [Legacy User Permissions](/security/iam/access-policies/legacy-permissions).
</Info>

## Organization IDs in CKS

CKS uses [Organization IDs](/security/authn-authz/orgs-users#organization-ids) to enforce tenant isolation. All interactions with CKS filter users using their Org ID, and all cluster requests are scoped to Org IDs.