Files
unkin-agent 600a7747b0
ci/woodpecker/push/apply Pipeline was successful
vault: ghp engine config-write + consumer policies (apply before #121) (#122)
Why: step 2 of the ordered ghp plugin add (install via puppet -> **this policy** -> resources). The terraform apply identities (tf_vault / woodpecker_terraform_vault) need create/update on ghp/config + ghp/roles/* BEFORE the engine resources are applied — an approle token capability set is fixed at login, so the grant must be effective in a prior apply or writing ghp/config is permission-denied.

How: split out of #121 — policies/ghp/admin.yaml (deployer: ghp/config + ghp/roles/*) and policies/ghp/creds/agent.yaml (agents approle: read ghp/creds/agent).

Order: puppet-prod#520 (install plugin) -> **this** -> #121 (resources).
Reviewed-on: #122
Co-authored-by: unkin-agent <unkin-agent@unkin.net>
Co-committed-by: unkin-agent <unkin-agent@unkin.net>
2026-08-16 14:49:33 +10:00

38 lines
1.1 KiB
YAML

# Allow the vault deployer to manage the ghp token secrets engine: its
# connection config (seeded service token) and its token-minting roles.
#
# Scoped to ghp/* only, and deliberately excludes ghp/creds/* - minting tokens
# is for consumers, not the deployer. ghp has NO rotate endpoint, so unlike the
# gitea/netbox engines there is no config/rotate grant here. The plugin-catalog
# grant needed to import the plugin is the shared, sudo-protected wildcard in
# policies/sys/plugins/catalog/admin.yaml (already covers this plugin), and
# mounting the engine uses the deployer's existing sys/mounts/* access, so no
# new catalog/mount grant is added here (mirrors the gitea/netbox engines).
---
rules:
# Engine connection config (base_url, TLS, seeded service token).
- path: "ghp/config"
capabilities:
- create
- read
- update
- delete
# Token-minting roles.
- path: "ghp/roles/*"
capabilities:
- create
- read
- update
- delete
- list
- path: "ghp/roles"
capabilities:
- read
- list
auth:
approle:
- tf_vault
k8s/au/syd1:
- woodpecker_terraform_vault