Discovery and maps

Screen: Organization structure

The organization structure holds two trees that group everything in Hive: Locations (Company › Site ›Building › Floor › Room) and Departments (for example Board › Finance › Accounts payable, with a cost center). Machines fall into place by themselves, and the structure is used by the physical map, deployment targets and who sees each item in the Store. It is in Discovery › Structure.

Create the company and its sites with New company or site, and build the tree with Add inside.

Create departments with New department, linked to directory names and OUs.

Edit a node (name, code, where it is inside, linking tags) or Remove it.

Switch between List and Map to see the tree.

See how many machines are in each node (Machines, with "n directly") and open them in the inventory.

A site also becomes the site used for time zone, maintenance window and distribution point by deployments, and sites that already existed show up as tree nodes.

Location, from the strongest rule to the weakest:

Department: the department of the machine's main user in the directory (the department name or one of its Names in the directory), otherwise the department whose OUs match the computer account's OU path.

A choice made by hand on the machine (panel Where it is › Change) wins over every rule; Automatic (by the rules) goes back to the rules. The machine inherits the tags Empresa , Localidade , Prédio , Andar , Sala and Departamento with the names of its path; when it changes rack, port, network or user, they change by themselves. The structure is applied when a scan ends, when the agent sends inventory, every 10 minutes and whenever the tree changes.

Worked example: site "São Paulo HQ" with two floors and its subnet

Deployments, patches and playbooks: pick a node and every machine in its subtree is included.

Store: who sees each item.

Physical map: devices grouped by their location path.

Racks: each rack is placed in a room, floor or building.

Inventory: the Location and Department filters include the subtree.

Creating, editing and removing nodes needs assets:write .

Remove also removes everything inside; the machines go back to the automatic rules.

Names must be unique among siblings ("There is already a location with this name here.").

A tag can have up to 200 characters.

Only locations have linking tags; departments use directory names and OUs.

Tags and groups

Discovery

Network map

Deployments

Inventory

Screen: Discovery area (1/3)

Screen: Discovery area (2/3)

Screen: Discovery area (3/3)

In Discovery › Discovery you scan networks from a collector to find what has no agent: workstations, servers, printers, cameras, phones and network devices. Each scan says which ranges, methods, credentials, collector, intensity, tags and schedule it uses; each run shows what is new, what changed, what is gone and what still has no agent. The passwords, keys and SNMP communities live in the Credential vault (Integrations › Credentials, also a tab of Discovery). Nothing opens from the internet inwards: the collector only makes outbound calls. Creating and running scans needs Manage agents.

Scans: see each scan with its scope, methods, last run (answered, new, without agent) and next run; Run now, Edit or remove it.

New scan: the seven-step wizard with an estimate before saving.

Credential vault: create, edit, test and remove WinRM, SSH and SNMP credentials; see how many scans use each one.

Run view: follow a run live, compare it with the previous one, read the errors and install the agent on Windows machines found without it.

In the asset detail, Discovered by shows which method, collector and scan brought each piece of data.

Scope. Mark Known networks (the ones registered and the ones seen by the agents, with their asset count) or add Other ranges as a network (CIDR, like 10.20.0.0/24 ) or From/To. Under Exclusions,

remove sensitive ranges such as industrial automation (OT) or medical equipment. Up to 65,536 addresses per scan.

Methods. Turn on what this scan uses: ICMP (ping), ARP (MAC on the same network), common TCP ports (30 ports), TLS certificates, NetBIOS (Windows name), mDNS / SSDP (printers, TVs, IoT), WMI / WinRM (Windows inventory without agent, Windows 2008 R2 included), SSH (Linux, Unix and appliances), SNMP v1/v2c/v3 (switches, routers, printers: ports, VLANs and the MAC table), LLDP and CDP (neighbors, read by SNMP). NetFlow / sFlow / IPFIX is not a scan method: the collector receives flows all the time.

Credentials. For each method with credential (WinRM, SSH, SNMP), tick one or more credentials of the vault, or create a New credential right here. The password stays in the vault and only goes to the collector with the task.

