apiVersion: helm-expt.confighub.com/v1alpha1 kind: ChartLifecycleRoute metadata: name: bitnami-contour-21.1.4-certgen-lifecycle-route chart: bitnami/contour version: 21.1.4 # Hand-authored decision record (not generated). Read-only over committed live # receipts. Update by hand only when a fresh certgen-route receipt lands. authoredFrom: live G/P + K parity receipts (see spec.evidence) spec: summary: >- Contour ships a pre-install Helm hook Job (contour-contour-certgen) that generates the Contour<->Envoy xDS mutual-TLS material as the Secrets contourcert and envoycert at install time. Those Secrets are produced by the hook, not rendered as desired objects. The installer package now contains that chart-specific setup action. The legacy proof base has run it successfully before cub installer apply on a fresh cluster. The ordinary default image remains unavailable, and controller-native Argo and Flux execution still need their own receipts. hook: name: contour-contour-certgen kind: Job phase: pre-install produces: - secret: contourcert type: kubernetes.io/tls role: Contour xDS serving certificate - secret: envoycert type: kubernetes.io/tls role: Envoy xDS client certificate # For config-only delivery, the two Secrets are required target facts produced # by a lifecycle action. They are not ordinary rendered desired objects. certClassification: answer: lifecycle-operation-output isRenderedDesiredSecret: false isTargetFact: true evidence: - "The legacy G/P direct lane records both Secrets as lifecycle-action target facts." - "The legacy strict kind lane runs the packaged action and checks all six Secret keys before apply." - "Regular Helm runs contour-contour-certgen; neither Secret is part of the ordinary rendered manifest." explanation: >- contourcert and envoycert are outputs of the pre-install certgen hook Job, not part of the rendered desired object model. Config-only delivery records them as required target facts and runs the packaged lifecycle action to produce them before applying the ordinary objects. # The legacy proof base resolves this dependency with the frozen # bitnamilegacy image. The ordinary default and no-crds rows remain blocked on # their removed docker.io/bitnami images. blockedUpstreamBy: family: remote-image detail: >- docker.io/bitnami/contour:1.32.1-debian-12-r0 and docker.io/bitnami/envoy:1.34.5-debian-12-r0 are not pullable on a vanilla target. Regular Helm fails at the hook with "failed pre-install: resource Job/.../contour-contour-certgen not ready" (ImagePullBackOff). The legacy proof route pins the frozen docker.io/bitnamilegacy image; production use still needs a maintained mirror or replacement. see: data/image-digest-workdown/summary.md routeOptions: - name: stage-cert-secrets-as-target-facts what: >- Pre-create contourcert and envoycert (kubernetes.io/tls) on the target as declared facts before apply, replacing the hook output with staged material. Mirrors the proven generated-fact-staged-secret route already used for the ingress-nginx admission certificate. executionMode: user-executes requires: TLS key/cert material for the Contour and Envoy xDS identities patternProvenElsewhere: data/webhook-cert-lifecycle/summary.md - name: managed-certgen-action what: >- Run the chart's certgen ServiceAccount, RBAC, and Job as an explicit package action before applying the ordinary objects. The action checks both Secrets and removes its temporary resources. executionMode: direct-package-action-proven requires: a reviewed, pullable certgen image packageSource: packages/bitnami/contour/21.1.4/prerequisites/contour-certgen/run.sh controllerBoundary: Argo-native and Flux-native execution are not yet proven - name: refuse-until-proven what: >- Keep the base watch-grade and do not claim certgen support until a fresh receipt proves one of the routes above on a target that can pull the image. executionMode: target-owned disposition: current: watch defaultRoute: managed-certgen-action for the legacy proof base executionMode: packaged-direct-action automatic: false # the script is proven; ConfigHub, Argo, and Flux do not yet select and execute it automatically humanOfframp: run the packaged certgen action before applying the rendered objects agentOfframp: inspect requiredSecrets and run package://prerequisites/contour-certgen/run.sh proven: strictKind: base: legacy result: pass regularHelmHook: pass packagedDirectAction: pass outputSecrets: - contourcert - envoycert semanticObjectDiffs: 0 configHubComparison: base: legacy result: watch directAction: pass ociTargetStaging: pass workloadsReady: true objectParity: pass remainingWatch: Argo reports five already-present CRDs OutOfSync notYetProven: - Argo CD executes the certgen action as its own sync hook or wave - Flux executes the certgen action as its own ordered step - production image maintenance and certificate rotation policy evidence: gpDefault: runs/live-helm-confighub-compare/bitnami-contour-default/receipt.yaml gpNoCrds: runs/live-helm-confighub-compare/bitnami-contour-no-crds/receipt.yaml gpLegacy: runs/live-helm-confighub-compare/bitnami-contour-legacy/receipt.yaml kDefault: runs/live-kind-parity/bitnami-contour-default/receipt.yaml kLegacy: runs/live-kind-parity/bitnami-contour-legacy/receipt.yaml nextAction: >- 1) Replace the frozen proof image with a maintained, reviewed mirror. 2) Rehearse the same packaged action as an Argo CD sync wave and a Flux ordered dependency, recording each receipt separately. 3) Decide who owns certificate rotation before calling the route production-ready. seeAlso: # vocabulary for the remote-image + hook/lifecycle families (do not duplicate) - docs/reference/residue-families.md # the Contour rows in the live rerun queue - data/live-parity-rerun-plan/summary.md # the proven staged-cert route pattern (ingress-nginx admission cert) - data/webhook-cert-lifecycle/summary.md