Device credential vault
Collectors need credentials to back up and change your devices. This page shows how to store them in the vault, bind them to devices, and how Tracix keeps them out of reach once saved.
How the vault protects credentials
- Write-only. Once you save a credential, no screen or API returns the secret, including to admins. The console shows its name, type, username, a short fingerprint you can recognize it by, and when it was created.
- Envelope encryption. Each secret is encrypted with AES-256-GCM under its own random 256-bit key, and that key is encrypted with your workspace's master key. Only the encrypted form is stored.
- Just in time. A collector receives a credential only while it runs a job that needs it, and only for the role that job needs. It keeps the credential in memory and clears it when the job ends. The collector control plane passes the credential through without storing it.
- Verified devices. Once you pin a device's SSH host key, or a certificate authority for gNMI over TLS, collectors refuse to connect to a device that doesn't match, so an impersonated device never receives a credential. See Pin device host keys.
Not yet: a hardware-backed master key
The vault's master key is a secret that belongs to your workspace. Keeping it in a cloud key management service or a hardware security module isn't available yet.
Add a credential
Open Credentials
In the console's main navigation, open Credentials. Every credential in your workspace is listed here, with a New Credential panel beside the list.
Choose a network device type
Under Type, choose one of the network device types: SSH password, SSH key, Enable secret, API token, NETCONF, SNMPv3 or TACACS pass-through. Each shows as, for example, SSH password · network device.
Enter the secret
Enter a Name, such as
core-ssh-prod, the Username and the Secret, then select Save credential.
To change a secret later, select Rotate on its row and enter the new value. Rotating keeps the credential's identity, so every binding that uses it keeps working. Delete removes the credential permanently, and device jobs that use it fail until you save a replacement and bind it.
Bind credentials to devices
A binding tells Tracix which credential to use for which devices and for what purpose.
Open the bindings
Open Network › Config Mgmt › Credentials and select Add binding.
Choose the credential and role
Pick the Credential and its Role: login to sign in, enable for privileged mode, api for gNMI. The snmp role is listed too, but configuration jobs don't use it.
Choose the scope
Pick a Scope, then one or more values: a platform such as Arista EOS, a site, a group, or individual devices. Selecting several values creates one binding for each. Select Create binding.
When several bindings match a device for the same role, the most specific one wins: device over group, group over site, and site over platform. To see what a device will use, open it under Inventory and select Connection settings: Credential resolution shows the credential chosen for each role and which binding chose it, and flags a missing role that blocks jobs.
Which roles a job needs
| Connection | Roles the job needs |
|---|---|
| SSH | login, plus enable for Cisco IOS and Cisco NX-OS |
| NETCONF | login |
| gNMI | api when one is bound, otherwise login. The credential needs the device username and password. |
SNMP polling credentials are separate: you set them on the SNMP integration. See SNMP polling and traps.
Pin device host keys
Each device's Connection settings tab has a Transport security section.
- Trust on first use. Until you pin a key, collectors accept the SSH host key the device presents and report it to your workspace. The reported key appears as observed; select Pin (approve) to pin it, or dismiss.
- Pinned keys. Once a key is pinned, collectors refuse a device whose key doesn't match. Pinned keys are listed in the section, and you can remove one.
- Strict mode. Turn on strict — reject unpinned to refuse devices that have no pinned key at all.
- gNMI over TLS. Select + pin gNMI/TLS CA, paste the CA certificate (PEM) and optionally the Expected TLS server name, then select save CA.
Managing host keys needs the apply permission, which admins have by default.