Why:
- The netbox engine modules stand ready but mount nothing and create no
identity until backend and role data exist, so terraform-infra still reads a
static NetBox token instead of minting ephemeral scoped tokens.
How:
- Add config/netbox_secret_backend/netbox.yaml to mount the engine at netbox and
point it at the syd1 NetBox URL; the admin token is read from KV, not stored
here.
- Add config/netbox_secret_backend_role/netbox/terraform-infra.yaml as the
single declarative source for the terraform-infra identity: filename-derived
role name and NetBox username, write access, short TTLs, and an inline
permissions block. Nothing in the file repeats the filename.
- Scope terraform-infra to view/add/change/delete on the IPAM/DCIM objects it
manages: prefixes, ip-addresses, ip-ranges, devices, interfaces, mac
addresses.
- Add policies/netbox/creds/terraform-infra.yaml letting the terraform-infra
AppRole and its Woodpecker k8s role read netbox/creds/terraform-infra; it
attaches to nothing until the separate terraform-infra Vault onboarding lands.
Why:
- Managing NetBox from Vault needs three capabilities the repo does not yet
have: mounting the netbox engine, minting scoped tokens through roles, and
creating the NetBox service users those roles mint tokens for. Landing the
modules and config scaffolding before any backend or role data lets each
concrete identity be added as pure data later.
How:
- Add three modules under modules/vault_cluster/modules: netbox_secret_backend
(mount + engine config, admin token read from KV), netbox_secret_backend_role
(mint ephemeral scoped tokens for a filename-derived NetBox username), and
netbox_user_management (mirror consul_acl_management: read the seeded admin
token, drive one e-breuninger/netbox provider per backend, and synthesize the
NetBox user + object permissions from the role map's inline permissions).
- Derive the netbox_secret_backend and netbox_secret_backend_role maps in
config.hcl, deriving each role's name and netbox_username from its filename so
the engine role and NetBox username match by construction.
- Wire the three module blocks and their variables through vault_cluster and the
syd1 terragrunt inputs, reusing the sanitized backend-alias pattern the Consul
providers use.
- Leave the backend and role maps empty: the modules stand ready and create
nothing until backend and role config data are added.
Why:
- The netbox secrets engine cannot be mounted until its plugin binary is
registered in the OpenBao catalog, so the catalog entry must land before any
engine mount or role config references it.
How:
- Add config/plugins/vault-plugin-secrets-netbox.yaml registering the plugin as
a secret plugin, pinned to the released v0.1.0 binary sha256 that Puppet
installs on the OpenBao nodes. Bump the sha in lockstep with any RPM upgrade.
benvin
unkinben