Introduction to Automated User Provisioning

This page introduces CoreWeave’s user provisioning system: how user and group identities move from their source of truth into CoreWeave IAM (CW IAM) and, if you use SUNK, into your SUNK clusters. Users and groups enter CW IAM through two paths: automated federation from an identity provider (IdP) using Automated User Provisioning (AUP), or manual creation in the Cloud Console. Users can also add SSH public keys to their accounts, which SUNK User Provisioning (SUP) uses to enable SSH access to SUNK clusters. This page focuses on AUP and is intended for organization administrators who manage user access at scale. AUP uses SCIM (System for Cross-domain Identity Management), an open standard that ensures changes to user permissions, additions, or removals made in the IdP appear immediately in CW IAM. This removes the need for manual updates or waiting for user-initiated events like SAML SSO logins, and it supports an efficient, accurate user management workflow. Although SCIM can synchronize in two directions, CoreWeave AUP uses one-way synchronization: the IdP is the source of truth, and data flows only from the IdP to CW IAM. The following diagram shows how all three elements (IdP federation via AUP, manual user and group management, and user SSH keys) connect through CW IAM to your SUNK clusters:

• Identity provider (IdP) via AUP: Federate users and groups from an IdP such as Okta or Microsoft Entra using SCIM. Changes in the IdP propagate automatically to CW IAM. The rest of this page covers AUP in detail.
• Manual user and group management: Create and manage users and groups directly in the Cloud Console on the Users and Groups pages.
• User SSH keys: Users add SSH public keys in their Settings page under Slurm Attributes. SUP uses these keys to enable SSH access to SUNK clusters.

​

SUNK user provisioning

SUP automatically provisions CW IAM data into your SUNK clusters, whether that data came from an IdP through AUP or was created manually in the Cloud Console. The exception is users you exempt from SCIM, which SUP doesn’t provision. For setup procedures, see Provision users in SUNK.

​

How SCIM differs from SAML SSO

Because AUP builds on SAML SSO, it helps to understand how the two standards divide responsibilities. SAML SSO lets users sign in securely and supports Just-In-Time (JIT) provisioning, which creates accounts on first sign-in. SCIM requires SAML SSO and goes further by syncing entire directories, including hundreds of users and their group memberships, in real time. Users and groups appear automatically in the Cloud Console without individual invitations or first-time SAML sign-ins. SCIM handles user provisioning and deprovisioning, while SAML handles authentication.

​

Users and groups

AUP synchronizes two core resource types from your IdP to the Cloud Console:

• Users: Creates new users, updates profile fields (first name, last name, status), and deactivates users in the Cloud Console when they’re deactivated in your IdP.
• Groups: Syncs group memberships and group definitions for better access control. AUP supports only flat groups. Nested groups (groups whose member lists include other groups) aren’t supported and cause provisioning errors.

AUP also supports syncing custom attributes defined in the IdP.

​

Key use cases

The following scenarios show how AUP keeps user state consistent between the IdP and the Cloud Console:

• Provision users: When you assign a user to the app in the IdP, AUP automatically creates the user in the Cloud Console.
• Update profiles: When you change attributes, first name, last name, or active status in the IdP, those changes overwrite the matching values in the Cloud Console.
• Deactivate users: When you remove a user from a group assigned to the application in the IdP, AUP deactivates the user in the Cloud Console, so only authorized users retain access.
• Sync groups: You can sync group memberships for application-specific group management beyond access control. To sync a group, you must explicitly add it to the push list in the IdP.
• Force sync (Okta-specific): Okta’s force sync feature lets admins manually push updates, which triggers a synchronization of user attributes between Okta and the Cloud Console. This updates user attributes but doesn’t activate or deactivate accounts. For more information, see Okta’s guide.

​

SCIM-managed and exempt users

Users provisioned from your IdP through AUP are SCIM-managed: the IdP is the source of truth for their profile fields, group memberships, and active status. When AUP is enabled, the Cloud Console Users page shows a SCIM Managed column so you can see which users the IdP controls. You can’t deactivate a SCIM-managed user from the Cloud Console, even with the IAM Admin role. To remove a SCIM-managed user’s access, deprovision them in your IdP and let AUP propagate the change, or mark them exempt from SCIM and then deactivate them from the Console.

​

Exempt a user from SCIM

Marking a user exempt from SCIM removes them from synchronization. The IdP no longer updates the user’s attributes (name, group memberships, or status), and you must manage the account manually from the Cloud Console. If you later deactivate or unassign an exempt user in your IdP, their CoreWeave account stays active until you deactivate it in the Console. An exemption doesn’t block deletion requests. If your IdP sends a SCIM delete request for the user, as Microsoft Entra does when a user is permanently deleted from the tenant, AUP deletes the CoreWeave account as well. Use an exemption when you need to control an account from the Cloud Console instead of the IdP: for example, to deactivate a SCIM-managed user or to manage a user’s group memberships manually. To exempt a user, you need the IAM Admin role:

1. In the Cloud Console, go to the Users page.
2. Click the vertical ellipsis (More options) next to the user, then click Exempt from SCIM.
3. Review the warning, then click Yes, exempt user.

The SCIM Managed column reflects the change, and you can now manage the user from the Cloud Console. To return an exempt user to IdP control, in the same menu, click Include in SCIM, then confirm in the dialog that opens.

​

Set up SCIM

After you configure SAML SSO, set up SCIM to synchronize users and groups from the IdP to the Cloud Console. The exact procedure depends on your IdP, but the overall flow is the same:

1. Enable SCIM in the Cloud Console: Because SCIM controls organization-wide user data, you must explicitly enable it.
2. Enable SCIM in the IdP: In your IdP, open the Provisioning section in the application configuration. This is usually next to the Single Sign-On (SSO) section.
3. Configure the SCIM API base URL: This URL is usually prefixed with the organization ID in the Cloud Console.
4. Select synchronization options: Choose to push new users, push profile updates, and push groups, depending on the level of synchronization you want.
5. Set up authentication: Configure a bearer token for secure communication between the IdP and the Cloud Console.
6. Assign users and groups: In the IdP, assign users and groups to the SCIM-enabled application to provision them in the Cloud Console.

After you complete these steps in your IdP, AUP syncs users and groups assigned to the application into the Cloud Console, and subsequent changes in the IdP propagate automatically.

​

Next steps

To set up AUP, follow the procedure for your IdP:

• Configure AUP with Okta
• Configure AUP with Microsoft Entra