How Red Hat solves the toughest challenges in agentless infrastructure scanning

Enterprises want absolute clarity on their IT footprint: they want to know exactly what software is running, where it’s running, and how those deployments align with subscription entitlements. For many organizations, Red Hat Hybrid Cloud Console and subscription watch provide that visibility. But what happens when your infrastructure can't (or shouldn't) phone home? Air-gapped networks, government systems, manufacturing floors, and sovereign clouds all require a completely disconnected approach.

That is exactly why we built discovery, an open source, agentless scanning tool that is a component of Red Hat Lightspeed and is designed to run entirely within your infrastructure. It scans your network environments, including IP ranges, hostnames, vCenter connections, and Red Hat Satellite servers to identify exactly which Red Hat products are deployed, including Red Hat Enterprise Linux (RHEL), Red Hat OpenShift Container Platform, Red Hat Ansible Automation Platform, or JBoss. Discovery can also determine the version numbers and infrastructure footprint for all these products. It is entirely configurable by you.

This blog post will look under the hood of discovery, covering what your security team needs to know, how a scan executes from start to finish, and how we are solving the hardest engineering problems in enterprise-scale agentless scanning.

What your security team needs to know about discovery

Any tool that requires network access and credentials deserves rigorous scrutiny, and discovery is engineered to make that security review as straightforward as possible.

Core security architecture

• Completely agentless: Discovery leaves no footprint on your target systems. There are no persistent agents to maintain, no background daemons to patch, and no software left behind.
• Strictly read-only: Once connected, discovery only reads system metadata, configuration files, and package registries. It never modifies configurations, writes files, or changes system state. It cannot access passwords, application data, or user files.
• Local credential isolation: Credentials provided for your scan sources are stored locally on your own discovery instance. They are used strictly at scan time and are never transmitted externally. When a scan concludes, credential usage ends immediately.
• Total data autonomy: Your scan data is yours. Scan results live entirely on your discovery instance within your environment. There is zero telemetry, no automatic phone-home functionality, and no background sync to Red Hat.

Network footprint

Discovery requires no inbound ports beyond what is already running in your environment. It connects outbound from your local discovery instance to the target infrastructure using standard, pre-existing management ports:

• SSH (Port 22): For RHEL and other Linux systems.
• WinRM (Ports 5985/5986): For Windows systems.
• HTTPS (Port 443): For VMware vCenter and Red Hat Satellite APIs.

Note on elevated privileges: If your security parameters restrict sudo access, discovery is designed to degrade gracefully: It will still run with reduced privileges, allowing the scan to complete rather than fail, though it may return less complete metadata. As part of our commitment to transparency, we are actively documenting all commands that use elevated privileges, along with the reasons why those commands need those privileges.

Anatomy of a discovery scan from start to finish

To understand how discovery protects your environment while gathering data, let’s walk through the end-to-end lifecycle of a single scan. We begin on the introduction screen of the discovery UI that you will see when discovery starts up, shown in Figure 1. 

Figure 1. Discovery introduction screen

Phase 1: Setup and definition

Discovery runs as a container on a host inside your own network, giving you absolute control. Before any network activity occurs, you define your target sources (IP ranges, specific hostnames, a vCenter connection, or a Satellite server), as shown in Figure 2; input the necessary local credentials, as shown in Figure 3; and manage the credentials, as shown in Figure 4. Nothing touches your network until you explicitly initiate the scan.
 

Figure 2. Inputting sources 

 

Figure 3. Adding local credentials

Figure 4. Managing credentials

Phase 2: Connection

When you launch the scan, discovery attempts to establish outbound connections to each defined target via SSH, WinRM, or HTTPS APIs. If a specific host is closed or unreachable, discovery logs the state and immediately moves to the next target. A single closed port will never stall or halt the wider scanning workflow. Scans can be managed via the scan management tab, as shown in Figure 5.

Figure 5. Managing scans

Phase 3: Interrogation

Once connected to a host, discovery runs its targeted suite of read-only commands to collect critical system metadata:

• Operating system: Distribution type and exact version.
• Red Hat ecosystem: Installed software instances (RHEL, OpenShift, Ansible Automation Platform, JBoss).
• Infrastructure footprint: System configuration (physical, virtual, or cloud) along with socket, core, and vCPU allocations.
• Management state: Checking whether the system is already registered via Red Hat Satellite or Subscription Manager.

For virtualized environments running on VMware, discovery queries the vCenter API directly to retrieve the VM inventory (guest OS, hardware allocation, cluster data) without ever touching or connecting to individual virtual machines.

Phase 4: Assembly and deduplication

As data flows back, discovery processes the raw information into a clean, unified report. A core part of this phase is intelligent deduplication. If a single RHEL instance is detected via both an SSH scan and a Satellite API sync, discovery merges the data points into a single record rather than double-counting your footprint. Furthermore, if data cannot be retrieved, discovery flags it clearly as a gap in the report rather than making a guess.

Phase 5: Results and action

The finalized report remains localized on your hardware. You can review it inside the discovery UI or export the data for your internal validation.

[Local setup] ──> [Outbound connection] ──> [Read-only interrogation] ──> [Data assembly and deduplication] ──> [Localized report]

Sharing this data with Red Hat for subscription reconciliation is completely optional and requires explicit, manual action on your part. You will always see exactly what data is being transmitted before it leaves your network perimeter, as shown in Figure 6.

Figure 6. Report view

How Red Hat implemented agentless scanning at scale

Building an agentless scanner that reliably operates across thousands of heterogeneous and protected enterprise systems presents distinct engineering challenges. Table 1 outlines how the discovery engineering teams are solving 5 of the most difficult obstacles in infrastructure scanning.

Table 1. How discovery handles infrastructure scanning challenges

Whether you operate a fully disconnected environment or simply want an independent, agentless verification of your active infrastructure, discovery is engineered to give you the data clarity you need to make confident architectural decisions.

Next steps

• Ready to deploy? Review the discovery documentation to set up your local container instance and launch your first scan.
• Running a connected environment? Learn how to pair your setup with subscription watch and Hybrid Cloud Console for comprehensive entitlement visibility.