Add support for device discovery #858
Description
Description
We need to add a discovery capability so customers can get visibility into devices across their network.
The idea is simple: a customer downloads and runs a lightweight agent across their environment. The agent collects device and AMT-related information and reports it back to Console. Console then provides a dashboard to summarize discovered devices and their capabilities.
How customers distribute the agent is out of scope. Most customers already use tools like Intune or similar for software distribution.
This will require:
- Building a discovery agent (new repo) - We should evaluate whether extending rpc-go is a better approach than building a new agent. The goal is to avoid introducing a new component if existing capabilities can be reused and aligned with the overall architecture.
- Defining how the agent authenticates and reports data back to Console
- Extending Console to ingest, store, and visualize discovery data
- Adding a dashboard in Console to summarize discovered devices
All discovered data is expected to be reported back to Console. The dashboard and device registration/visibility should be handled in Console.
Data Collected (Initial Scope)
AMT / ME Details
- CSME FW Version
- Control Mode (ACM, CCM, Pre-Prov)
- SKU type (vPro, ISM, Non-vPro)
- Provisioned State (Pre, In or Post)
- TLS Mode
- Network details
- 802.1x (wireless)
- DHCP vs Static
- AMT Hashes
- UPID
- Is AMT enabled in BIOS?
Additional Device Details
- ME Interface Version
- LMS Version
- Is LMS installed?
- OS details (including distro)
- CPU details
- Hostname
- OS IP address
- Number of ethernet adapters
- Detect if a monitor is connected (useful for KVM scenarios)??
Console Capabilities
Console should provide a dashboard with:
- Summary of discovered devices
- Ability to filter and sort devices
- Breakdown of device capabilities (e.g., number of vPro devices)
- Within vPro, visibility into how many are provisioned
Non-Functional Requirements
- Capture when the device was last reported/discovered
- Ensure discovery data can be updated over time without creating duplicate devices.
- Support exporting discovered data to a file for external analysis or reporting.
Open Questions
- We should evaluate whether extending rpc-go is a better approach than building a new agent. The goal is to avoid introducing a new component if existing capabilities can be reused and aligned with the overall architecture.
- The agent will likely reuse rpc-go for AMT-related discovery. This may require making rpc-go easier to consume as a Go library, similar to
go-wsman-messages. - Should discovery data always be reported to Console, or do we need a standalone/offline mode?
- Is Console ready to handle ingestion and storage of discovery data, or do we need additional components?
- Console will need to support ingesting and storing discovery data. What is the right data model in Console for storing discovery results? SQL vs Document DB?
- How should the agent authenticate with Console? Reuse what we have?
- How frequently should the agent report data (one-time vs periodic)?
- Once a device is discovered and already activated, should Console allow it to be directly added as a managed device, so a user can connect?
- The agent should support uninstall/cleanup.
Acceptance Criteria
- Define the architecture for discovery (agent + Console).
- Define the data model for discovered device information.
- Define how the agent communicates with Console.
- Define how rpc-go is reused or adapted for discovery.
- Define the Console dashboard requirements for discovery.
- Create follow-up work for agent implementation and Console changes.