Bring in #128 (agents approle write on ghp config KV path) and confirm ghp backend/role YAMLs removed by #129 stay absent, so plan resolves the now-published vault-secrets-arrstack v0.1.0 provider cleanly.
Create the arrstack secrets engine resources: the mount + config and the
per-scope roles that mint arrproxy API keys. Third and final stacked step
(register -> policy -> resources).
Adds:
- config/arrstack_secret_backend/arrstack.yaml: mounts the engine at
"arrstack" and writes its config (base_url, timeout). The arrproxy
admin token stays out of git and is read from KV by the module.
- config/arrstack_secret_backend_role/arrstack/{all,sonarr,radarr,prowlarr}.yaml:
roles scoped to each arr app (and one covering all three). Default
ttl is 60s (short-lived, renewed on demand); max_ttl 86400 mirrors the
litellm sibling convention. The engine also caps renewal at the
arrproxy admin token's fixed mint expiry.
- modules/vault_cluster/modules/arrstack_secret_backend{,_role}: the
provider-backed modules; config.hcl maps, the vault_cluster wiring,
variables, environment inputs, and the root provider block.
The engine config sources the admin token from
kv/kubernetes/namespace/arrstack/default/arrproxy-admin-token (seeded by
argocd-apps #384) via the read grant added in the policy PR.
Provider source is artifactapi.k8s.syd1.au.unkin.net/terraform-unkin/
vault-secrets-arrstack (terraform-provider-vault-secrets-arrstack repo),
local name "arrstack".
Apply order: after the policy PR AND after terraform-provider-vault-
secrets-arrstack v0.1.0 is published to the artifactapi terraform
registry. Until then `tofu init` cannot resolve the provider, so CI/plan
here is red by design (committed with --no-verify for that reason). Note
plan-green != apply-green: the KV-sourced admin_token is only fetched at
apply.
Grant the Vault access the arrstack engine needs, before any engine
resources exist. Second of three stacked steps (register -> policy ->
resources).
Adds:
- policies/arrstack/admin.yaml: the terraform-vault deployer may
create/read/update/delete arrstack/config and manage arrstack/roles/*.
- policies/kv/.../arrproxy-admin-token/read.yaml: the deployer may read
the KV-seeded arrproxy admin token (data + metadata paths) that the
engine config sources; the existing secret_backends_read policy does
not cover this kubernetes/namespace KV path.
- policies/arrstack/creds/{sonarr,radarr,prowlarr}.yaml: each terraform-
<app> run may read its own arrstack/creds/<app> to mint a scoped key.
Policy YAMLs are auto-discovered by policies/policies.hcl, so no wiring
changes are needed.
Apply order: after PR-1 (register). Safe to apply before the engine
exists since these only grant capabilities on paths.
Import the arrstack secrets plugin (v0.1.0) into the OpenBao plugin
catalog so later PRs can mount the engine. Registration is the first of
three stacked, independently-applied steps (register -> policy ->
resources) per the never-bundle rule.
The plugins map glob and module.plugin already exist, so this only adds
the catalog entry; the sha256 pins the released v0.1.0 binary.
Apply order: run this only AFTER the Puppet plugin-install PR (#521,
merged) has placed the binary at
/opt/openbao-plugins/vault-plugin-secrets-arrstack on the OpenBao nodes.
Registration fails until the binary is present.