Collector and intensity. Choose the collector inside the network and the intensity: Light (50 packets/s, 32 at a time), Normal (200 packets/s, 128 at a time) or Fast (1000 packets/s, 256 at a time, asks you to confirm). The scan pauses by itself if the network gets slow. Optionally, Run only in this time window (for example 22:00 to 06:00).

Origin tags. Every asset found gets the tag Descoberto por: <method> · <collector> · <scan> (always with this name, whatever the language) and the tags you add here (press Enter after each one).

Schedule.Only when I ask, Every day or Some days of the week, at a time in your time zone. Run now, after saving starts the first run immediately.

Review. Give the Scan name and check the estimate: addresses, estimated duration and load on the network, with warnings for fast intensity, credentials and large scopes. Then Save scan.

In Integrations › Credentials, New credential asks for a Name, the Type and:

WMI / WinRM: user as DOMAIN\user or user@domain , password, WinRM transport HTTPS (5986) or HTTP (5985).

SSH: user, password and port if it is not 22.

SNMP: the version — v1 or v2c with the Community, or v3 with the SNMP v3 user, the Security level (authPriv, authNoPriv or noAuthNoPriv), the Authentication protocol (SHA-1 to SHA-512, or MD5) and password, and the Privacy protocol (AES-128, AES-192, AES-256 or DES) and password (blank uses the authentication password).

Only on these networks (optional): limit where the credential may be used, like 10.20.0.0/16 .

Test runs through a collector against one machine in three steps — Reach the port, Sign in, Collect —and shows what the method brings (system, host name, programs, services). Editing a credential updates every scan that uses it; secrets are never shown again.

The run page shows the state (Waiting for the collector, Running, Done, Failed, Cancelled), the progress in addresses and the figures Answered, New, Changed, Gone (seen in the previous run and not in this one), Without agent and Pauses (slow network). The tabs list the devices of each kind with IP, name, MAC, manufacturer, system, type, methods and open ports, and Errors explains each failure (credential refused, closed port). In Without agent, select Windows machines and click Install agent: the scan's collector installs it by WinRM with a vault credential. Cancel run stops it; Runs lists the history.

A device found by a scan goes into the inventory through the same reconciliation as the agent. From the most reliable to the least:

ARP and DNS tables that nobody cleans keep MACs and IPs of devices that are gone, so Hive treats them carefully: an ambiguous ARP MAC never merges two records, an ARP MAC that already belongs to another device is not copied, and names come only from what the device reports (no reverse DNS). When an IP now answers for a device, it is removed from the other records without agent that still kept it. If the machine already has an agent, discovery only records that it saw it.

Worked example: weekly scan of 10.10.0.0/16 with SNMP v3, SSH and WinRM



Sunday morning, open the scan's last run from Scans (click the entry under Last run).

The two pauses happened when the network got slow; the collector lowered the rate by itself. 2. New: 57 devices, among them 12 IP cameras found by ports and TLS, and two switches read by SNMP. They are now assets with the tags Descoberto por: … and Office SP .

Two notebooks already share the MAC 00:1a:2b:3c:4d:5e in the inventory (an old USB network adapter). The scan sees 10.10.8.12 with only that MAC, from the ARP table. Hive does not choose one of them: the device enters as a new asset by its IP, and the MAC is not copied to it. WS-0231 (Windows without agent, read by WinRM) received 10.10.4.20 by DHCP; that IP was still in the record of WS-0198 , also without agent. The scan matches WS-0231 by its serial number, adds 10.10.4.20 to it and removes the IP from WS-0198 . If WS-0198 had an agent, its addresses would be left alone.

Up to 65,536 addresses per scan; split larger scopes. The exclusions cannot remove every address.

A scan does not start again while its previous run is still waiting or running.

Fast can slow the network down and asks for confirmation; prefer Normal with a time window.

Without an online collector there is nothing to choose in step 4: install one first.

Scan names are unique (up to 80 characters).

Installing from a run takes up to 500 machines at a time and only Windows machines still without agent.

Removing a scan removes its history; the assets it found stay in the inventory.

Network and topology

Rolling out the agent

Step by step: create a collector

Agents and collectors



Screen: Network and topology

