CoreWeave IAM doesn’t govern Forge. Forge has a separate identity and access system for organizations, teams, projects, and product access. See Forge and CoreWeave identity.
Authorization model
Use the following layers to determine how a user or workload gets access:
An identity or credential doesn’t grant authorization by itself. For example, an API access token authenticates its owner. The owner’s IAM roles determine which platform actions they can perform with the token. Service-specific controls can impose additional requirements.
Service authorization boundaries
The following services have authorization controls outside IAM Access Policies:Enterprise onboarding
When you onboard an organization, use the following sequence to set up identity, provisioning, and least-privilege access:- Sign-in and SSO: Configure SAML SSO so your team signs in through your identity provider. To enforce SSO as the only sign-in method, use login methods to turn off email and password, Google, and GitHub sign-in by default, and review per-user overrides.
- Multi-factor authentication (MFA): Each user can enable two-factor authentication (2FA) with a time-based one-time password (TOTP) on their account settings page. For organization-wide enforcement, configure your identity provider to require MFA on every SSO sign-in. See Can I enforce 2FA for all users?.
- User and group provisioning: Sync users and groups from your identity provider with Automated User Provisioning (AUP), which uses the System for Cross-domain Identity Management (SCIM). Group memberships are synchronized with IAM and can be used in access policies.
- Least-privilege access: Assign IAM roles through access policies. Use default access policies to keep common access patterns current as CoreWeave introduces new roles, and create custom policies for narrower access.
Per-cluster access scoping
Managed Authentication allows every CoreWeave user in an organization to authenticate to every CKS cluster in that organization. IAM roles determine what each user can do, but they don’t provide per-cluster scoping. To control which identities can authenticate to a specific cluster, configure Unmanaged Authentication with your own identity provider. Then, use Kubernetes RBAC to authorize those identities. For stronger organizational separation, contact support about using multiple organizations. See How do I scope users to specific clusters?.Object Storage access without admin
To obtain Object Storage credentials, users need either the Object Storage Admin role or an organization access policy that grants the narrowercwobject:CreateAccessKey permission. To let users obtain credentials without the full admin role, grant this permission through an organization access policy. Users can then exchange their API access token directly for temporary credentials. Combine this approach with group-based bucket policies so SCIM group memberships control which buckets each user can access.
For production workloads, CoreWeave recommends that you use Workload Identity Federation to exchange short-lived identity-provider tokens for temporary credentials.
Troubleshoot access
Start with the layer where the access attempt failed:- If a user can’t sign in or obtain an API access token, see the authentication and access support articles.
- If CKS returns an authentication or authorization error, see Managed Authentication errors.
- If a user can’t create Object Storage credentials or access a bucket, see How do I give someone Object Storage access without admin privileges?.
- If Grafana doesn’t show metrics, see Why are my metrics missing in Grafana?.
- If a SUNK user can’t access a cluster, see How do I add users to the
slurm-usersgroup? and Where do I add my SSH public key?.