Aller au contenu

Gitlab D&D#

This sections is about our integrations with Gitlab D&D.

It is a Gitlab instance provisioned by Digital and Data orange team. Its url is: (https://sourcecehub.orange-business.com)

Projects and instances#

Via DT Store we provisioned several projects:

  • cloudservicesfactory
  • cloudservicesfactory stg
  • MCS NGOT deprecated

These projects as two gitlab instances (internal and external) This document is applicable to external Gitlab only.

As our services are unable to reach OBS internal zone, we have built a CI model for NGOT Gitops workflow and maybe other future usages around the external Gitlab instance.

Limitations on the external zone#

  • We cannot have Vault approle on Vault external instance, thus it is not possible to automate secrets creation on this service. external Vault instance does not provide approles.

  • Gitlab instance will use Vault instance in the same zone for its CI templates and cannot be connected to another trusted source.

  • The external zone can neither talk to the internal zone and thus cannot use internal Vault instance.

Architecture#

To overcome this limitation we have decided to provide to the Gitlab a static secret.

It will be an approle secret generated by infra zone Vault, to simplify this approle has the same scope as the one trackbone uses while in CI. While rendering our templates Gitlab CI will write those approle in our jobs. The job run context will then be able to talk to our infra one Vault.

To ensure Gitlab Workers connectivity with all of our API we have built a Gitlab D&D external worker on our infra zone CCE cluster. Sharing the same network than our current Concourse CI ensures that Gitlab CI may run any Concourse Job.

Finally we have asked D&D to whitelist our infra zone NAT GW to ensure the Gitlab worker is able to reach Gitlab D&D external instance.

Example: trackbone workflow#

Trackbone workflow network stream

The runner is deployed in infra zone and is able to talk to infra vault, git corp and reach any bastion proxy machine.

The workflow is described as this:

  • An operator ask for a trackbone approle secret
  • An operator stores the approle in gitlab secret
  • An operator uses Gitlab CI jobs templating to retrieve the approle and send a job to our runner
  • the runner receives the jobs by pulling Gitlab D&D and starts task (trackbone, kubectl, helm, etc.)
  • job talks to Gitlab Corp and Infra Vault to build providers
  • job produces a ssh tunnel through NGOT admin bastion proxy (bst.admin-...) to connect to k8s apis
  • job configures applications

Approle#

The approle is managed through infra-.../keycloak-vault-infra envs-ng configuration which uses keycloak-vault-infra terraform configuration.

The approle has been stored in auth/approle/role/cscd-app-trackbone-for-d-and-d