Skip to main content
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 still works, but IAM Access Policies supersede it and offer more flexible, role-based access control. This page is a reference for administrators and organization owners whose CoreWeave organizations still use the legacy groups. Use it to understand what each legacy group grants and how those groups map to the current IAM roles. You can then interpret existing access, plan a migration, or troubleshoot permissions issues.

​
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 who aren’t assigned to any groups can still access the Cloud Console, but don’t 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 might not be automatically included in legacy admin policies. If you expect access to a feature but can’t reach it, check your organization’s access policies and add the relevant role if it’s missing. To review and modify these role assignments or create new groups with different role combinations, use IAM Access Policy management.

​
Group permissions in detail

The following sections describe each legacy group, the actions its members can perform, and the equivalent IAM roles in the new model. Managed Auth uses Kubernetes RoleBindings and ClusterRoleBindings to define user permissions within CKS organizations. Each organization gets a single namespace in which organization members can create clusters. Administrators can then grant users 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 maps to Observability Viewer.
  • billing_viewer maps to 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.
CoreWeave automatically assigns the first user who creates an organization 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 broad 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 with 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 can add and remove others from clusters at any time. They can also assign admin privileges to other users. Admins can also deactivate or reactivate any user in their organization through 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 can 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 can 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 can 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 can view billing data, including the billing dashboard, current balance, and listing or downloading invoices.

​
Next steps

Migrate from the legacy groups to the new permissions model so you can use role-based access control and the full set of roles available for newer platform features. To transition to the new permissions model or create custom access policies, see IAM Access Policies.
Last modified on June 10, 2026