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 Red Hat Asset 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 Red Hat Asset 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 Red Hat Asset Discovery

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

Core security architecture

• Completely agentless: Red Hat Asset 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, Red Hat Asset 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 Red Hat Asset 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 Red Hat Asset Discovery instance within your environment. There is zero telemetry, no automatic phone-home functionality, and no background sync to Red Hat.

Network footprint

Red Hat Asset Discovery requires no inbound ports beyond what is already running in your environment. It connects outbound from your local Red Hat Asset 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, Red Hat Asset 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 Red Hat Asset Discovery scan from start to finish

To understand how Red Hat Asset 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 Red Hat Asset Discovery UI that you will see when it starts up, shown in Figure 1. 

Figure 1. Red Hat Asset Discovery introduction screen

Phase 1: Setup and definition

Red Hat Asset 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, Red Hat Asset Discovery attempts to establish outbound connections to each defined target via SSH, WinRM, or HTTPS APIs. If a specific host is closed or unreachable, Red Hat Asset 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, Red Hat Asset 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, Red Hat Asset 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, Red Hat Asset 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, Red Hat Asset Discovery merges the data points into a single record rather than double-counting your footprint. Furthermore, if data cannot be retrieved, Red Hat Asset 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 Red Hat Asset 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 Red Hat Asset Discovery engineering teams are solving 5 of the most difficult obstacles in infrastructure scanning.

Table 1. How Red Hat Asset Discovery handles infrastructure scanning challenges

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

Next steps

• Ready to deploy? Review the Red Hat Asset 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.

Note: This blog post has been updated to reflect the renaming of this tool from "discovery" to "Red Hat Asset Discovery."