Credentials & the vault

A source authenticates to its device with a credential from the tracker’s vault. Credentials come in two flavours: stored secrets, encrypted at rest, and just-in-time logins — where Taranac doesn’t store a password at all, because it mints and rotates one itself.

Credentials live under Configuration Tracker → Settings → Credentials.

The vault: a just-in-time password credential and a stored SSH key, each with its type, mode and reference count — secrets never shown in the list.

A stored credential holds secret material, encrypted at rest. The type fixes what fields it carries:

Type	Holds
Password	Username + password.
SSH key	Username + private key (+ optional passphrase).
SSH certificate	Username + certificate + private key (+ optional passphrase).
API token	A bearer token (for HTTP recipes, injected via {{cred.token}}).
Enable secret	An enable/privileged-mode secret, referenceable from another credential.
Secret bag	An arbitrary key→value map for one-off needs.

• Fernet, per value, at rest. Every secret field is individually Fernet-encrypted with the deployment’s master key before it touches the database. The master key is loaded at startup (from an environment variable, a file, or an interactive prompt) and is never written to the database.
• Never returned by the ordinary API. Listing or viewing a credential shows secret fields as a masked sentinel (••••••••), never the ciphertext and never the plaintext. Editing uses the same sentinel, so re-saving a form without touching a field leaves the stored secret untouched.
• Reveal is a separate, audited action. Seeing a stored secret in the clear requires the dedicated ncm_credentials.reveal permission — distinct from view/create/edit — and every reveal writes an audit event with the operator, IP and user agent.

just-in-time · svc-ncm (local)

mint •••••••••••••••• → borrow ×3 → rotate ××××××××××××××××

nobody ever sees it 32 chars · rotated on drain

The vault isn’t the interesting part. The interesting part is not storing a password at all — and this is where being the AAA server changes the game. A just-in-time (jit) credential doesn’t carry a secret. Instead it points at a managed local Taranac account, and at collection time Taranac:

1. Mints a strong, 32-character random password on that local account.
2. Logs the collector into the device with it — and because the device authenticates its admin logins against Taranac (Taranac is its AAA server), the login is validated live, against the just-minted password. There is no device-local password to store.
3. Rotates it away once the collection work drains.

Follow what that removes. The service account an automated system uses to reach your fleet is the classic soft target — a shared password in a config file, reused for months, one leak from a fleet-wide compromise. A JIT account has none of those handles:

• Nobody has ever seen it. The password is machine-generated and never displayed — not in the UI, not in logs, not over the API. (Revealing a JIT credential returns an empty payload, because there is no stored secret to show.)
• It’s genuinely strong. 32 random characters, not a memorable string a person picked.
• It’s already gone. It rotates as the work drains, so a password sniffed off the wire is dead before it’s useful — and the next one doesn’t exist yet.

Pointing one JIT credential at a rack of devices means several collections hit the same account at once. Rather than mint a fresh password per run (which would race), the mint is an account-scoped “warm” lease:

• The first collection mints the password and takes a lease on the account.
• Every concurrent collection on that account borrows the same live password and logs in in parallel.
• The password is rotated once the lease goes idle (all borrowers have drained) — never yanked out from under an in-flight login.

If the password was ever handed to a standalone collector (it touched an edge), it’s rotated immediately on drain rather than kept warm. An absolute lifetime ceiling and an idle window bound how long any minted password can live.

Separately from which credential a source uses, the tracker remembers which credential last authenticated successfully at a given address. This “auto-bind” memory means discovery and probing won’t re-spray every credential at an address that already has a known-good one — avoiding the account lockouts that credential-spraying triggers on real gear. Deleting a credential drops its bindings automatically.

Read every switch config without a stored service password. Create one local Taranac account for config collection, make a just-in-time credential pointing at it, and reference that credential from your SSH sources. No device-reachable password is ever stored or reused.

Track an API platform. Store an API token credential and reference it from the HTTP recipe’s header (Authorization: Bearer {{cred.token}}). The token is encrypted at rest and injected only at collection time.

Privileged-mode (enable) access. Store an Enable secret credential and reference it from the login credential so the collector can escalate where the platform needs it.

Choose just-in-time when…	Choose stored when…
The device does its admin AAA through Taranac (so Taranac can validate a minted password).	The device authenticates locally or against another system.
You want zero long-lived, reusable service passwords.	You must present a specific existing account (e.g. a vendor API token, an SSH key).
Collection is CLI over SSH/Telnet on a managed local account.	The credential is an SSH key, certificate, or API token.

Field	Notes
Name	Required, unique.
Type	password · ssh_key · ssh_cert · token · enable · bag.
Mode	stored (default) or jit.
Secret fields	Per type; each value Fernet-encrypted at rest; masked in list/view; revealed only via ncm_credentials.reveal.
Local account	For jit: the managed local Taranac user the password is minted on.
Enable reference	Optional link to an enable-type credential for privilege escalation.

• Tracked configs & transports — where a source picks its credential.
• Recipes & scrub sets — {{cred.*}} injection in HTTP recipes.
• Collectors — run-scoped credential hand-out to standalone collectors.
• Audit & syslog — where credential reveals are recorded.
• Roles & permissions — the ncm_credentials permissions, including reveal.