Add Hetzner edge node secrets to Salt GPG pillar

ldraney commented

2026-06-13 08:25:28 +00:00

Owner

Summary

GPG-encrypt hetzner_api_token and edge_ssh_public_key into salt/pillar/secrets/platform.sls
Required for tofu apply of the hetzner-edge module (PR #420)

Changes

salt/pillar/secrets/platform.sls — add two GPG-encrypted entries: hetzner_api_token (Hetzner Cloud API token) and edge_ssh_public_key (SSH public key for edge VPS)

Test Plan

make tofu-secrets generates secrets.auto.tfvars with both values
tofu plan shows expected resources (server, SSH key, firewall)

Review Checklist

No secrets committed in plaintext
GPG encryption uses correct Salt Master key (81A03D1CF874DC90)
Commit messages are descriptive

Closes #419 (secrets provisioning follow-up)
ldraney/pal-e-platform #420 — Terraform module this enables

## Summary - GPG-encrypt `hetzner_api_token` and `edge_ssh_public_key` into `salt/pillar/secrets/platform.sls` - Required for `tofu apply` of the hetzner-edge module (PR #420) ## Changes - `salt/pillar/secrets/platform.sls` — add two GPG-encrypted entries: `hetzner_api_token` (Hetzner Cloud API token) and `edge_ssh_public_key` (SSH public key for edge VPS) ## Test Plan - [ ] `make tofu-secrets` generates `secrets.auto.tfvars` with both values - [ ] `tofu plan` shows expected resources (server, SSH key, firewall) ## Review Checklist - [ ] No secrets committed in plaintext - [ ] GPG encryption uses correct Salt Master key (81A03D1CF874DC90) - [ ] Commit messages are descriptive ## Related Notes - Closes #419 (secrets provisioning follow-up) - `ldraney/pal-e-platform #420` — Terraform module this enables

ldraney added 1 commit

2026-06-13 08:25:28 +00:00

Add Hetzner edge node secrets to Salt GPG pillar

ci/woodpecker/push/terraform Pipeline was successful

Details

ci/woodpecker/pr/terraform Pipeline was successful

Details

ci/woodpecker/pull_request_closed/terraform Pipeline was successful

Details

3c5f666297

GPG-encrypt hetzner_api_token and edge_ssh_public_key for the
hetzner-edge Terraform module (PR #420).

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

ldraney commented

2026-06-13 08:27:06 +00:00

Author

Owner

PR #421 Review

DOMAIN REVIEW

Tech stack: Salt pillar (GPG-encrypted YAML), Terraform/OpenTofu secrets pipeline.

GPG encryption correctness:
Both encrypted blocks begin with hQIMA4GgPRz4dNyQAQ/, which encodes recipient key ID 81A03D1CF874DC90 -- this matches the documented Salt Master GPG key in arch-secrets-pipeline and sop-secrets-management. Correct key used.

Pillar structure:
The new entries are properly indented under the secrets: top-level key, use YAML literal block scalars (|), and include complete -----BEGIN/END PGP MESSAGE----- delimiters. Formatting is consistent with the existing 505 lines of the file.

Naming:

hetzner_api_token -- clear, follows existing snake_case convention.
edge_ssh_public_key -- clear, descriptive.

Both names are appropriate for TF_SECRET_VARS allowlist consumption.

BLOCKERS

1. Missing secrets_registry.sls metadata entry (SOP step 4 -- always required)

Per sop-secrets-management, Steps 1-4 are the "canonical backup layer" and are always required regardless of delivery path:

Step 4: Add metadata entry to salt/pillar/secrets_registry.sls

The registry tracks origin, rotation schedule, and provider for every secret. This PR adds two new secrets to the pillar but does not update the registry. The SOP is explicit: "Full metadata for every secret (origin, rotation schedule, provider) lives in salt/pillar/secrets_registry.sls. Check there before creating new secrets."

Both hetzner_api_token and edge_ssh_public_key need registry entries with at minimum: origin (External - Hetzner console / Generated), rotation_days, and purpose.

2. Missing TF_SECRET_VARS Makefile allowlist update

Per arch-secrets-pipeline, the rendering pipeline filters secrets through the TF_SECRET_VARS allowlist in the Makefile before writing secrets.auto.tfvars. If these two keys are not added to the allowlist, make tofu-secrets will NOT render them to tfvars, making the PR body's test plan (make tofu-secrets generates both values) impossible to pass without a Makefile change.

Unless the Hetzner edge module uses a separate rendering path not documented in the architecture note, this is a missing change.

NITS

Plaintext backup (SOP step 2): The SOP requires storing plaintext in ~/secrets/{service}/{name}.env. Not verifiable from PR diff, but worth confirming this was done before merge.
Woodpecker CI sync: Per the SOP section "Keeping Salt and CI in Sync," if the Hetzner edge module will eventually run via CI (Woodpecker tofu plan/apply), corresponding Woodpecker repo secrets (tf_var_hetzner_api_token, tf_var_edge_ssh_public_key) will need to be created. If this is host-side only (manual apply), this can be deferred, but should be noted.
SOP update (step 10): The SOP itself should be updated with these two new secrets in the registry tables once they are finalized.

SOP COMPLIANCE

PR body has Summary, Changes, Test Plan, Related -- all present and well-structured
No secrets committed in plaintext -- values are GPG-encrypted, only ciphertext in diff
GPG encryption uses correct Salt Master key (81A03D1CF874DC90)
Commit messages are descriptive (per PR title)
No unnecessary file changes (single file, tightly scoped)
secrets_registry.sls metadata entry (SOP step 4) -- MISSING
TF_SECRET_VARS Makefile allowlist -- likely MISSING (needed for make tofu-secrets to render these values)

PROCESS OBSERVATIONS

Change failure risk: LOW. The change is additive (no existing secrets modified), properly encrypted, and uses the correct GPG key. The risk is entirely in process completeness, not in the code itself.
Deployment frequency impact: NONE. This is infrastructure provisioning, not a deployment change.
Documentation gap: The arch-secrets-pipeline secret inventory (currently 15 entries) will need updating to reflect these two new secrets once the full pipeline is in place. The architecture note should also document the Hetzner edge module as a new consumer alongside the existing k3s Terraform.

VERDICT: NOT APPROVED

Two SOP compliance gaps must be addressed:

Add metadata entries to salt/pillar/secrets_registry.sls for both secrets.
Confirm and add both keys to the TF_SECRET_VARS Makefile allowlist (or document the alternative rendering path if the Hetzner module uses a different mechanism).

The encryption itself is correct and the PR is well-scoped. These are process completeness items, not security or correctness issues.

## PR #421 Review ### DOMAIN REVIEW **Tech stack:** Salt pillar (GPG-encrypted YAML), Terraform/OpenTofu secrets pipeline. **GPG encryption correctness:** Both encrypted blocks begin with `hQIMA4GgPRz4dNyQAQ/`, which encodes recipient key ID `81A03D1CF874DC90` -- this matches the documented Salt Master GPG key in `arch-secrets-pipeline` and `sop-secrets-management`. Correct key used. **Pillar structure:** The new entries are properly indented under the `secrets:` top-level key, use YAML literal block scalars (`|`), and include complete `-----BEGIN/END PGP MESSAGE-----` delimiters. Formatting is consistent with the existing 505 lines of the file. **Naming:** - `hetzner_api_token` -- clear, follows existing `snake_case` convention. - `edge_ssh_public_key` -- clear, descriptive. Both names are appropriate for `TF_SECRET_VARS` allowlist consumption. ### BLOCKERS **1. Missing `secrets_registry.sls` metadata entry (SOP step 4 -- always required)** Per `sop-secrets-management`, Steps 1-4 are the "canonical backup layer" and are *always* required regardless of delivery path: > Step 4: Add metadata entry to `salt/pillar/secrets_registry.sls` The registry tracks origin, rotation schedule, and provider for every secret. This PR adds two new secrets to the pillar but does not update the registry. The SOP is explicit: "Full metadata for every secret (origin, rotation schedule, provider) lives in `salt/pillar/secrets_registry.sls`. Check there before creating new secrets." Both `hetzner_api_token` and `edge_ssh_public_key` need registry entries with at minimum: origin (External - Hetzner console / Generated), rotation_days, and purpose. **2. Missing `TF_SECRET_VARS` Makefile allowlist update** Per `arch-secrets-pipeline`, the rendering pipeline filters secrets through the `TF_SECRET_VARS` allowlist in the Makefile before writing `secrets.auto.tfvars`. If these two keys are not added to the allowlist, `make tofu-secrets` will NOT render them to tfvars, making the PR body's test plan (`make tofu-secrets` generates both values) impossible to pass without a Makefile change. Unless the Hetzner edge module uses a separate rendering path not documented in the architecture note, this is a missing change. ### NITS 1. **Plaintext backup (SOP step 2):** The SOP requires storing plaintext in `~/secrets/{service}/{name}.env`. Not verifiable from PR diff, but worth confirming this was done before merge. 2. **Woodpecker CI sync:** Per the SOP section "Keeping Salt and CI in Sync," if the Hetzner edge module will eventually run via CI (Woodpecker `tofu plan/apply`), corresponding Woodpecker repo secrets (`tf_var_hetzner_api_token`, `tf_var_edge_ssh_public_key`) will need to be created. If this is host-side only (manual apply), this can be deferred, but should be noted. 3. **SOP update (step 10):** The SOP itself should be updated with these two new secrets in the registry tables once they are finalized. ### SOP COMPLIANCE - [x] PR body has Summary, Changes, Test Plan, Related -- all present and well-structured - [x] No secrets committed in plaintext -- values are GPG-encrypted, only ciphertext in diff - [x] GPG encryption uses correct Salt Master key (81A03D1CF874DC90) - [x] Commit messages are descriptive (per PR title) - [x] No unnecessary file changes (single file, tightly scoped) - [ ] `secrets_registry.sls` metadata entry (SOP step 4) -- **MISSING** - [ ] `TF_SECRET_VARS` Makefile allowlist -- **likely MISSING** (needed for `make tofu-secrets` to render these values) ### PROCESS OBSERVATIONS - **Change failure risk: LOW.** The change is additive (no existing secrets modified), properly encrypted, and uses the correct GPG key. The risk is entirely in process completeness, not in the code itself. - **Deployment frequency impact: NONE.** This is infrastructure provisioning, not a deployment change. - **Documentation gap:** The `arch-secrets-pipeline` secret inventory (currently 15 entries) will need updating to reflect these two new secrets once the full pipeline is in place. The architecture note should also document the Hetzner edge module as a new consumer alongside the existing k3s Terraform. ### VERDICT: NOT APPROVED Two SOP compliance gaps must be addressed: 1. Add metadata entries to `salt/pillar/secrets_registry.sls` for both secrets. 2. Confirm and add both keys to the `TF_SECRET_VARS` Makefile allowlist (or document the alternative rendering path if the Hetzner module uses a different mechanism). The encryption itself is correct and the PR is well-scoped. These are process completeness items, not security or correctness issues.