Modeling Identity and Access Management with Gitpod: SSO, SCM, and OIDC explained

Lou Bichard Product Manager at Gitpod

Feb 14, 2024

Moving your development environments to the cloud using a Cloud Development Environment (CDE) like Gitpod brings not only productivity benefits, but also security benefits. Standardizing your development environments ultimately can ensure that “the easy way is also the right way” for your developers.

You don’t have to compromise productivity for security—or vice versa.

Gitpod defers to your sources of truth for identity and access management (SSO for auth, SCM for repositories and OIDC for cloud and secret access). Through the combination of these three, you can create and apply a “defense in depth” strategy for your development environments in Gitpod ensuring only the right people have the right access at the right time. This article breaks down the big three integrations with Gitpod: SSO, SCM and OIDC.

Note: This blog will not cover network level access controls such as VPNs and other cloud network controls like VPCs, which can also be configured on top of the constructs we discuss today.

Modeling Identity in Gitpod

When a user access a workspace they go through the following:

1. Authentication - Authenticate through a configured SSO provider.
2. Repository Access - Open workspaces for repositories the user can access.
3. Secrets Access - Optionally fetch secrets from a 3rd party (e.g. Vault).

These layers work together for a “defense in depth” strategy for identity and access in Gitpod. Here’s how that looks represented as a flow chart:

The above diagram shows how a user accesses a Gitpod workspace and how the subsequent systems like SCM and cloud access are granted to a workspace, where each point surfaces an opportunity to restrict access and layer in security.

Today we’ll go through each one of these three integrations, to see how Gitpod connects to these sources of truth for identity and access in Gitpod.

Authenticating to Gitpod via Single Sign On (SSO)

Gitpod integrates with your existing SSO provider. Gitpod currently supports Google, Okta, Azure AD and AWS Cognito as Identity Providers (IdP). When Gitpod is configured with SSO, you retain full control over who can access your Gitpod installation. SSO makes onboarding and offboarding your developers within Gitpod seamless.

1. Only users with access granted via SSO can access Gitpod.
2. To revoke access to Gitpod, you can do so directly from your SSO provider.

Once a user has authenticated into Gitpod via SSO, only the repositories the user has access to can be started in their workspaces. Then, when starting a workspace, only credentials or secrets that are included in the OIDC trust policy for the workspace can then be accessed.

Connecting Gitpod to Source Control (SCM)

When a user requests a Gitpod workspace they specify a repository as the context for that workspace. If the user does not have the necessary access permissions for the repository, the Gitpod workspace will not start. Gitpod workspaces are started with the context of a user, and access is not granted for repositories at the installation level.

1. Gitpod workspaces are authenticated with git based on users permissions.
2. Without access to a repository, a user cannot start the workspace in Gitpod.
3. A user will only see repositories in Gitpod when they have SCM access.

Read how Authentication works in Gitpod.

Accessing Secrets from Gitpod Workspaces (OIDC)

Gitpod workspaces can make use of the OIDC integration and can access secrets from any public cloud provider, or secrets manager like vault. Trust rules are established inside the secrets management tool. For AWS, the OIDC exchange results in an STS token that can be used to access any AWS resource that is configured in the IAM trust policy.

1. Trust policy rules are established in the 3rd party, e.g. AWS and Vault.
2. You can establish trust policies based on specific individuals or repositories. I.e. you can define that a specific user(s) can access certain resources, or all users with access to a repo can access certain resources.
3. Only resources identified in your OIDC trust policy can be accessed.

Note: Whilst related, the workspace OIDC integration is not to be confused with the SSO authentication for Gitpod. Claims for generated workspace OIDC token are based on both your connected identity provider, and the connected SCM.

Read more about Workspace OIDC and AWS Integration.

Secure Development Environments

Through a combination of the above three mechanisms (SSO, SCM and OIDC) you ensure that only users with: the required authentication via SSO, repository access in SCM and secrets access via OIDC can start workspaces and access sensitive resources inside their development environments.

Get started with Gitpod Enterprise.