Import identity provider groups into Astro Private Cloud

You can import existing identity provider (IdP) groups into Astro Private Cloud as Teams, which are groups of Astro users that have the same set of permissions for a specific Workspace or Deployment. Configuring Teams lets you quickly onboard staff to APC and provides better control of user permissions.

APC Teams function similar to users. You can:

Assign Teams to both Workspaces and Deployments.
Assign Viewer, Editor, or Admin roles to a Team.
View information about users and permissions from the UI.

After you configure SCIM, you can use templates to add or remove Teams on Astro Private Cloud and manage groups of users directly from your IdP. However, if SCIM is not available, you can pre-populate groups via the UI or API following the procedure for Create local teams. With either process, when you create new user groups in the future, you can automatically apply a batch of permissions that they need to access Astro Private Cloud.

Implementation considerations

Before you implement Teams, consider the following:

By default, the first user to log in to your Astronomer platform is automatically granted SYSTEM ADMIN permissions. If you configure Teams for a new Astronomer installation, Astronomer recommends logging in first as the user responsible for importing your IdP groups using Astronomer’s default login flow.
Teams are based solely on the IdP group they are configured from, which means that you can’t configure Team membership from Astronomer.
To remove a Team from your installation, you have to delete it from the Astro Private Cloud UI or the Houston API. Deleting an IdP group from your IdP UI doesn’t automatically delete the associated Team.
If a user is added or removed from your original IdP group, that change applies to the related Astronomer Team only after the user logs back in to Astronomer.

Most Permissive Role Priority

Astronomer user roles function on a most permissive policy: If a user has roles defined at both the Workspace and the Team level, then that user will continue to have the most permissive role between the two contexts. This policy has a few implications for implementing Team:

If a user’s most permissive role comes from a Workspace configuration, there is no way to override/ remove this permission from a Team configuration.
If a user’s most permissive role comes from a Team configuration, then there is no way to override/ remove this permission from a Workspace configuration.
Importing a Team from an IdP has no effect on existing Astronomer user roles. Users continue to have permissions from both contexts, with the most permissive role defining how they interact with a given Workspace or Deployment.

For example, consider a user with Workspace Editor permission in a Production Workspace via Astronomer’s default authentication for the last year. Your organization begins using Okta as your authentication system for Astronomer and adds this user to a Team with Workspace Viewer permissions in Production Workspace. Because the user still has Workspace Editor permissions from their original account, they continue to have Workspace Editor permissions in Production Workspace. The only way to remove their Editor permissions is to have a Workspace Admin remove them through Workspace settings.

Prerequisites

To complete this setup, you need:

A configured third party identity provider. See Integrate an auth system.
System Admin permissions for configuring the feature.
Workspace or Deployment Admin permissions for managing Teams.
An OAuth authorization code flow. See Configure a custom OAuth flow.
An IdP group.

Astronomer also recommends setting up SCIM so that you can manage user groups as Teams directly from your IdP.

Step 1: Enable APC Teams

In your values.yaml file, set the following value.

1 # Auth configuration.
2 auth:
3   openidConnect:
4     idpGroupsImportEnabled: true
5     # Optional configuration. Set to assign System-level permissions using Teams.
6     manageSystemPermissionsViaIdpGroups:
7       enabled: true
8       systemAdmin: ["<your-system-admin-groups>"] // Only these groups will be treated as SysAdmin Groups
9       systemEditor: ["<your-system-editor-groups>"]
10       systemViewer: ["<your-system-viewer-groups>"]

Save this configuration and push it to your platform as described in Apply a Platform Config Change.

Step 2: Add a group claim to your IdP group

To add your IdP group to Astronomer as a Team, Astronomer needs to be able to recognize the IdP group through a group claim and assign members from the group through tokens.

If you haven’t already, add group claims to the IdP groups that you’re importing to Astronomer through your configured third party identity provider. Refer to your IdP’s documentation for information on how to complete this step. For example, for Okta you can refer to Customize tokens returned from Okta with a Groups claim.

By default, Astronomer assumes that the name of your group claim is groups. If you named your group claim something other than groups, complete the following setup:

In your values.yaml file, set houston.config.auth.openidConnect.<idp-provider>.claimsMapping to the custom name of your group claim.
Save this configuration and push it to your platform. See Apply a Platform Config Change.

Step 3: Add Teams to Workspaces and Deployments

In the UI, open the System Admin menu, then click Teams.
Click Create Team.
Give the team a name and a description, choose the Provider that you use for your IdP, and add users to your Team.

After configuring and importing user groups, Workspace Admins and Deployment Admins can configure those groups as Teams using the UI. You can add Teams to Workspace and Deployments in the same way that you add individual users.

Create local Teams

If you want to create a Team of Astronomer users, and the team doesn’t map to a group in the IdP, you can enable local team creation. This means that if SCIM sync is not available, you don’t have to wait for a user to log in to Astro Private Cloud for their IdP user groups to sync. You can instead create teams using a locally available source of users.

To enable the feature, add the following configuration to your values.yaml file and apply the change to your installation.

1 astronomer:
2   houston:
3     config:
4       # Auth configuration.
5       auth:
6       # Local database (user/pass) configuration.
7         local:
8           enabled: true
9           teams:
10             enabled: true

Then, to create a local Team:

In the UI, open the System Admin menu, then click Teams.
Click Create Team.
Give the team a name and a description, then select all the users that you want in the Team.
(Optional) Grant the Team a System Level Role if the Team needs system-level permissions.

You can now add the local Team to a Workspace or Deployment as you would with an IdP Team or an individual user.

Disable individual user management

To use Teams as the only user management system on Astro Private Cloud, add the following entry to your values.yaml file:

1 astronomer:
2   houston:
3     config:
4       userManagement:
5         enabled: false

Save this configuration and push it to your platform. See Apply a Platform Config Change.

After you apply the configuration, individual users can’t be invited or assigned Workspace or Deployment-level roles in Astro Private Cloud. Users must be invited through a Team by a System Admin, and only Teams can be assigned roles for Workspaces and Deployments. You can still create individual service accounts with Workspace and Deployment permissions.