fix(secrets): seed image-gallery's role credential on GCP too - #2037
Merged
Merged
Conversation
The entry was appended under `if [ "$CLOUD" = "aws" ]`, which was correct when written: apps/base/complete was absent from apps/gcp-0/kustomization.yaml, the application reached S3 with its bucket hardcoded in the container environment, and gcp-0 had no image-gallery, no SQLInstance for it and no ExternalSecret reading the key. Seeding it there would have created a paid, unread secret. image-gallery v2 (#2022) made every clause of that false. apps/gcp-0 now includes ../base/complete, the app selects its backend with STORAGE_PROVIDER=gcs against a real GCS bucket, and gcp-0 has both the SQLInstance and the ExternalSecret. Observed on gcp-0 today: External Secrets could not read cnpg-xplane-image-gallery-roles-image-gallery-app, and both app replicas AND the CNPG initdb pod sat in CreateContainerConfigError naming a Kubernetes Secret. initdb needing that credential is what makes it a deadlock rather than an ordering problem — CNPG cannot seed a secret it requires in order to start, so nothing converges on its own. seed_body needed no change: its case pattern is `cnpg?xplane-image-gallery?roles?image-gallery-app`, where `?` matches either separator, so the generator half was already cloud-agnostic. Only GENERATABLE excluded GCP. Verified: `seed --cloud gcp` dry-runs to `cnpg-xplane-image-gallery-roles-image-gallery-app`, matching the key the cluster asked for; `seed --cloud aws` keeps the slash spelling unchanged. shellcheck -x -S warning is clean, and test-cloud-secret-store.sh and test-cnpg-promote-seed.sh both pass.
Contributor
🔍 Rendered manifest diff — this PR vs
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
GENERATABLEinscripts/secret-store.shgated image-gallery's CNPG role credential behindif [ "$CLOUD" = "aws" ]. This lists it unconditionally, so it resolves through_cnpg_sepon both clouds.Why
The gate was correct when written —
apps/base/completewas absent fromapps/gcp-0/kustomization.yaml, the app reached S3 with its bucket hardcoded in the container environment, and gcp-0 had no image-gallery, no SQLInstance for it and no ExternalSecret reading the key. Seeding it there would have created a paid, permanently-unread secret.image-gallery v2 (#2022) falsified every clause of that.
apps/gcp-0now includes../base/complete, the app selects its backend withSTORAGE_PROVIDER=gcsagainst a real GCS bucket, and gcp-0 has both the SQLInstance and the ExternalSecret.Observed
On gcp-0 today, after #2022 reached the cluster: External Secrets could not read
cnpg-xplane-image-gallery-roles-image-gallery-app, and both app replicas and the CNPGinitdbpod sat inCreateContainerConfigErrornaming a Kubernetes Secret.initdbneeding that credential is what makes this a deadlock rather than an ordering problem: CNPG cannot seed a secret it requires in order to start, so nothing converges on its own. That is precisely the failure the comment aboveGENERATABLEwarns about — "seeded here so a rebuild does not depend on someone remembering".Scope
seed_bodyneeded no change. Its case pattern iscnpg?xplane-image-gallery?roles?image-gallery-app, where?matches either separator, so the generator half was cloud-agnostic all along. Only the list excluded GCP. Nobao_target_forentry either: like the other twocnpg/*keys, this one stays in the cloud store because the SQLInstance composition hardcodessecretStoreRef.name: clustersecretstore, andmigratereports unmapped keys asskipped (unmapped).Verification
seed --cloud gcp(dry-run) resolves tocnpg-xplane-image-gallery-roles-image-gallery-app— character-for-character the key the cluster asked for.seed --cloud awskeeps the slash spelling, unchanged for aws-0.shellcheck -x -S warningclean; the two info-level findings (SC1091, SC2016 at lines 81 and 287) are identical before and after and predate this change.test-cloud-secret-store.shandtest-cnpg-promote-seed.shboth pass.After merge
scripts/secret-store.sh seed --cloud gcp --applycreates the secret. It never overwrites an existing one, so it is safe to re-run. Note the ORDER MATTERS warning inseed_body: CNPG fixes the role password when it creates the cluster — currently safe, becauseinitdbhas not run.