unkin/puppet-prod
4
0
Fork 0
Code Issues 15 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

netbox-facts: decide token source (no host->Vault auth exists) #518

New Issue
Open
opened 2026-08-09 00:19:45 +10:00 by unkinben · 0 comments
unkinben commented 2026-08-09 00:19:45 +10:00
Owner
Copy Link
Copy Source

Context

profiles::netbox::facts seeds /etc/puppetlabs/netbox.token from hiera profiles::netbox::facts::api_token, and the netbox fact authenticates to NetBox with that static token. The vault-plugin-secrets-netbox engine is now live and mints per-consumer ephemeral NetBox tokens; terraform-vault adds a read-only netbox/creds/puppet-facts role (svc-puppet-facts, 24h ttl / 72h max_ttl). Question: how should puppet hosts obtain their token?

Investigation findings

  • No puppet-host -> Vault authentication exists anywhere in the estate: no AppRole, no vault-agent, no cert/TLS auth, no hiera-vault/vault lookup backend, not even hiera-eyaml (hiera.yaml is plain yaml_data). The fact cannot fetch netbox/creds/puppet-facts at runtime today.
  • The engine is lease-based: a minted token is deleted from NetBox at max_ttl, so a statically-seeded engine-minted token stops working after 72h. (The fact fails safe to its on-disk cache, so a run never breaks, but data goes stale until re-mint.)

Design decision needed

  1. Stay static (pragmatic near-term). Keep api_token a long-lived NetBox token created directly in NetBox for svc-puppet-facts, seeded in hieradata. Do NOT mint it from the engine. No puppet change; engine used only for terraform-infra for now.
  2. Operator-minted + periodic re-seed. Mint from netbox/creds/puppet-facts and re-seed hieradata on a <=72h cadence. Adds operational toil.
  3. Introduce host -> Vault auth (proper fix, larger project). AppRole/cert auth for puppet hosts + runtime fetch (vault-agent template or hiera-vault) so the fact pulls netbox/creds/puppet-facts each run and never stores a long-lived token. Scope separately.

Recommendation

Option 1 now (no puppet code change; the profile already accepts a hiera-seeded token), with Option 3 tracked as the real fix if puppet-host Vault auth is introduced. Flagging for a call before any code lands.

## Context `profiles::netbox::facts` seeds `/etc/puppetlabs/netbox.token` from hiera `profiles::netbox::facts::api_token`, and the `netbox` fact authenticates to NetBox with that static token. The `vault-plugin-secrets-netbox` engine is now live and mints per-consumer ephemeral NetBox tokens; terraform-vault adds a read-only `netbox/creds/puppet-facts` role (svc-puppet-facts, 24h ttl / 72h max_ttl). Question: how should puppet hosts obtain their token? ## Investigation findings - **No puppet-host -> Vault authentication exists anywhere in the estate**: no AppRole, no vault-agent, no cert/TLS auth, no `hiera-vault`/`vault` lookup backend, not even `hiera-eyaml` (`hiera.yaml` is plain `yaml_data`). The fact cannot fetch `netbox/creds/puppet-facts` at runtime today. - The engine is lease-based: a minted token is **deleted from NetBox at max_ttl**, so a statically-seeded engine-minted token stops working after 72h. (The fact fails safe to its on-disk cache, so a run never breaks, but data goes stale until re-mint.) ## Design decision needed 1. **Stay static (pragmatic near-term).** Keep `api_token` a long-lived NetBox token created directly in NetBox for `svc-puppet-facts`, seeded in hieradata. Do NOT mint it from the engine. No puppet change; engine used only for terraform-infra for now. 2. **Operator-minted + periodic re-seed.** Mint from `netbox/creds/puppet-facts` and re-seed hieradata on a <=72h cadence. Adds operational toil. 3. **Introduce host -> Vault auth (proper fix, larger project).** AppRole/cert auth for puppet hosts + runtime fetch (vault-agent template or hiera-vault) so the fact pulls `netbox/creds/puppet-facts` each run and never stores a long-lived token. Scope separately. ## Recommendation Option 1 now (no puppet code change; the profile already accepts a hiera-seeded token), with Option 3 tracked as the real fix if puppet-host Vault auth is introduced. Flagging for a call before any code lands.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
benvin (BenVincent) unkin-agent (Unkin Agent) unkinben (Ben Vincent)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: unkin/puppet-prod#518
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?