Pulumi Cloud organization identity providers

Every Pulumi organization is backed by exactly one identity provider, which governs who is allowed to be a member. New organizations use the Pulumi identity provider, where membership is managed entirely in Pulumi Cloud. You can instead back an organization with a GitHub organization, a GitLab group, a Bitbucket workspace, or a SAML 2.0 identity provider.

When an organization is backed by a third party, membership is the intersection of two things: a user must belong to the Pulumi organization and be a current member of the backing organization, group, or workspace. As soon as someone loses access to the backing system, they lose access to the Pulumi organization.

A user who belongs to the backing system but has not been added to the Pulumi organization yet is a potential member. Potential members appear on the list of people an organization admin can invite, but they cannot use the organization until they are added.

Available identity providers

These options are mutually exclusive. An organization uses one identity provider at a time, and selecting a new one replaces the old one.

This setting goes by more than one name. The docs and the console call it the organization’s identity provider, and you configure it under Membership Requirements; the console also refers to it as the organization backend, which is the name the REST API uses. They all mean the same thing.

Before you change identity providers

Changing an organization’s identity provider takes effect immediately, and Pulumi does not check in advance whether your existing members can meet the new requirement. Anyone who cannot is locked out until they can.

Before you change providers:

1. Link an identity from the new provider to your own Pulumi account first. You cannot select a provider you have no identity for, and if you lock yourself out you cannot change the setting back.
2. Confirm that every member has linked an identity from the new provider to their Pulumi account, under Account settings > Identity providers. For the steps, see Adding new identities.
3. Confirm that every member belongs to the GitHub organization, GitLab group, or Bitbucket workspace you are about to require.

Members who do not meet the new requirement are not deleted. Their membership records remain in place, and they regain access as soon as they link the required identity and belong to the backing organization.

Permissions

Changing the identity provider requires the organization:change_backend permission, shown as Change organization backend in Pulumi Cloud. Organization admins have it by default, and you can grant it to a custom role. See Organization settings scopes.

Some providers add a requirement on top of this one. To select a Bitbucket workspace, you must also be an admin or owner of that workspace. See Bitbucket.

Changing your organization’s identity provider

1. Navigate to Settings > Access management.
2. Select the Other tab.
3. In the Membership Requirements section, select Change requirements.
4. On the Select Requirements step, choose an identity provider, then choose the specific organization, group, or workspace that should back your Pulumi organization.
5. On the Confirm Requirements step, review the change and select Apply changes.

The change takes effect immediately and is recorded in your audit logs. Admins can change the requirement again at any time.

The Membership Requirements section does not appear for individual organizations or for legacy per-stack organizations, because membership works differently for those.

GitHub

A GitHub-backed organization draws its membership from a GitHub organization. Only members of that GitHub organization can belong to the Pulumi organization.

To back your organization with GitHub:

1. Connect a GitHub identity to your Pulumi account under Account settings > Identity providers.
2. Make sure the Pulumi OAuth app is authorized for the GitHub organization with the read:org scope, which Pulumi uses to verify who belongs to the organization. You can review and grant that access on the Pulumi OAuth app’s page in your GitHub settings. Depending on the GitHub organization’s third-party application policy, a GitHub organization owner may need to grant or approve this access. Pulumi does not get access to source code, issues, or any other organization data.
3. Change your organization’s identity provider and select the GitHub organization.

If the backing GitHub organization enforces its own SAML SSO, each member must also authorize their GitHub credential for that organization. Until they do, GitHub does not report their membership to Pulumi and they cannot access the Pulumi organization.

GitLab

A GitLab-backed organization draws its membership from a top-level GitLab group. Subgroups cannot back a Pulumi organization.

To back your organization with GitLab:

1. Connect a GitLab identity to your Pulumi account under Account settings > Identity providers.
2. Make sure the group is visible to your GitLab account.
3. Change your organization’s identity provider and select the GitLab group.

GitLab lets group owners grant memberships that expire. A member whose GitLab group membership has expired, or is in any state other than active, loses access to the Pulumi organization.

Bitbucket

A Bitbucket-backed organization draws its membership from a Bitbucket workspace. Bitbucket identities are labeled Atlassian in your account settings.

To back your organization with Bitbucket:

1. Connect an Atlassian identity to your Pulumi account under Account settings > Identity providers, granting the Pulumi OAuth app read access to your account and workspace membership information.
2. Confirm that you are an admin or owner of the workspace.
3. Change your organization’s identity provider and select the Bitbucket workspace.

Once the change is complete, admins can see the list of Bitbucket workspace members and add or invite them to the Pulumi organization. Adding them is a separate step from their workspace membership. See Backing membership doesn’t grant Pulumi membership.

SAML 2.0

A SAML-backed organization draws its membership from the users your identity provider assigns to the Pulumi application. Pulumi Cloud works with any SAML 2.0 identity provider, including Microsoft Entra ID, Google Workspace, Okta, OneLogin, Auth0, and JumpCloud.

Configuring SAML is covered by the SAML SSO guides. Two things are specific to switching your organization to SAML:

• You become the organization owner. Pulumi makes the user who applies the SAML configuration the organization owner, so that an error in the identity provider metadata cannot lock everyone out of the organization.
• Your account cannot have other commitments. The admin who makes this change can't belong to other, unrelated Pulumi organizations. Pulumi rejects the switch to SAML otherwise, and the error surfaces at the last step of setup. Either have an admin who belongs only to this organization make the change, or leave the other organizations first. Your individual account must also not own any stacks or environments. Transfer or delete them first.

SCIM provisioning is available only for SAML-backed organizations, and the SAML & SCIM settings tab appears only once your organization is SAML-backed.

Members of a SAML organization can sign in with the organization name pre-filled by visiting https://app.pulumi.com/welcome/<organization-name>/sso.

Removing a third-party identity provider

You remove a third-party identity provider by selecting a different one — there is no “none” option. To go back to managing membership entirely in Pulumi Cloud, follow Changing your organization’s identity provider and select Pulumi.

This is also how you remove a SAML SSO configuration.

Learn more

• Accounts — linking third-party identities to your individual Pulumi account.
• Organizations — creating organizations, inviting members, and organization roles.
• SAML SSO — configuring Pulumi Cloud with a SAML 2.0 identity provider.
• SCIM — automating user and team provisioning from your identity provider.
• Organization settings scopes — the full list of organization-level RBAC permissions.