Maps › Network map shows the network as Hive reads it: switches, routers and printers read by SNMP, the links between them found by LLDP and CDP, which device is plugged into each port (from the switch MAC table), the traffic of each port and the racks and rooms. It has three tabs: Physical map, Ports and Racks. The data comes from discovery scans with SNMP turned on; flows (NetFlow, sFlow, IPFIX) and the agents' own connections add the traffic between machines.

Physical map: see the connection map from the Internet down to each machine, filter by Location, Highlight VLAN and click any element to light its path to the Internet.

Ports: choose a device and see the front panel of the switch, each port with state, speed, VLAN, neighbor, connected devices, traffic in Mb/s and the link use in the last 24 hours.

Racks: create racks with room, units and place in the structure, and see how many devices each one has.

On each asset (Hardware tab, Physical network): the port where it is plugged, the port history, its rack and unit, the path to the Internet and the dependency map.

Create an SNMP credential in Integrations › Credentials (community for v1/v2c, or user, authentication and privacy for v3) and turn on SNMP, LLDP and CDP in a scan with that credential. On each read, the collector brings the ports (state, speed, VLAN), the VLAN names, the MAC table and the LLDP/CDP neighbors. A device is placed on a port by the MAC table, ignoring uplinks (ports with a neighbor or with more than 8 MACs). It then carries the tags Switch: <switch> and Porta: <switch> · <port> ; when it moves, the tags change by themselves and the move goes to its port history.

The Connection map is a tree: the Internet at the top, each switch hanging from its uplink (the fastest LLDP/CDP neighbor), machines on the port where they are plugged (with port and VLAN) and VMs dashed under their host. A thick line is an aggregated link (LAG ×N with the summed speed); dashed is a link down or virtual; red has errors; neighbors Hive does not read yet are grouped apart. Moving dots show traffic toward the Internet. Devices are grouped by their place in the structure; Location shows only that place, what is below it and the path to the exit, and devices whose ports show new errors since the last read are highlighted. Highlight VLAN fades every device that does not carry the chosen VLAN.

In Ports, choose the Device. The Front panel of the switch draws the ports as on the device: green up, grey down, orange with new errors and a blue border on the uplink; hover for the port, speed, VLAN and who is connected. Below, each port shows its state, neighbor, the devices plugged into it and Traffic (↓ in · ↑ out in Mb/s and % of the link), computed by comparing the byte counters of two SNMP reads. Clicking the rate opens Link use, last 24 h (SNMP counters).

In Racks, New rack asks for the name, the Room, the Units (U) (1 to 60, default 42) and the Place in the structure (room, floor or building). On a device (Hardware tab, Physical network), choose the Rack and Unit: it inherits the tags Rack: <rack> and Sala: <room> . Deployments, patches and playbooks can target a switch, a rack or a room through these tags.

The collector always listens for flows: point switches, routers and firewalls to its IP — NetFlow v5/v9 and IPFIX on UDP 2055, sFlow v5 on UDP 6343 (each sample counts the frame size × the sampling rate).

Agents also report the connections of their own machine (who talked to whom, on which port), with nothing to set up on the switch; when both ends have an agent, only the server side counts, so nothing is doubled. The flows are summed per minute and feed the logical map and the service map.

Worked example: find where a notebook is plugged and follow its path

Worked example: a rack for the 3rd floor and traffic on an uplink

Nothing shows until a scan reads at least one device by SNMP ("No network device read by SNMP yet.").

Traffic needs two SNMP reads to compute a rate; the first read only shows counters.

A port with more than 8 MACs or with a neighbor is treated as an uplink and does not place devices.

The last hop of the path can be a neighbor Hive does not read yet: add it to a scan with SNMP to go further.

The tag names Porta and Sala are fixed, whatever the language of the console.

