Configure Automated User Provisioning with Okta

Automated User Provisioning (AUP) lets you sync users and groups from your identity provider (IdP) to the Cloud Console, using the SCIM (System for Cross-domain Identity Management) standard. You no longer need to send invites or wait for users to sign in. This guide shows how to set up AUP with Okta as the IdP. When you finish, SAML SSO and one-way SCIM are configured, and you can assign Okta users and groups so they sync into CoreWeave IAM.

​

Prerequisites

You need the following access:

• Admin access to the CoreWeave Cloud Console.
• Admin access to the Okta dashboard.

For SUNK migrations from Authentik or another LDAP directory, you also need:

• A system with ldapsearch and network access to the LDAP endpoint.
• An LDAP bind account with permission to search the configured LDAP search base. The account must also be able to read the configured POSIX username attribute, uidNumber, gidNumber, homeDirectory, loginShell, and sshPublicKey.

​

Create SAML SSO integration

Users created through AUP must use SAML SSO for authentication, so you must configure SAML SSO first.

1. Open the Cloud Console and the Okta dashboard in separate windows.
   • In the Cloud Console: Navigate to the SAML SSO page and click Configure SAML.
   • In Okta: Go to Applications, click Create App Integration, and select SAML 2.0.
   For the next few steps, the Cloud Console displays details for your integration that you need to copy into Okta.
2. Copy the ACS URL from the Cloud Console and paste it into Okta’s Single sign-on URL field. Leave the checkbox checked (for Use this for Recipient URL and Destination URL).
3. Copy the Entity ID from the Cloud Console and paste it into Okta’s Audience URI (SP Entity ID) field.
4. In Okta, within the SAML Attributes > Sign-on tab, add the following SAML SSO attributes in the Attribute Statements section:

   Name	Value
   first_name	user.firstName
   last_name	user.lastName
   email	user.email

   Click Next.
5. For App Type, select This is an internal app we have created, and click Finish.
6. The Okta dashboard displays a page with details for your integration. This time, you copy values from the Okta dashboard and paste them into the Identity Provider section in the Cloud Console. In the Okta dashboard, ensure the Sign-on tab is selected. Under Sign-on methods, under Metadata details, expand the More details caret to reveal more sign-on details.
   • Copy the Sign-on URL, and then paste the value into the SSO URL field in the Cloud Console.
   • Copy the Issuer, and then paste the value into the Entity ID field in the Cloud Console.
   • Copy the Signing Certificate, and then paste the value into the Signing certificate field in the Cloud Console.
7. In the Cloud Console, click Next and then click Deploy SSO.

​

Configure one-way SCIM

Set up one-way SCIM provisioning so the Cloud Console can receive user and group information from Okta.

1. In the Cloud Console, on the SCIM Configuration page, toggle Enable SCIM API and Enable Automated User Provisioning.
2. In the Cloud Console, create a new SCIM Token with a name of your choice (for example, Okta ID).
3. In Okta:
   • On your integration’s General tab, click Edit in the App Settings card.
   • Set Provisioning to SCIM radio button, and click Save.
4. Go to the Provisioning tab in Okta:
   • Click Edit in the SCIM Connection section.
   • Set SCIM Connector base URL to https://api.coreweave.com/scim/[ORG-USERID]. Find your org ID in the ACS URL (from the Cloud Console) https://console.coreweave.com/accounts/saml/[ORG-USERID]/acs.
   • Set Unique identifier field for users to userName.
   • For Supported provisioning actions: select Push New Users, Push Profile Updates, and Push Groups. Do not enable any import options.
   • Set Authentication mode to HTTP Header.
   • For Authorization, paste the bearer token from the Cloud Console.
   After setup, the Settings sidebar populates two new tabs: To App and To Okta. Because this is a one-way sync, To Okta shows Import Not Available.
5. In the To App tab:
   • Click Edit under Provisioning to App.
   • Enable: Create Users, Update User Attributes, and Deactivate Users.
   • Do not enable Sync Password because SAML SSO handles authentication.
   • Click Save.

​

Assign users and groups

To complete the integration, assign users to a group in your IdP, and then assign the group to your application. Then test the integration by checking whether the users sync to the Cloud Console.

1. In the Cloud Console, navigate to the Users page to view a list of all users in your organization.
2. Assign users to a group in Okta:
   • Go to Directory > Groups and click the name of a group.
   • With the People tab selected, click Assign people.
   • Click the + icon to add individuals to the group, and ensure you include the Org Admin.
3. Assign the group to your application in Okta:
   • Go to Applications > Applications and click the name of your application.
   • On your application’s Assignments tab, click the Assign dropdown, then click Assign to Groups.
   • Find the name of the group, then click Assign.
   • Click Save and go back, then click Done.
   • The name of that group appears in the assignments list for your application.
