Secrets & Credential Management¶
The Discovery App integrates directly with Nautobot's native Secrets and Secrets Group framework to provide secure, structured credential management for discovery and onboarding workflows.
How Credentials Are Assigned¶
Within a Discovery Profile, you assign one or more Secrets Groups. Each secret within a group is associated with a weight that controls its priority during authentication.
SSH Credential Selection¶
For SSH-based discovery, the app sorts all assigned secrets by ascending weight and attempts them in order, starting with the lowest weight. If authentication fails, it proceeds to the next secret. This continues until authentication succeeds or all secrets are exhausted.
This weighted retry logic means the app can securely authenticate devices across diverse environments, support multi-credential retry without manual intervention, and work seamlessly with the Device Onboarding App for end-to-end workflows.
Tip
After a successful SSH authentication, the app stores the secret that worked as the last known working credential. On future runs, this stored secret is attempted first — even if weight ordering would normally suggest otherwise — reducing authentication attempts and minimizing lockout risk.
SNMP Credential Selection¶
SNMP handling is intentionally simpler. Only the lowest-weight SNMP secret is used, with no fallback attempts. SNMP queries are typically deterministic and version-specific, so retrying multiple credential sets would introduce unnecessary polling overhead.
Defining SSH Secrets¶
To create an SSH-compatible Secrets Group, navigate to Secrets > Secrets Groups > Create and add the following secrets:
| Access Type | Secret Type | Purpose |
|---|---|---|
| SSH | Username | SSH login username |
| SSH | Password | SSH login password |
Device Onboarding Compatibility¶
The current Device Onboarding App expects AccessType: Generic rather than AccessType: SSH. To ensure both Discovery and Onboarding work with the same Secrets Group, define your secrets twice within the same group:
| Access Type | Secret Type | Secret |
|---|---|---|
| SSH | Username | $YOUR_SECRET |
| SSH | Password | $YOUR_SECRET |
| Generic | Username | $YOUR_SECRET |
| Generic | Password | $YOUR_SECRET |
This looks duplicative, but it ensures the Discovery App can authenticate via SSH access type while the Onboarding App can consume the Generic access type.
Defining SNMP Secrets¶
SNMP secrets are defined according to protocol version.
SNMPv2c¶
For community-based SNMP, define a single secret:
| Access Type | Secret Type | Description |
|---|---|---|
| SNMP | Token | Community string |
SNMPv3¶
For SNMPv3, the required secrets depend on the security level:
| Security Level | Required Secrets |
|---|---|
| noAuthNoPriv | Username |
| authNoPriv | Username + Password |
| authPriv | Username + Password + Key |
All SNMPv3 secrets use AccessType: SNMP.
Enabling Device Onboarding Integration¶
To enable the Onboard Selected Devices button in the Discovery results view, the associated Secrets Group must include both AccessType: SSH and AccessType: Generic secrets. If only SSH is defined, discovery will succeed but the onboarding button will remain disabled because the Onboarding App currently requires Generic access types.
Best Practices¶
Assign production credentials lower weights so they are attempted first, and assign fallback or emergency credentials higher weights. Keep SSH and SNMP secrets in separate Secrets Groups or at least keep in mind that SNMP will not retry like SSH does. Use the dual AccessType pattern (SSH + Generic) for SSH credentials.