> ## 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. # IAM Access Policies > CoreWeave IAM Access Policies for assigning permissions to users and groups across platform services CoreWeave IAM Access Policies let administrators and privileged users define which principals (CoreWeave IAM users or groups) can perform specific actions across CoreWeave services. You create a policy once, and CoreWeave evaluates it wherever authorization is required, which enforces consistent, least-privilege access across the Cloud Platform. IAM Access Policies don't govern actions for the following services, which host their own authorization infrastructure: * The [CoreWeave AI Object Storage S3-compatible API](/products/storage/object-storage/reference/object-storage-s3), which is governed by [organization and bucket access policies](/products/storage/object-storage/auth-access/policies). * [Kubernetes Roles and RoleBindings](/products/cks/auth-access/managed-auth/kubeconfig) within CoreWeave Kubernetes Service (CKS) clusters, which use Kubernetes RBAC. ## Core concepts The following terms are central to how IAM Access Policies work: | Term | Description | | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Principal | A CoreWeave IAM identity (either a user or a group) that can be referenced in a policy. | | Role | A permission string enabling a set of actions that, when assigned to a principal, are permitted. | | Rule | An assignment of a role or set of roles to a principal. | | Policy | A collection of rules that assign entitlements to a set of principals. When a principal is referenced in a policy, that principal can perform the actions the policy assigns to it. | CoreWeave IAM operates on a default-deny posture. Without an access policy that grants privileges to a principal, that principal can't perform an action. Structurally, the policy contains one or more rules, and each rule assigns a role to a principal. For example: Example IAM Access Policy assigning CKS Admin, IAM Admin, Billing Viewer, and CKS Viewer roles to two users and a group In this example, the policy grants the following permissions: * User A has the CKS Admin role, which lets them manage Kubernetes resources. * User B has the IAM Admin and Billing Viewer roles, which let them manage IAM resources and view billing data. * Engineering Group has the CKS Viewer role, which lets them view Kubernetes resources. ## Roles CoreWeave IAM supports the following actions permitted in roles: | Name | Role description | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Access Token Viewer | Read-only visibility into personal access tokens (list and view). | | Access Token Admin | Full management of personal access tokens: create and delete tokens for the current user as permitted by org policy. | | IAM Viewer | Read-only visibility across IAM configuration (for example, view organization user permitted actions, SAML configuration, AUP provisioning, API tokens, groups and memberships). | | IAM Admin | Administrative control over IAM: invite and revoke users, create, delete, and update groups and memberships, and configure identity integrations (for example, SAML SSO, AUP provisioning, API tokens). | | CKS Viewer | Read-only visibility into Kubernetes resources: list and view clusters and VPC resources. | | CKS Admin | Administrative control over Kubernetes resources: create, update, and delete clusters and VPC resources. | | Inference Viewer | Read-only visibility into inference resources: list and view gateways, deployments, and capacity claims. | | Inference Admin | Administrative control over inference resources: create, update, and delete gateways, deployments, and capacity claims. Includes Inference Viewer permissions. | | Object Storage Admin | Full administration for AI Object Storage: create and delete buckets, manage organization access policies, and create, revoke, and list access keys. Includes listing buckets and ensuring and setting bucket access policies. | | Billing Viewer | Read-only access to billing data, including viewing the billing dashboard, current balance, and listing and downloading invoices. | | Observability Viewer | Read-only access to observability data (for example, cluster metrics and dashboards) for troubleshooting and performance monitoring. | | Notifications Viewer | Read-only access to alert history, notification delivery statuses, and the alert configuration page. | | Notifications Admin | Manage which alerts the organization receives and where they are delivered: subscribe and unsubscribe alerts per destination on the alert configuration page. Includes Notifications Viewer permissions. | | Integrations Viewer | Read-only visibility into notification destinations and credentials, including the Integrations page and the destinations list on the alert configuration page. | | Integrations Admin | Full management of notification destinations and credentials: create, update, and delete Slack and webhook integrations. Includes Integrations Viewer permissions. | | Support Viewer | Read-only access to support tickets and records in the integrated support system (Freshdesk). | | Access Request Approver | Approves or denies privileged access requests. Can view the list of pending Service Account Management access requests. | Administrators can manage resources in the Cloud Console, the API, and with infrastructure-as-code (IaC) tools like Terraform. ### Legacy group role assignments Before IAM Access Policies, user permissions were determined by the legacy group a user belonged to. The following table shows how each legacy group maps to the new IAM 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 | Roles added for newer platform features may 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. You can review and modify these role assignments or create new groups with different role combinations using [IAM Access Policy management](/security/iam/access-policies/manage). ## Next steps * Create an [IAM Access Policy](/security/iam/access-policies/manage). * Learn about [CoreWeave IAM](/security/iam).