Add artifactRegistry to appConfig

Narendranrequested to merge
narendran/artifact-registry-appconfig into master

What does this MR do?

Introduces an optional Artifact Registry integration under global.appConfig.artifactRegistry, rendering the artifact_registry: section into gitlab.yml and projecting the shared service token into the webservice, Sidekiq, and toolbox pods.

Modelled on iam_data_access_service (!5125 (merged)), with three differences that follow from what Rails reads and from who owns the token:

  • The rendered block is gated. An install that leaves the block unset gets no artifact_registry key at all, rather than one with an empty api_url. A rendered api_url: "" is a meaningless key in a file operators read and diff, and it makes an unconfigured install look configured.
  • Only keys Rails reads are emitted, so no enabled: lands in gitlab.yml. Rails does not read one for this integration, and a key nothing consumes is a false affordance.
  • The chart does not generate the token. The same value is configured on the Artifact Registry service, which validates incoming requests against its own copy, so a chart-minted secret would authenticate against nothing and every call would return 401. authToken.secret names a Kubernetes Secret the operator supplies, and shared-secrets is untouched.

One decision the precedent does not cover: apiUrl is the only field checkConfig requires when the block is enabled. An environment may be given the endpoint before the shared token exists, which is the order the rollout imposes; Rails then fails closed on the calls that authenticate as the service, while user-facing calls are unaffected.

Note that service_token.secret_file is a nested mapping, unlike the flat iam_data_access_service.secret_file. That is the key Rails reads.

This input:

global:
  appConfig:
    artifactRegistry:
      enabled: true
      apiUrl: https://artifact-registry.example.com
      authToken:
        secret: gitlab-artifact-registry-credential
        key: token

renders, in all three gitlab.yml.erb ConfigMaps:

artifact_registry:
  api_url: "https://artifact-registry.example.com"
  service_token:
    secret_file: /etc/gitlab/artifact-registry/.gitlab_artifact_registry_secret

The settings keys this renders are added Rails-side in gitlab-org/gitlab!252017 (merged), a separate MR. The two are independent: the chart may render a key Rails does not yet read, the way it already renders an enabled: key for IAM that Rails ignores.

Related issues

Related to gitlab-org/gitlab#619471 (closed)

Author checklist

For general guidance, please follow our Contributing guide.

Required

For anything in this list which will not be completed, please provide a reason in the MR discussion.

  • Merge Request Title and Description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • MR has a green pipeline.
  • Documentation created/updated.
    • doc/development/artifact_registry.md, plus its entry in doc/development/_index.md, following the IAM Data Access page.
  • Tests added/updated.
    • spec/configuration/artifact_registry_spec.rb, 12 examples: the three render states (unset, URL only, URL plus token), the projected volume across all three deployments, the checkConfig failure, and that no token is generated. One assertion has no equivalent in the IAM spec: the mounted path is spelled independently in the projected volume, in the rendered secret_file, and in the $optional list in _configure.tpl, so the spec compares the three to each other rather than each to a literal it supplies. A drift between them otherwise means the file silently never appears.
  • Have you validated that your change works end-to-end on a real cluster deployment?
    • Not done. Verified by rendering rather than by deploying: helm template with the block unset, with apiUrl only, and with apiUrl plus authToken.secret, checking the rendered gitlab.yml.erb in all three ConfigMaps and the projected volume in all three Deployments, plus the checkConfig failure path. Details in the Verification comment below. A cluster deployment would additionally exercise the secret mount, which no Artifact Registry environment is reachable for from here: the Rails side that consumes the file is still open in gitlab-org/gitlab!252017 (merged).
  • Equivalent MR/issue for omnibus-gitlab opened.

Reviewers checklist

Edited by Clemens Beck

Merge request reports