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