## Problem The shared-secrets Job generates every secret with a bash script rendered from Helm templates ([templates/shared-secrets/job.yaml:53](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/2fc7f4741/templates/shared-secrets/job.yaml#L53), [_manifest_shell.tpl](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/2fc7f4741/templates/shared-secrets/_manifest_shell.tpl)). The certmanager-issuer Job also runs a bash script, a `kubectl apply` retry loop ([charts/certmanager-issuer/templates/issuer-job.yaml:36](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/2fc7f4741/charts/certmanager-issuer/templates/issuer-job.yaml#L36)). ### The script is the recurring source of shared-secrets bugs Most shared-secrets fixes in 2026 come from handling YAML, base64 and character sets as shell text: - Failures were silent until `set -e` and `pipefail` were added (https://gitlab.com/gitlab-org/charts/gitlab/-/work_items/6561, 8c1f075b6). - A stray comma in a `tr` character class put commas in Praefect passwords (e2ee6d67e). - Rails secrets with more than one `active_record_encryption` key were written with broken indentation (https://gitlab.com/gitlab-org/charts/gitlab/-/work_items/6639, 991545da8). - base64 random values above 57 characters had to be refused, because GNU `base64` wraps and command substitution strips newlines (e3101b03e). - Still open: a `db_key_base` list is read back through `yq` as text and written as a scalar, producing invalid YAML on the next upgrade (https://gitlab.com/gitlab-org/charts/gitlab/-/work_items/6709). None of these happen when the values are handled as data instead of text. The script is also never executed in tests. The specs ([spec/configuration/shared_secrets_spec.rb](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/2fc7f4741/spec/configuration/shared_secrets_spec.rb)) assert on the rendered text, for example that the awk indentation for a rotated key list is present ([L138-L149](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/2fc7f4741/spec/configuration/shared_secrets_spec.rb#L138-149)), so only a real deploy shows whether it produces correct Secrets. ### There are now two implementations of the same contract Since 785e2a867 the manifest ([_manifest.tpl](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/2fc7f4741/templates/shared-secrets/_manifest.tpl)) is the contract, and `provider: controller` hands it to the GitLab Operator. The Operator implements every generator in Go, with tests, including Rails secrets, SSH host keys and the self-signed certificates (`internal/secretgen`; https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/merge_requests/1735, https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/merge_requests/1737, https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/merge_requests/1741), and defaults to it (https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/merge_requests/1769). Every manifest change now has to be implemented twice and kept identical in shell and in Go. The chart already carries a spec whose only purpose is to stop the two from drifting ([the two backends stay in step](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/2fc7f4741/spec/configuration/shared_secrets_spec.rb#L285-328)), and e3101b03e is an example of a shell quirk (base64 wrapping) becoming part of the contract the controller must reproduce. One Go implementation used by both backends removes that class of problem. ### The script defines what the kubectl image must contain The result depends on the userland of whichever image runs the Job: bash, GNU coreutils behaviour (`base64 -w 0`, `head -c`, `tr`), awk, sed, openssl and ssh-keygen. CNG installs openssh, openssl and gawk into its kubectl images only for this Job ([kubectl/Dockerfile:18](https://gitlab.com/gitlab-org/build/CNG/-/blob/master/kubectl/Dockerfile#L18), [kubectl/Dockerfile.ubi:25](https://gitlab.com/gitlab-org/build/CNG/-/blob/master/kubectl/Dockerfile.ubi#L25)), so their vulnerabilities count against every kubectl image. A user who points `global.kubectl.image` at a minimal or distroless kubectl image gets a Job that fails to start. The hardened CNG images are one such case (https://gitlab.com/gitlab-org/software-supply-chain-security/hardened-builds/-/work_items/31, which adds the tools to that image as a stopgap). ## Proposal 1. shared-secrets: add a shell-free Job backend. Render the manifest into the ConfigMap as data, and run a small Go binary built on the same generators as the Operator controller. Same semantics as today: fill only missing keys, never overwrite, no owner references, same labels. One implementation then serves both `provider: job` and `provider: controller`. 2. certmanager-issuer: replace the script with `command: [kubectl, apply, -f, ...]`, and rely on the Job `backoffLimit` for the retry while the cert-manager CRDs are not yet established. 3. Ship the binary in the CNG kubectl image, make the new backend the default for `provider: job`, then drop openssh, openssl and gawk from the kubectl images. ## Open questions - Where the binary lives. `internal/secretgen` cannot be imported from another module, so either the Operator builds and releases the CLI, or the package moves to an importable path. - Whether to keep the shell backend for one deprecation cycle. - Whether the self-signed certificate Job ([self-signed-cert-job.yml](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/2fc7f4741/templates/shared-secrets/self-signed-cert-job.yml)) should move to the same binary, since `secretgen` already covers it. ## Not considered Helm template functions (`genPrivateKey`, `randAlphaNum`, `lookup`): the values would be stored in the Helm release, and `lookup` returns nothing under `helm template` and Argo CD. ## Acceptance criteria - A fresh install and an upgrade with `provider: job` generate the same Secrets as today, with no shell in the Job container. - The generators are executed in tests, and shared with the Operator controller. - certmanager-issuer creates the issuer with no shell in the Job container. - The CNG kubectl image needs only kubectl for the chart.