Migrate current Gemnasium service to GitLab infrastructure
Description
In %10.5 we'll start providing some security scans powered by Gemnasium tools that rely on an external service to get vulnerabilities and dependencies information. This service is now already running on a OpenShift infrastructure not directly managed by us, but this service will be dismissed in a few months.
The plan is to migrate the service mostly as-is to the GitLab infrastructure to ensure we can continue to provide this service. Following steps will be to consider adding this service as part of the product instead of just part of the infrastructure.
The current service architecture is microservices-oriented, so this should help in our GCP Migration, but this should be evaluated anyway from a technical point of view. Since this is a standalone service that should be available to anyone from anywhere, it doesn't require to be moved on GCP at the same time as GitLab.com but can be considered separately.
Plan
First phase:
-
Create a new DNS entry for security checks by gl-sast: https://gitlab.com/gitlab-com/infrastructure/issues/3617 -
Create a new SSL cert for deps.sec.gitlab.com: gitlab-com/infrastructure#3619 -
Change sast
in order to use a different hostname for the Gemnasium client: https://gitlab.com/gitlab-org/security-products/sast/issues/20 -
Create a staging environment for the database in the GitLab infrastructure: https://gitlab.com/gitlab-com/infrastructure/issues/3614
Second phase:
-
Create a new eval
(API) endpoint in the GitLab infrastructure, with limited access to the original database -
Use the new endpoint for gl-sast
request -
Migrate all the data (except the user information) to the new database -
Make the new endpoint using the new database
Before anything will be promoted to production use on GitLab owned infrastructure, the Production band and the Security Products band should sync and agree on a plan.