Legacy User Permissions
Reference for the CoreWeave legacy group-based permissions model
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:
adminreadmetricswritebilling_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 Group | Corresponding IAM Roles |
|---|---|
admin | IAM Admin, CKS Admin, Object Storage Admin, Access Token Admin, Access Request Approver |
write | CKS Admin, Object Storage Admin, Access Token Admin |
read | IAM Viewer, CKS Viewer, Access Token Viewer |
metrics | Observability Viewer |
billing_viewer | Billing Viewer |
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 Group | Kubernetes Role Mapping | CoreWeave IAM Role Name |
|---|---|---|
admin | cluster-admin | CKS Admin |
write | edit | CKS Admin |
read | view | CKS Viewer |
The following CoreWeave legacy groups map to the corresponding new roles, but do not map to Kubernetes RBAC permissions:
metrics- Observability Viewerbilling_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
- Create new CKS clusters in your CoreWeave organization
- View existing cluster configurations
- Create and view cluster API Access Tokens
- Create and view SAML configurations
- Open support tickets through Freshdesk
- View metrics and logs for all 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:
- Access CoreWeave Grafana to view dashboards and explore metrics and logs for all clusters
- Access the CoreWeave Logs and Metrics APIs to query metrics and logs for all clusters
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:
- View billing data, including the billing dashboard, current balance, and listing or downloading invoices
Next steps
To transition to the new permissions model or create custom access policies, see IAM Access Policies.