4. In the Cloud Console, refresh the page showing your Users list. The users in the group you assigned in Okta appear in the Cloud Console.

​

Sync groups

The following sections describe how Okta syncs groups to CoreWeave and the options available for managing nested group structures.

​

Nested groups

CoreWeave SCIM does not support nested groups. If you push a parent Okta group whose member list includes references to other groups, provisioning fails for those nested group members. To avoid sync errors, use one of the following approaches:

• Push only flat (leaf) groups. Do not push parent groups that contain sub-groups.
• Add a group membership filter to exclude parent groups from being pushed.
• Use an Okta group rule to flatten nested memberships into a single flat group before pushing.

Okta uses push groups that are configured to push group memberships to applications like the Cloud Console, through a feature called Group Push. You can sync groups from Okta to the Cloud Console in two ways:

• Recommended path: Configure a regular Okta group for all the users you want to push to CoreWeave, along with all regular groups that you want to represent in the Cloud Console. Then configure push groups for any subgroups you want to manage within CoreWeave. Only those subgroups sync with CoreWeave automatically. Removing a user from a subgroup does not remove the user from the “all CoreWeave users” group.
• Manual path: Do not create an “all CoreWeave users” group. Configure push groups in a one-to-one mapping with every regular group. When you make changes, manually run force sync in Okta for each update.

​

Map SUNK attributes

If you use SUNK User Provisioning (SUP), you can sync SSH public keys and POSIX user information from Okta to CoreWeave. This requires creating custom attributes in your Okta user profile and mapping each one to CoreWeave’s SCIM endpoint.

​

SUNK attribute reference

Create all of the following custom attributes in your Okta user profile and map each one to the corresponding CoreWeave SCIM attribute. The steps in this section use the SSH keys attribute as a worked example. Repeat the same process for each row.

​

Add the SUNK attributes to the Okta user profile

1. In the Okta Admin Console, navigate to Directory > Profile Editor.
2. Click Okta in the Filters list, then click Profile for Okta User (default).
3. Click Add Attribute and configure the fields for the SSH keys attribute:

   Field	Value
   Data type	Array
   Display name	SUNK SSH Keys
   Variable name	sunk_ssh_keys
   Description	SSH public keys for SUNK login

4. Click Save.
5. Repeat the previous two steps for each remaining attribute in the SUNK attribute reference table, using the Display name, Variable name, and Data type values from that table.

​

Set the SSH key on a user profile

1. In the Okta Admin Console, navigate to Directory > People.
2. Select the target user and click the Profile tab.
3. Click Edit and enter the user’s SSH public key in the SUNK SSH Keys field (for example, ssh-ed25519 AAAAC3Nza...).
4. Click Save.

​

Add the attribute mapping

1. In the Okta Admin Console, navigate to Applications > Applications and select your CoreWeave application.
2. Click the Provisioning tab, then select To App in the settings list.
3. Scroll to the Attribute Mappings section and click Edit.
4. Find sunk_ssh_keys in the list of Okta user profile attributes. In the target attribute dropdown, select the CoreWeave SCIM attribute sunkSshKeys. Okta auto-discovers this attribute from CoreWeave’s SCIM schema. The attribute appears under the urn:coreweave:params:scim:schemas:extension:coreweave:2.0:CoreWeaveUser namespace.
5. Repeat the previous step for each remaining attribute in the SUNK attribute reference table, matching the Okta source attribute (Variable name) to the corresponding CoreWeave SCIM attribute.
6. Click Save.

​

Verify the sync

1. In Okta, trigger a manual push for the target user (or wait for the next provisioning cycle).
2. In the Cloud Console, navigate to Users, click the three-dot menu next to the target user, and select View Details.
3. Under Slurm Attributes, confirm the SSH Keys field contains the public key you set in Okta.

If the key does not appear, check the Okta provisioning logs under Reports > System Log for errors. For more details about verifying SSH keys and configuring SUP, see Provision users in SUNK.

​

Preserve POSIX identities during migration

For a SUNK migration, use this procedure before the standard provisioning sequence. When you migrate an existing SUNK environment from Authentik or another LDAP directory, preserve each user’s numeric UID and GID. File ownership and permissions use these numeric IDs, so allowing CoreWeave IAM to assign new values can prevent users from accessing their existing files. Complete the migration in this order:

