Skip to main content

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.

This guide covers the legacy permissions model. For the new permissions model, see IAM Access Policies.

​
About legacy permissions

CoreWeave previously used a group-based permissions model with five predefined groups. This model is still functional but has been superseded by IAM Access Policies, which offer more flexible, role-based access control. This page serves as a reference for organizations still using the legacy groups.

​
Legacy user groups and permissions

CoreWeave provides the following legacy user groups for organization users:
  • admin
  • read
  • metrics
  • write
  • billing_viewer
Each of these groups provides varying levels of privilege within your CoreWeave organization. An administrator must add all non-administrator users to a group to allow them to interact with organization resources. Users that are not assigned to any groups can still access the Cloud Console, but do not have any resource permissions.

​
Mapping legacy groups to IAM roles

The following table shows the CoreWeave legacy permissions mapped to their corresponding new roles:
CoreWeave Legacy GroupCorresponding IAM Roles
adminIAM Admin, CKS Admin, Object Storage Admin, Access Token Admin, Access Request Approver
writeCKS Admin, Object Storage Admin, Access Token Admin
readIAM Viewer, CKS Viewer, Access Token Viewer
metricsObservability Viewer
billing_viewerBilling Viewer
Roles added for newer platform features may not be automatically included in legacy admin policies. If you expect access to a feature but are unable to reach it, check your organization’s access policies and add the relevant role if it is missing. You can review and modify these role assignments or create new groups with different role combinations using IAM Access Policy management.

​
Group permissions in detail

Managed Auth leverages Kubernetes RoleBindings and ClusterRoleBindings to define user permissions within CKS organizations. Organizations are allocated a single namespace in which organization members can create clusters. Users may then be granted specific permissions to perform actions within a given cluster. The CKS-related legacy permission groups map directly to standard Kubernetes user-facing groups, where the CKS permission groups map accordingly to standard groups:
CoreWeave Legacy GroupKubernetes Role MappingCoreWeave IAM Role Name
admincluster-adminCKS Admin
writeeditCKS Admin
readviewCKS Viewer
The following CoreWeave legacy groups map to the corresponding new roles, but do not map to Kubernetes RBAC permissions:
  • metrics - Observability Viewer
  • billing_viewer - Billing Viewer

​
admin group permissions

In the IAM Access Policies model, the admin group equivalent IAM roles are: IAM Admin, CKS Admin, Object Storage Admin, Access Token Admin, Access Request Approver.
The first user to create a CoreWeave organization is automatically assigned to the admin group. Every organization must have at least one admin.
Admins hold the highest level of privilege within an organization. They can make significant changes to the environment and view sensitive information about the organization, cluster configuration, and other users. Administrators can also adjust their own permissions to gain access to specific cluster resources. Assign this role carefully.
Admins can assign users to groups using the command write_groups_user_assignments and can edit initial user access permissions until the user accepts the invitation. Admins can perform the following actions for cluster and user management:

​
Manage Clusters

​
Manage users

  • Invite new users to the organization
  • Assign users to specific groups, including the admin group, both before and after sending an invitation
  • Deactivate other user accounts, including admin user accounts
  • Remove users from groups
  • View user groups and their members
Admin users may add and remove others from clusters at any time. They may also assign admin privileges to other users. Admins can also deactivate or reactivate any user in their organization via the write_org_users cluster action.

​
write group permissions

In the IAM Access Policies model, the write group equivalent IAM roles are: CKS Admin, Object Storage Admin, Access Token Admin.
Users in the write group may perform the following actions for cluster and user management:
  • Create new CKS clusters in your CoreWeave organization
  • View existing cluster configurations
  • Create and view cluster API Access Tokens
  • Open support tickets through Freshdesk
  • View metrics and logs for all clusters
  • View user groups and their members

​
metrics group permissions

In the IAM Access Policies model, the metrics group equivalent IAM role is: Observability Viewer.
Users in the metrics group may perform the following actions:

​
read group permissions

In the IAM Access Policies model, the read group equivalent IAM roles are: IAM Viewer, CKS Viewer, Access Token Viewer.
Users in the read group may perform the following actions:
  • View existing cluster configurations
  • Open support tickets through Freshdesk
Users in the read group cannot view metrics and logs for all clusters.

​
billing_viewer group permissions

In the IAM Access Policies model, the billing_viewer group equivalent IAM role is: Billing Viewer.
Users in the billing_viewer group may perform the following actions:

​
Next steps

To transition to the new permissions model or create custom access policies, see IAM Access Policies.
Last modified on April 16, 2026