Add admin_app_db_password to Salt pillar (gates pal-e-platform#302 apply) #306

New issue

Closed

opened 2026-04-26 00:02:36 +00:00 by forgejo_admin · 0 comments

forgejo_admin commented

2026-04-26 00:02:36 +00:00

Contributor

Type

Chore

Lineage

Discovered scope from Track D (#302 admin_app k8s Job, PR #304 merged 2026-04-25) of westside-admin bootstrap. Operator step required before make tofu-apply succeeds.

Repo

forgejo_admin/pal-e-platform (pillar lives in this repo at salt/pillar/secrets/platform.sls)

User Story

story:admin-row-crud — As the operator running make tofu-apply on pal-e-platform after PR #304 merged, I need admin_app_db_password rendered into secrets.auto.tfvars so the new kubernetes_job_v1.admin_app_user_provision and kubernetes_secret_v1.admin_app_db_url resources can plan/apply, otherwise the apply fails on the missing variable.

Architecture

arch:salt

Context

PR #304 added a new terraform variable admin_app_db_password (declared in terraform/variables.tf and consumed in terraform/modules/database/variables.tf). The Makefile diff already adds it to TF_SECRET_VARS so make tofu-validate-secrets will block apply until this lands. The operator workflow renders secrets.auto.tfvars from the Salt pillar via make tofu-apply (existing convention).

The actual sibling password to mirror is paledocs_db_password (lines 281-298 of salt/pillar/secrets/platform.sls) — same #!yaml|gpg renderer, same secrets.platform.<key>: | schema, same multi-line PGP MESSAGE block. Single source: make tofu-secrets calls salt-call pillar.get secrets:platform, no environment overlays to coordinate.

File Targets

~/pal-e-platform/salt/pillar/secrets/platform.sls — add GPG-encrypted entry for admin_app_db_password mirroring the paledocs_db_password block at lines 281-298

Acceptance Criteria

admin_app_db_password exists in salt/pillar/secrets/platform.sls, GPG-encrypted, with a strong generated value (openssl rand -base64 32 or equivalent)
make tofu-secrets (or make tofu-validate-secrets) reports the variable present
make tofu-apply (after PR #304 merged) runs without prompting for the variable
Password generation procedure documented in commit message (length, charset, source)

Test Expectations

Operator runs make tofu-apply end-to-end without manual intervention for this variable
The resulting kubernetes_secret_v1.admin_app_db_url contains the same password as the Job uses to CREATE ROLE

Constraints

Password MUST be GPG-encrypted in the pillar (matches paledocs_db_password pattern)
MUST NOT commit the plaintext value anywhere
Coordinate timing: pillar entry must exist before next make tofu-apply runs

Checklist

Reviewed via /review-ticket and moved backlog → todo
Pillar entry added (encrypted), mirroring paledocs_db_password pattern
Verified make tofu-apply runs clean
Operator notes added to apply runbook

Blocks: pal-e-platform PR #304 apply (apply, not merge — PR is merged)
Triggered by: Track D dev agent report
Sibling pattern: paledocs_db_password at salt/pillar/secrets/platform.sls:281-298
Memory: feedback_discovered_scope_always_tracked

### Type Chore ### Lineage Discovered scope from Track D (#302 admin_app k8s Job, PR #304 merged 2026-04-25) of westside-admin bootstrap. Operator step required before `make tofu-apply` succeeds. ### Repo forgejo_admin/pal-e-platform (pillar lives in this repo at `salt/pillar/secrets/platform.sls`) ### User Story story:admin-row-crud — As the operator running `make tofu-apply` on pal-e-platform after PR #304 merged, I need `admin_app_db_password` rendered into `secrets.auto.tfvars` so the new `kubernetes_job_v1.admin_app_user_provision` and `kubernetes_secret_v1.admin_app_db_url` resources can plan/apply, otherwise the apply fails on the missing variable. ### Architecture arch:salt ### Context PR #304 added a new terraform variable `admin_app_db_password` (declared in `terraform/variables.tf` and consumed in `terraform/modules/database/variables.tf`). The Makefile diff already adds it to `TF_SECRET_VARS` so `make tofu-validate-secrets` will block apply until this lands. The operator workflow renders `secrets.auto.tfvars` from the Salt pillar via `make tofu-apply` (existing convention). The actual sibling password to mirror is **`paledocs_db_password`** (lines 281-298 of `salt/pillar/secrets/platform.sls`) — same `#!yaml|gpg` renderer, same `secrets.platform.<key>: |` schema, same multi-line PGP MESSAGE block. Single source: `make tofu-secrets` calls `salt-call pillar.get secrets:platform`, no environment overlays to coordinate. ### File Targets - `~/pal-e-platform/salt/pillar/secrets/platform.sls` — add GPG-encrypted entry for `admin_app_db_password` mirroring the `paledocs_db_password` block at lines 281-298 ### Acceptance Criteria - [ ] `admin_app_db_password` exists in `salt/pillar/secrets/platform.sls`, GPG-encrypted, with a strong generated value (`openssl rand -base64 32` or equivalent) - [ ] `make tofu-secrets` (or `make tofu-validate-secrets`) reports the variable present - [ ] `make tofu-apply` (after PR #304 merged) runs without prompting for the variable - [ ] Password generation procedure documented in commit message (length, charset, source) ### Test Expectations - Operator runs `make tofu-apply` end-to-end without manual intervention for this variable - The resulting `kubernetes_secret_v1.admin_app_db_url` contains the same password as the Job uses to CREATE ROLE ### Constraints - Password MUST be GPG-encrypted in the pillar (matches `paledocs_db_password` pattern) - MUST NOT commit the plaintext value anywhere - Coordinate timing: pillar entry must exist before next `make tofu-apply` runs ### Checklist - [ ] Reviewed via /review-ticket and moved backlog → todo - [ ] Pillar entry added (encrypted), mirroring paledocs_db_password pattern - [ ] Verified `make tofu-apply` runs clean - [ ] Operator notes added to apply runbook ### Related - Blocks: pal-e-platform PR #304 apply (apply, not merge — PR is merged) - Triggered by: Track D dev agent report - Sibling pattern: `paledocs_db_password` at `salt/pillar/secrets/platform.sls:281-298` - Memory: `feedback_discovered_scope_always_tracked`