secretgen command

Status: Implemented Issue: https://gitlab.com/gitlab-org/charts/gitlab/-/work_items/6717 Parent: none

Goal

The chart’s shared-secrets Job generates its Secrets without a shell, with the generators of the GitLabSecrets controller. For the controller, see GitLab secrets.

Requirements

  • secretgen --manifest <file> reads the apps.gitlab.com/v2alpha1 GitLabSecrets document the chart renders, and writes its Secrets in metadata.namespace, or in the namespace of its client when the document sets none.
  • A document of another apiVersion or kind, with a field the command does not know, or with no Secret, fails before anything is written.
  • It generates, keeps, derives, and reports the keys of spec.secrets and spec.certificates as GitLab secrets does, except that it records no ready units: a missing data-bearing unit is generated, as in the shell Job.
  • It creates a missing Secret, and merge-patches an existing one with the keys it adds and the labels it changes. The patch fails when the Secret changed since it was read. It sets no owner reference.
  • Every declared Secret that exists after a run carries every label of metadata.labels, and keeps its other labels.
  • It writes a certificate set CA, TLS, chain, and stops at the first write that fails.
  • It plans every Secret, logs each report with its Secret, unit, and reason, and exits non-zero when a Secret is reported or cannot be read or written.
  • It connects with the ServiceAccount of its Pod, or with a kubeconfig outside a Pod.
  • It builds with no cgo and no build tags.
  • A build with GOFIPS140 or BoringCrypto exits with an error at startup when FIPS mode is off.

Out of scope

  • The container image, the version pin, and the CNG and hardened-builds packages. See ADR 45.
  • The chart side: rendering the document into the hook ConfigMap and running the command in the Job.
  • Removing the application labels when global.application.create is false, as the shell Job does.

FAQ

  • Why read the GitLabSecrets document? The chart already renders it for provider: controller, without the fields only the shell needs, with the certificate set, and with the labels. Its apiVersion and kind version the schema.
  • Where does it depart from the shell Job? Where the controller does, as the GitLab secrets FAQ lists, except the departures that need status. A reported Secret also fails the Job, where the shell Job leaves it alone or completes it.
  • Why fail the Job on a report? A report is the Job’s form of a Ready that is False. Installing with a Secret that is partial, or that does not parse, would leave Pods that cannot mount it.
  • What happens when a Secret changes while the command runs? The write fails, the command exits non-zero, and the next attempt of the Job plans the Secret again.
  • What happens when a certificate set is written only in part? Every later run reports the partial set, because the CA key is not stored. Delete the Secrets of the set that exist, and the next run issues a new set. The controller does the same.
  • What happens to a certificate set with ed25519 or an odd RSA keySize? The declaration is reported on every run, even for a complete set the shell Job issued, so the Job fails. Set selfsign.keyAlgorithm to rsa or ecdsa, with an even keySize, and delete the three certificate Secrets.