1. From a system that can reach your LDAP endpoint, export the existing LDAP attributes as close to the cutover as possible. Set [LDAP-URI] to the LDAP endpoint URI and [LDAP-BIND-DN] to the bind distinguished name. Set [LDAP-SEARCH-BASE] to the search base and [LDAP-USER-FILTER] to the user search filter. Set [LDAP-USERNAME-ATTRIBUTE] to the attribute configured as the POSIX username in SUNK:
   export LDAP_URI="[LDAP-URI]"
   export LDAP_BIND_DN="[LDAP-BIND-DN]"
   export LDAP_SEARCH_BASE="[LDAP-SEARCH-BASE]"
   export LDAP_USER_FILTER="[LDAP-USER-FILTER]"
   export LDAP_USERNAME_ATTRIBUTE="[LDAP-USERNAME-ATTRIBUTE]"
   
   ldapsearch -x \
     -H "${LDAP_URI}" \
     -D "${LDAP_BIND_DN}" \
     -W \
     -b "${LDAP_SEARCH_BASE}" \
     "${LDAP_USER_FILTER}" \
     "${LDAP_USERNAME_ATTRIBUTE}" \
     uidNumber gidNumber homeDirectory loginShell sshPublicKey \
     > authentik-sunk-users.ldif
   
   ldapsearch prompts for the bind password instead of storing it in your shell history. The exported file contains user identity data and SSH public keys, so protect it according to your organization’s policies. To find the username attribute, check userNameAttr in the existing System Security Services Daemon (SSSD) configuration or ldap_uidattr in the existing nsscache configuration. Authentik deployments can use cn, but the configured attribute can differ.
2. Complete the SAML SSO integration and one-way SCIM configuration, but don’t assign users or groups to the CoreWeave application yet.
3. In Okta, create the SUNK attributes and map them to the CoreWeave SCIM attributes.
4. Before you assign users to the CoreWeave application, populate each Okta user profile with the corresponding exported values:

   LDAP attribute	Okta variable
   Configured POSIX username attribute	sunk_posix_username
   uidNumber	sunk_posix_user_id
   gidNumber	sunk_posix_group_id
   homeDirectory	sunk_preferred_home_directory
   loginShell	sunk_login_shell
   sshPublicKey	sunk_ssh_keys

   If a user has multiple sshPublicKey values, add each key to the sunk_ssh_keys array.
5. Assign the users and groups.
6. On the SCIM Configuration page in the Cloud Console, confirm that you’ve enabled Enable SCIM API, Enable automated user provisioning, and Enable SUNK user provisioning.
7. Coordinate with your CoreWeave account team to test the SCIM-backed nsscache configuration against the LDAP export. After the comparison succeeds, your account team can update SUNK to use SCIM instead of LDAP.
8. Compare each user’s POSIX username, UID, GID, home directory, login shell, and SSH keys with the exported LDAP values. Use the nsscache output or SCIM response for the complete comparison. You can verify the POSIX username, UID, GID, and SSH keys on the Cloud Console Users page. Also confirm that assigned users and groups appear in the Cloud Console.

​

Adjust attribute mappings

The following sections describe attribute mapping adjustments you must make so that groups sync correctly, along with the recommended group sync configuration.

​

Remove the Department attribute

The Department attribute in Okta can prevent groups from syncing properly with CoreWeave IAM. Before syncing groups, remove this attribute from the attribute mappings:

1. Navigate to your CoreWeave application in the Okta dashboard.
2. Click the Provisioning tab.
3. Locate the Attribute Mapping section.
4. Remove the Department attribute, and save your changes.

This adjustment removes the Department attribute from the attribute mapping used for syncing with CoreWeave, but does not change the attribute inside Okta itself.

​

Recommended group sync configuration

To sync groups correctly between Okta and CoreWeave IAM, follow these steps:

1. Configure a regular Okta group for all the users you want to push to CoreWeave.
2. Configure regular Okta groups for all the subgroups that you want to represent in the Cloud Console.
3. For legacy CoreWeave IAM deployments, ensure that your selected Okta groups and subgroups are not named any of the default user groups. For every push group with the same name as a default user group, create a new user group with the appropriate default policies attached.
4. Use Group Push to sync your Okta groups for all except the “all CoreWeave users” group.

​

Legacy default user groups

Legacy CoreWeave IAM deployments automatically provisioned a set of default user groups with specific policies attached. The attached policies were necessary for operating CoreWeave services. These legacy default user groups included:

• admin
• metrics
• read
• write
• billing_viewer

When syncing groups with legacy CoreWeave IAM deployments with SCIM, you must resolve the naming conflict by either avoiding syncing push groups with these names, or for each push group with the same name as a default user group:

• Create a new user group in CoreWeave IAM with a new preferred name.
• Assign the policies attached to a default user group. For example, for an administration group use the policies attached to the admin group.
• Delete the default user group before configuring a push group with the same name.