Skip to main content

IAM Access Policies

Learn about CoreWeave IAM Access Policies

CoreWeave IAM Access Policies let administrators and privileged users define which principals (CoreWeave IAM users or groups) are allowed to perform specific actions across CoreWeave services. Policies are created once and then evaluated wherever authorization is required, enabling consistent, least-privilege access across the Cloud Platform.

IAM Access Policies do not govern actions for the following services, which currently host their own authorization infrastructure:

Core concepts

TermDescription
PrincipalA CoreWeave IAM identity (either a user or a group) that can be referenced in a policy.
RoleA permission string enabling a set of actions that, when assigned to a principal, are permitted.
RuleAn assignment of a role or set of roles to a principal.
PolicyA collection of rules that assign entitlements to a set of principals. When a principal is referenced in a policy, the principal is allowed to perform the actions assigned to it by the policy.

CoreWeave IAM operates on a default-deny posture: without an access policy that assigns privileges to principals, that principal is not allowed to conduct an action.

Structurally, the policy contains one or more rules, and each rule assigns a role to a principal. For example:

Roles

CoreWeave IAM supports the following actions permitted in roles:

NameRole Description
Access Token ViewerRead-only visibility into personal access tokens (list and view).
Access Token AdminFull management of personal access tokens: create and delete tokens for the current user as permitted by org policy.
IAM ViewerRead-only visibility across IAM configuration (for example, view organization user permitted actions, SAML configuration, AUP provisioning, API tokens, groups and memberships).
IAM AdminAdministrative control over IAM: invite/revoke users, create/delete/update groups and memberships, and configure identity integrations (for example, SAML SSO, AUP provisioning, API tokens).
CKS ViewerRead-only visibility into Kubernetes resources: list and view clusters and VPC resources.
CKS AdminAdministrative control over Kubernetes resources: create, update, and delete clusters and VPC resources.
Object Storage AdminFull administration for AI Object Storage: create/delete buckets, manage organization access policies, and create/revoke/list access keys; includes listing buckets and ensuring/setting bucket access policies.
Billing ViewerRead-only access to billing data, including viewing the billing dashboard, current balance, and listing/downloading invoices.
Observability ViewerRead-only access to observability data (for example, cluster metrics/dashboards) for troubleshooting and performance monitoring.
Support ViewerRead-only access to support tickets/records in the integrated support system (Freshdesk).
Access Request ApproverApproves or denies privileged access requests; can view the list of pending Service Account Management access requests.

Admins can manage resources in the Cloud Console, the API, and with infrastructure as code (IaC) tools like Terraform.

Legacy group role assignments

User permissions depended on the group they were assigned to. The following table shows the legacy permissions and their corresponding new roles:

Legacy GroupAssigned 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

You can review and modify these role assignments or create new groups with different role combinations using IAM Access Policy management.

Next steps