Replace the second static user_mgmt_token with a Vault-minted, user-admin-capable
token so only ONE static NetBox admin credential exists. A dedicated engine role
(netbox/roles/vault-user-mgmt) mints a short-lived token for a pre-existing NetBox
superuser (user_mgmt_username); netbox_user_management authenticates the
e-breuninger provider with that minted token to reconcile the service users. This
also resolves rotation-divergence structurally: the credential is always derived
from the current static admin token, so rotating it never strands user management.
Constraints this design works within (documented in the module):
- The hashicorp/vault provider ships ephemeral resources for KV only, not dynamic
engine creds, so the mint is read via the vault_generic_secret data source; the
short-lived token transits state (sensitive, lease-revoked) and is re-minted each
plan. Migrate to an ephemeral resource once the provider ships one.
- A provider cannot be configured from a role created in the same fresh apply, so a
brand-new backend needs a one-time targeted bootstrap of the mount + role.
- Add user_mgmt_username to the netbox backend config; when set, mint dynamically,
else fall back to the single static admin_token (a check block warns that
rotation would then break user management).
- Add module.netbox_user_mgmt_role (vault-user-mgmt, write-enabled, short TTL).
- Grant the deployer read on netbox/creds/vault-user-mgmt (the one deliberate
exception to the admin policy's creds exclusion).
- Keep the bare-token + token_version postconditions on the single admin token.
unkinben
483fd21acb