Networking and Data Flows in Enterprise

Enterprise was designed with the goal of minimizing data inflows and relying mostly on data outflows to operate. This reduces the number of external access points, thus reducing the potential attack surface.

Data flows

The following is a summary of the data flows that can be expected coming into and going out of a Enterprise instance.

Outgoing flows include:

• Making calls and sending heartbeats to the Substrate API (Enterprise Control Plane) in order to send status updates and to check for available updates
• Sending out observability data for support purposes

Incoming flows include:

• Downloading images from ECR/Docker to update Gitpod

Connectivity Requirements:

For Gitpod to function, the following services need to be reachable from the instance at a minimum:

When using All Private networking mode (described below), the customer is responsible for ensuring connectivity to all of these unless they choose the “public services” option which exposes an endpoint for OIDC and webhooks.

• Login via SSO (outbound connectivity only): This feature allows users to log into the instance when using SSO via OIDC (default). Only outbound connectivity is needed as the callback URL is resolved on the users machine rather than within the Gitpod Instance. If the provider for SSO is only available on the public internet, this means the instance requires an outward route to the internet.

• Git provider (outbound connectivity always required, inbound connectivity for prebuilds): This feature enables users to see the contents of their Git repos and for enabling prebuilds. For prebuilds, inbound connectivity is required as they use webhooks to be triggered. If the git provider is only available on the public internet (e.g. Gitlab.com), this means the instance requires an inbound and outbound connection to the public internet.

• Identity Provider (IDP) connectivity (inbound and outbound connectivity): IDP connectivity (both inbound and outbound) is required to enable OIDC from within workspaces. This allows workspaces to connect and authenticate with third party services such as AWS. If the IDP is only available on the public internet, this means the instance requires an inbound and outbound connection to the public internet.

• VS Code (in the browser, outbound connectivity only)

  Source	Description	Domain
  Extension management	For searching, installing and updating vscode extensions.	https://open-vsx.org/ https://open-vsx.gitpod.io/ https://openvsxorg.blob.core.windows.net/
  JSON Language Features (built-in extension)	For the JSON extension to properly work and provide IntelliSense and validation.	https://www.schemastore.org/json/

• JetBrains (outbound connectivity only)

  Source	Description	Domain
  Extension and client management	For access to the marketplace and downloading JetBrains clients/backends	https://download.jetbrains.com/ https://download-cf.jetbrains.com/ https://download-cdn.jetbrains.com/ https://data.services.jetbrains.com/

• AWS Services (outbound connectivity only): Gitpod services should be able to access AWS services like ECR, s3, Dynamo, Private API Gateway, etc. To allow this, your network should have outbound connectivity to all AWS service endpoints. So allowing *.aws.amazon.com and *.amazonaws.com is necessary for smooth functioning.

• Gitpod components: To allow communication between Gitpod components, you will have to allow communication to your Gitpod domain name. If your Gitpod instance domain name is yourcompany.gitpod.cloud, please do allow communication to and from yourcompany.gitpod.cloud and *.yourcompany.gitpod.cloud always.