On Physical map the Network, Virtualization and Kubernetes buttons add layers to the tree (your choice is remembered): switch → port → hypervisor host (ESXi, Hyper-V, Proxmox or Nutanix, by the host's inventory device) → its VMs → the Kubernetes nodes running on those VMs. Clicking a host opens the hypervisor view; clicking a node opens its cluster. A host, VM or node with no known switch port goes to the group No known switch port, never under an unrelated switch. The Maps ›Virtualization shortcut opens /network?layers=virt ; /network?layers=k8s opens the Kubernetes layer.

Discovery area

Service map

Structure

Step by step: create a collector

Screen: IPAM, DNS and DHCP

Maps › Physical map, tab IPAM, shows your subnets and the use of each address. "In use" comes from what Hive already sees — the addresses of the assets, discovery scans of the last 30 days and active DHCP leases — and "reserved" from reservations made by hand (through the API) or imported from DHCP. DNS zones and DHCP scopes and leases are imported from files (BIND, Windows, ISC, Kea). IPAM only reads: it never creates or merges assets.

Subnets: add a subnet by hand with Add subnet or click Find subnets (discovery ranges, imported DHCP scopes and the /24 networks with at least 2 asset addresses). Each subnet shows a utilization bar, used, reserved and free addresses and when an address was last seen. Click the subnet to see the address grid (up to /22) and the table of addresses with MAC, name, asset and source.

Conflicts: the same IP seen with different MACs in the last 7 days (scans and DHCP), the same IP reserved more than once (by hand and on a DHCP server, or on two servers) and one MAC reserved on two addresses.

DNS: import a zone and see Stale: no live host (an A record whose address was not seen in 7 days) and Reverse does not match (the PTR of the address points to another name).

DHCP: import scopes and leases and see, for each lease, the asset that has its MAC.

BIND zone file: paste or choose the zone file ( $ORIGIN , $TTL , relative names and multi-line SOA are understood).

Windows DNS: Get-DnsServerResourceRecord -ZoneName corp.local exported with HostName , RecordType , RecordData and TimeToLive columns ( Export-Csv ).

ISC: dhcpd.leases (the last entry of each address wins) and, in the same paste, dhcpd.conf for the subnet … netmask … { range … } scopes.

DhcpServerv4Lease | Export-Csv for leases; reservations ( ActiveReservation ) become reservations of that server.

Open Import a DNS zone (in DNS) or Import DHCP scopes and leases (in DHCP), fill Server (and Zone, for DNS), choose the Format, choose the File or paste it in Content, and click Import. Importing again replaces the data of the same server (and zone, for DNS).

Worked example: find a free address and a duplicated reservation in the office

IPv4 only. Subnets from /16 to /32; the address grid is drawn up to /22.

Adding, finding and removing subnets and importing DNS or DHCP need assets:write ; reading needs assets:read . Imported files above 20 MB are refused.

Reservations by hand are made only through the API ( POST /api/v1/ipam/reservations ); the screen shows them but has no button to create or remove them.

A lease is linked to an asset only by MAC and only when exactly one asset has that MAC; a hostname or a DNS name never links (ARP and DNS are a last resort and ambiguous data does not merge assets).

"Stale" depends on what Hive sees: an address of a machine that no scan, agent or lease

reaches looks stale.

The Infoblox (WAPI) connector and reading the Windows DNS/DHCP servers directly by the

collector are not available yet: export the files and import them.

Removing a subnet does not remove addresses, reservations or the DNS/DHCP data.

Network and topology

Map timeline and export

Discovery area

Screen: Firewalls, Wi-Fi and config backups (1/2)

Screen: Firewalls, Wi-Fi and config backups (2/2)

Maps › Firewalls & Wi-Fi reads FortiGate, Palo Alto, Cisco Meraki and Ubiquiti UniFi through their own APIs with a read-only account. Each firewall, access point and switch the API returns becomes a network device in the inventory (the same one the SNMP read and the physical map use), with its interfaces, firmware version, HA state, SSIDs, Wi-Fi clients and the switch port where each access point is plugged. Maps › Config backups keeps every version of the configuration of firewalls and switches, with secrets masked, shows the difference between two versions and raises an alert when the configuration changes outside a change window. Hive never restores a configuration: you download the version and apply it yourself.

Add a source with Add source: a FortiGate, a Palo Alto firewall, a Meraki organization or a UniFi controller.

See the devices with firmware, HA, switch port, Wi-Fi clients, open CVEs and the last backup; and the SSIDs with security, band, VLAN and clients.

Read a source again with Read now, or remove it with Remove.

Open a device in Config backups, compare a version with the previous one (Side by side or Unified) and Download it.

Send a switch configuration with Upload configuration, and open a change window with Open window in Change windows so planned changes do not raise alerts.



The firmware becomes a software item of the device with its CPE (FortiOS and PAN-OS), so the vulnerability correlation finds the CVEs of that version like it does for any other software.



The account must be read-only: Hive only reads (GET, op and export calls). Restore is not done by Hive; Download gives the masked file, so secrets must be filled back by hand before applying it.

Adding a source, Read now and Remove need agents:admin ; Download, Upload configuration and Open window need assets:write . The Address must start with https:// ; Meraki needs the organization ID and UniFi the user.

The certificate of the firewall or controller must be trusted by the Hive server (import the internal CA); self-signed certificates are refused.

Switch backup by SSH through the collector is not automatic yet: use Upload configuration (or the API POST /api/v1/network/devices//config-versions ) with the text read over SSH.

A new version is saved only when the masked text changes, so a change only in a secret (a new password) is not seen.

Meraki and UniFi firmware names do not map to a CPE: their CVEs are not correlated.

UniFi OS consoles (UDM, Cloud Key Gen2) that answer only under /proxy/network are not read yet.

Configurations above 5 MB are refused.

Network and topology

Vulnerabilities

Alerts

Discovery area

Screen: Map timeline and export to draw.io and Visio

Hive keeps the history of the maps: whenever the map changes, a snapshot is stored with only what changed (nodes and links added or removed). Maps › Physical map, tab Timeline, shows the map as it was at a date and time and what changed from then until now. Every map also has draw.io and Visio buttons, next to Image (PNG) and Image (SVG), that download an editable diagram.

Choose the Map (physical map or service map) and move the slider: As of … shows how many nodes and links the map had and lists, in green, what was added since then and, in red, what was removed.

Record now (shown only when the physical map is chosen) takes a snapshot of the physical map right away (Hive also takes one every hour, the first about 15 minutes after the core starts); if nothing changed, nothing is stored.

On any map, draw.io downloads a .drawio file (open it in draw.io or diagrams.net) and Visio a .vdx file (Visio XML drawing).

Worked example: what changed in the network since last Monday

History starts when the feature is installed: there is nothing before the first snapshot. Until then the tab shows No snapshot yet.

The draw.io and Visio buttons are hidden on narrow screens (phone); use a wider window or Image (PNG).

The physical map is taken every hour, so a change that came and went within the hour may not appear. The service map has a timeline only when its nodes and links are sent through the API ( POST /api/v1/map-timeline/service/snapshot ); the console does not send it by itself yet.

Visio export is the XML drawing format ( .vdx ), not .vsdx : Visio 2013 and later open it and save it as .vsdx ; Visio for the web does not open .vdx .

The export reads the drawn map: shapes become boxes or ellipses with their text, lines become connectors attached to the shapes where they start and end. Icons, colors and dashes are not kept; use SVG for a faithful picture.

Network and topology

Service map

Map builder

IPAM, DNS and DHCP

Screen: Virtualization

Virtualization reads your hypervisors through a collector with a read-only account and shows the hosts, the VMs (and which inventory device each one is), the virtual switches, the datastores and the snapshots. It is in Discovery › Virtualization. Four kinds of connection exist: vCenter / ESXi, Hyper-V, Proxmox VE and Nutanix (Prism Central).

Connect a hypervisor with Connect hypervisor and follow the read in the Connections tab.

Read a connection again with Read now, or remove it with Disconnect.

See the topology of one connection in the Map tab (Physical and Logical views).

List the Hosts (hardware, cluster, VMs on and total) and the VMs (power state, system, network cards, inventory device).

Find the VMs that are not in the inventory with Only VMs out of the inventory.

Check the Storage tab (datastores and VM snapshots) and the Virtual switches tab (uplinks and port groups with their VLAN).

The password or token goes to the vault and only goes to the collector at read time. Each connection is read again every hour.

Each VM and each host is matched with an inventory device, from the most to the least reliable evidence: BIOS UUID (also with the first three fields byte-swapped, as Windows shows some VMware UUIDs), MAC, IP and name. The VMs tab says how each one was matched ("matched by BIOS UUID", "matched by MAC"...).

A MAC, IP or name repeated on more than one device only decides if exactly one of them has the agent; otherwise the item is not linked (an old ARP table or DNS record does not win).

A VM or host that matches no device becomes an asset with the hypervisor as its origin ("added to the inventory from the hypervisor"). This includes powered-off VMs: they enter the inventory too, so they show on the maps with the host → VM relation. When several VMs share the same BIOS UUID (copies restored from backup), the VMs that are on choose first.

When an asset created by the hypervisor later meets the real record of the machine by UUID or MAC (agent installed, discovery, integration), both are merged by themselves: the real record stays and receives the tags, groups and history of the one created by the hypervisor. If they only match by IP or name, both stay and may show up as possible duplicates.

If the device already exists, the hypervisor only links it and fills what is empty: what the agent reports wins.

The device page shows where it runs (VM on which host and cluster) or, for a host, the VMs running on it. That is what links the Kubernetes node and the database server to the VM and the host on the maps.

The team connects vCenter SP and also, for a test, the ESXi host esx03.corp.local directly as ESX03 direct .

Only UUID or MAC join items seen by two connections; an IP or a name alone never does.

Connecting, reading now and disconnecting need agents:admin ; viewing needs assets:read .

A new read cannot start while one is running ("The hypervisor is being read now.").

If the collector does not finish within an hour, the connection goes to Error with "The collector did not finish the read." and the fix "Check that the collector is online and reaches the hypervisor."

Datastores and snapshots come from vCenter and Proxmox. Hyper-V and Nutanix show hosts, VMs and networks.

For Proxmox, API token ID must be user@realm!token .

The fingerprint must be the SHA-256 of the certificate (64 hexadecimal digits, with or without ":").

The screen has no edit form: to change the address, the account or the read interval (15 to 1440 minutes, default 60) use the API ( PUT /api/v1/virtualization/connections/ ); a new password or token replaces the one in the vault. Disconnecting and connecting again would retire the assets the connection created.

Discovery

Network map

Kubernetes

Service path and logical map

Inventory

Screen: Kubernetes

Kubernetes reads your clusters through a collector with a read-only account: what runs, the images and their CVEs, the dependencies and the map from the published service down to the database. It is in Discovery › Kubernetes. The list shows each cluster with its state, contents ("nodes · workloads ·pods"), images with CVEs and the last read; click a cluster to open its detail.

Connect a cluster with Connect cluster (a 3-step wizard).

Open a cluster and use its tabs: Logical map, Service paths, Workloads, Images, Nodes and Namespaces.

Read the cluster again with Read now, change how Hive authenticates with Access, or remove it with Disconnect.

Click an object on the map to see what it depends on, who uses it and what stops if it goes down.

Each line has Copy. Under Optional: Gateway API, Istio or OpenShift routes there are two more commands to read those objects. Click Next.

The token or the certificate stays in the vault and only goes to the collector at read time.

Nodes, namespaces, workloads (Deployment, StatefulSet, DaemonSet), pods and containers (image and ports), Services, Endpoints, Ingress, network policies, volumes and, only when turned on, ConfigMaps; with the optional commands, Gateway API, Istio virtual services or OpenShift routes. Secrets are never read. From environment variables (and ConfigMaps, when read) only the addresses (host:port, URLs without password) leave the cluster, to draw the dependencies. Nodes are linked to inventory devices by name or IP.

If the account cannot list some kinds, the cluster shows "Partial read" with the kinds missing; fill User (service account) under Access to see the exact commands that grant the rest.

Logical map: from left to right, what is published (Ingress, routes), Services, workloads, data and destinations outside the cluster, and the nodes (Show nodes). Each link says where it came from (Ingress rule, label selector, Endpoints, environment variable, ConfigMap, network policy, service mesh or connection seen by the agent) and its confidence: solid line high, dashed medium, dotted low. A destination that is an inventory device shows its name; a managed cloud database shows as Cloud service. When the node's agent sees the connection, the dependency is "confirmed by the agent".

Service paths: one line per published address, from the entry to the end of the chain, with the data in bold.

Workloads and Nodes: what runs, how many replicas are ready and the inventory device of each node.

Images: product and version come from the image name and tag (postgres:16.2 → PostgreSQL 16.2) and the CVEs are those of that version in the NVD, with the exploited ones (KEV) highlighted. Images without a fixed version show "no fixed version (latest or digest)". Packages inside the image are not read.

Namespaces: one card per namespace with what runs in it; click to open its map.

Click any object on the map to see Goes to, Used by and If it goes down: what stops and what only loses capacity (a workload with replicas on other nodes).

Connecting, reading now, changing access and disconnecting need agents:admin ; viewing needs assets:read .

The API address must start with https:// . The CA must be the decoded PEM (BEGIN CERTIFICATE).

A client certificate pasted in the token field is refused with "This is a client certificate: choose that option."

Disconnect removes what was read and the token in the vault; the cluster itself is not touched.

The read interval (15 to 1440 minutes, default 60) is changed only through the API.

The logical map goes from left to right (or top to bottom: Horizontal, Vertical or Automatic, remembered per person): what is published (Ingress, routes), Services, workloads, data and destinations outside the cluster, and the nodes. Each link says where it came from — Ingress rule, label selector, Endpoints, environment variable, ConfigMap, network policy, service mesh or a connection seen by the agent — and the confidence (high, medium, low). A destination that is an inventory device (a database server) shows its name; a managed cloud database (RDS, Azure SQL, Cloud SQL) shows as a cloud service. When the node's agent sees the connection to the destination, the dependency is confirmed.

Use Levels to show from the entries down to the level you choose (1 = only what is published; the last one = everything down to the nodes); it starts at a readable level. With more than one namespace, each namespace is a box; on Map of the whole cluster click the name to collapse or expand it. A big layer splits into more columns, the order crosses as few lines as possible and Fit makes it fit the screen. Clicking an object opens the panel beside the map: what it depends on, what it affects and what stops if it goes down.

Service paths shows, for each published address, the hops down to the database, grouped by namespace (search by name or host, filter by namespace and host). Each hop is a chip with its kind, name and a short state: host:port and TLS on the entry, type and ports on the Service, ready/desired replicas on the workload and the address of the data at the end. Click a path for the mini-map and the panel with the public host, the pods and the nodes they run on, the images with CVEs/KEV and what stops if the end of the chain goes down; Open in the logical map shows the whole map with that chain highlighted (or only it). Click an object on the map to see what stops if it goes down: whoever depends on it stops; a workload with replicas on other nodes loses capacity when a node goes down.

A cluster discovered by a cloud account (Cloud → Resources, kind Kubernetes) is read with the identity of the cloud account, without a service account token: Read this cluster takes the API address and the CA from the provider, and at each read the core generates a short-lived token that goes to the collector with the task (it is never stored). In the account, Kubernetes turns on reading every managed cluster automatically, with the collector that reaches them. The Kubernetes list shows the provider and the account; the cluster page links back to the cloud resource. Token or client certificate under Access still work for any cluster.

Example — EKS. Account "AWS prod" (access key of the IAM user hive-reader) finds aurora-eks in us-east-1. Read this cluster calls DescribeCluster (address and CA) and each read uses the same token as aws eks get-token . If the cluster answers 401 or 403, the page shows the commands with the ARN of the key: aws eks create-access-entry --cluster-name aurora-eks --region us-east-1 --principal-arn arn:aws:iam::123456789012:user/hive-reader and aws eks associate-access-policy ... --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy --access-scope type=cluster . If nodes or volumes stay missing, bind hive-read to a group and put the group on the access entry ( --kubernetes-groups hive-readers ). Only clusters in CONFIG_MAP mode (aws-auth) use eksctl create

Example — AKS. Account "Azure prod" (app registration with Reader) finds aurora-aks. The core takes the address and the CA from listClusterUserCredential and signs in with a Microsoft Entra token for the AKS server application. Give the service principal "Azure Kubernetes Service RBAC Reader" and "Azure Kubernetes Service Cluster User Role" on the cluster ( az role assignment create --assignee <app id> --role ... --scope <cluster id> ), or, with Kubernetes RBAC, bind hive-read to its object id ( --user= <object id> ). A cluster with local accounts only does not accept the Entra token: connect it with a token.

Example — GKE. Account "GCP lab" (service account key) finds aurora-gke. The core takes the endpoint and the CA from clusters.get and signs in with the OAuth token of the service account. Give it roles/container.viewer ( gcloud projects add-iam-policy-binding <project> --member=serviceAccount:<email>--role=roles/container.viewer ) or bind hive-read to the e-mail of the service account.

ConfigMaps often hold passwords, tokens and keys, so the main hive-read role no longer includes them. In the wizard, Optional: read ConfigMaps (off by default) shows a warning and two separate commands ( hive-read-configmaps ); turn on Read ConfigMaps (endpoints only) under Access to use them. Even then the collector keeps only what looks like an address and drops everything else before sending:

Kept: host and port of URLs ( postgres://app:[email protected]:5432/orders → pg.data:5432 ), of JDBC ( jdbc:sqlserver://mssql.corp:1433;… , Oracle @//ora.corp:1521/ORCL ), of DSN strings ( Server=sql01,1433;… , host=pg port=5433 … , user:pw@tcp(mysql:3306)/db ) and of host:port lists (Kafka bootstrap).

Dropped: users, passwords, tokens, keys, certificates, paths, query parameters and any value that is not an address; only the names of the keys that held an address are kept.

With reading off the cluster shows the note "ConfigMap not read (optional; may contain secrets)" — it is never listed as missing in a partial read.

A Service reaches its workload by, in this order: the pods listed in its EndpointSlices (discovery.k8s.io) or Endpoints; the label selector on the pods; the selector on the workload's pod template (a workload scaled to 0). A pod whose ReplicaSet was not read still reaches its Deployment by the pod-template-hash . When nothing is found the chain ends with an explicit marker instead of stopping silently: Service without endpoints (no pod matches the selector, no pod ready, or no selector) or the workload with 0 replicas.

Cluster DNS names point to the real Service, in any namespace, instead of a node "outside the cluster": svc , svc.ns , svc.ns.svc , svc.ns.svc.cluster.local and the pod name of a headless Service ( kafka-0.kafka-headless.hml-tools.svc.cluster.local ), found in environment variables, arguments, ConfigMap addresses, ExternalName, Gateway and Istio routes. Two more sources add links: traffic seen (NetFlow/IPFIX and the agents' flows from a pod IP to a ClusterIP or pod IP, origin seen in traffic, high confidence; it also confirms a link the configuration already declared) and a NetworkPolicy with namespaceSelector (declared, medium confidence).



Opening a namespace shows one consolidated map with all its paths: entries on the left, objects used by several paths marked shared by N, the common end marked, and every namespace it depends on as a block ("hml-tools · 3 here depend on it", with what is used there). Click a block to open it in place (recursively, following Levels) or ↗ to open its own map in a new tab.

Selecting an object draws its impact on the map, even outside Only this path or the levels shown: red stops, orange loses capacity, gray uses it, blue is what it depends on; items outside the original view are dashed. Show impact / Back to the path switches it. Clicking an item in the side panel shows it on the map (and the first click on an affected node highlights it in the panel). Published services that stop lists each entry (host, kind, namespace and the business service, when there is one) with a link to its path in Service paths.

Cloud

Virtualization

Service path and logical map

Vulnerabilities

Screen: API inventory

The API inventory lists the APIs of the company with their operations (method, path, authentication and tags) and shows the shadow APIs: routes that the applications answer or that the Ingress publishes without any documentation. It is in Discovery › APIs.

Import an OpenAPI 3 or Swagger 2 document (JSON or YAML), pasted or fetched from an https address.

Read the APIs of a gateway: Kong Admin API, Azure API Management or Apigee.

Open an API to see each operation and which ones declare no authentication.

See the Kubernetes Service that publishes the API (found through the Ingress path) and the business service.

Compare what is documented with what is seen: undocumented routes and documented operations never called.