Description
Bug description
Currently if one installs Gitpod via a private registry (in airgap) we silently enforce that registry as the place to store user images, by overwriting the gitpod install yaml instead of surfacing the options in the configuration screen.
Since we want users to use the kots installer screen, at minimum this information should be exposed there.
This also complicates situations where some users can docker pull from the URL, but it's not the same URL to get an HTTP status of the image, due to networking and proxy limitations. The result is kubernetes can deploy from it, but registry facade's own status checks fail against it.
Steps to reproduce
Install gitpod in airgapped mode, block port 80 access to a target registry from the POD network, but not the Node network, and see that the services can be deployed, but now the services themselves (running in the PODs) can't access the same registry.
Workspace affected
No response
Expected behavior
The Container Registry our configuration page displays explains that this is where gitpod needs to store container images, mostly for user workspaces. One would expect this could be a separate registry than where Gitpod is installed from and can be configured separately.
Example repository
No response
Anything else?
The fact that in an airgapped installation Gitpod will store an image built by a user alongside where it retrieves the images for it's own services has multiple consequences:
- Opens a security issue where it would be possible for a user generated image to be deployed in place of a gitpod service (ie, a custom version of agent-smith), if other vulnerabilities were found in the workspace generation process.
- Ideally Gitpod's Service registry would be one restricted to read only access to Gitpod, to ensure it can't overwrite it's own services, by accident or intentionally
- Gitpod's service images and end-user workspace images have lifecycle needs: workspaces can grow exponentially in numbers and size while service images would remain static with monthly updates and pruning of previous versions. These could be entirely different registries for optimal cost savings and auditing depending on the kinds of registries the customers are using.
Scenarios
There are two different uses of Registries for Gitpod: Service Images and User Images. A solution should consider the following iterations when being developed:
- Same registry, same credentials, same namespaces because it's all considered untrusted content (current scenario)
- Same registry, same credentials, different namespaces for Service vs User: The namespaces enforce restrictions, gitpod user only has read access to Service images
- This implies that a different process and/or credentials are used to upload the airgapped images, so we can't assume we can copy the information from KOTS
- Same registry, different credentials, same namespace: much less likely, but still feasible
- Different registry, different credentials, same namespace: artifactory/gitpod for services, acr/gitpod for images
- Different registry, different credentials, different namespace