Option to run from CLI, with API

[Torstein-Eide]

Environment

• Nautobot version: Not relevant
• nautobot-device-onboarding version: Not relevant

Proposed Functionality

Add a option where users can use a CLI to onboard devices.

Topology

Use Case

For some companies the access to netmiko and NAPALM on the devices are heavily restricted.

SSOT is often setup i a locations where many users can use the SSOT, to limit the exposure if the solution is comprised, the SSOT does not have access to devices directly.

This is in complance with:

• Cisco Guide to Harden Cisco IOS Devices
• IEC 62443 is an international series of standards that address cybersecurity for operational technology in automation and control systems.
• PURDUE MODEL FRAMEWORK FOR INDUSTRIAL CONTROL SYSTEMS & CYBERSECURITY SEGMENTATION
• NIST cybersecurity

[scetron]

Thank you Eideen. Can you expand on how you would like the onboarding procedure to work in this case?

I imagine that from the CLI or API, you would provide all of the items that Device Onboarding discovers by connecting to the device, is that right? In a sense, a short-cut to creating a new device.

[Torstein-Eide]

I think there is 2 ways you can go:

• Read and forward all the raw data that you read.
• Do the work on the client machine, and use the /dcim/device*/ api.

From a user perspective i think would be something simlare to the GUI:

Onboarding.py  --host ${url/ip} --username ${username} --password ${password} --secret ${secret} --port ${port} --timeout ${time} --location ${Location} --role ${role} --device_type ${device_type} --platform ${platform} --Nautobot_url ${Nautobot_URL} --Nautobot_token ${token}

Yes the second option is a short-cut to creating a new device, but can also be used to update periodically, the Nautobot, when the SSOT state is a "Sink" phase, until your are able to make the transition to "source" state.

for the first option the:

• Location
• Role
• Device_type
• Platform

Can be done in bulk, in the web GUI on Nautbot.