Vault Device Management

Overview

The Vault Device Management tab gives you visibility into and control over the physical devices assigned to each vault agent's Quantum Trust Domain (QTD).

These devices are network switches, firewalls, and ObjectScale vault management endpoints. The vault agent operates them to enforce the airgap boundary.

Quantum Trust Domains

Each registered vault agent defines a Quantum Trust Domain. It is a security perimeter in which air-gap switch passwords are protected by ML-KEM-1024 post-quantum encryption (NIST FIPS 203).

Air-gap switch passwords are protected with the vault agent's ML-KEM-1024 public key (key encapsulation) and encrypted with AES-256-GCM. Only the vault agent on the vault host can decrypt them. This applies to switch passwords only. The console can decrypt all other credentials. See Credential storage on the console.

Device types

Label	Color	Description
Switch · RESTCONF / Switch · SSH CLI	Blue	A network switch. The vault agent shuts and re-opens the airgap interface over the protocol shown.
ECS Vault	Green	An ObjectScale management endpoint. The vault agent uses the management API to rotate S3 service account keys.
ECS API	Teal	A generic ObjectScale API device.

How devices get assigned to a domain

ECS Vault devices

ECS Vault devices are assigned automatically. When you click Switch to Vault Mode on the Vault Data Sync Dashboard, the ObjectScale devices associated with the protected groups move into the Quantum Trust Domain of the selected vault agent as ECS Vault devices. No manual action is needed.

Network switches

You add network switches manually. Click Add Airgap Control Device on a domain card to register a switch (device type Network Switch).

This tab is the only place where you add or change a switch. The Vault Agents config panel shows the same switches read-only.

Field	Description
Protocol	How the vault agent talks to the switch. See Protocol.
IP address and port	The switch management address. The port follows the protocol: 443 for RESTCONF and 22 for SSH. A port you typed yourself is kept when you change the protocol.
Username and password	A switch account that is allowed to change interface state. You can set the password now or push it later with the Send button. An SSH switch can log in with an SSH key instead. See SSH login.
Interfaces	The interfaces that link the vault to the outside. Enter one per line or separate them with commas, for example port-channel21 or ethernet1/1/5. These are Dell OS10 names, and breakout ports such as ethernet1/1/49:2 are allowed. At least one is required. See Interfaces.
Certificate trust (RESTCONF only)	How the vault agent checks that it is talking to the real switch. See Certificate trust.
SSH host key fingerprint (SSH only)	The switch's host key. See SSH host key fingerprint.
Login (SSH only)	How the vault agent logs in as the switch user. See SSH login.
Mode	Enforce (default): the agent opens and closes the interfaces. Log only: the agent reads the switch but only logs the changes it would make. The airgap is not enforced in Log only mode. Use it for a first check on a new switch.

Protocol

• RESTCONF (HTTPS) is the default. It uses the Dell OS10 RESTCONF API over HTTPS.
• SSH (CLI) uses the Dell OS10 command line over SSH (shutdown and no shutdown on the interface).

RESTCONF must be enabled once on the switch. In configuration mode, run rest api restconf, then run write memory. Without write memory, the setting is lost on the next switch reboot.

Interfaces

When the link is a LAG, enter the port-channel itself and never its member ports. Shutting one member leaves the link up through the others.

The airgap counts as closed only when every listed interface is confirmed shut.

Certificate trust (RESTCONF)

Certificate checking is never switched off. Choose one option:

• Pin certificate. Enter the switch certificate's SHA-256 fingerprint. Colons are optional. Dell OS10 ships a self-signed certificate without a host name, so pinning is the usual choice.
• Trust CA. Paste or load the PEM of the CA that signed the switch certificate.

To get the fingerprint, use Fetch via vault agent (see below). You can also run this command on a host that reaches the switch:

openssl s_client -connect <ip>:443 </dev/null | openssl x509 -noout -fingerprint -sha256

If the switch regenerates its certificate, update the pin. Health then reports a certificate mismatch (VA-009). Fetch the fingerprint again.

SSH host key fingerprint (SSH)

Enter the switch's host key in SHA256:… form. 64 hex characters are also accepted.

Use Fetch via vault agent. It returns the fingerprint of the key type that the agent actually negotiates with the switch.

You can also list the fingerprints with this command:

ssh-keyscan <ip> 2>/dev/null | ssh-keygen -lf -

It lists one fingerprint per key type (RSA, ECDSA, ED25519). Only the type that the agent negotiates matches. On a switch that offers an ED25519 host key, such as Dell OS10 10.6, that is the ED25519 one.

SSH login

Choose how the vault agent logs in to the switch user:

• Password (default) uses the password above.
• SSH key > Generate on the vault agent (recommended).
• SSH key > Paste an existing private key.

Generate on the vault agent

1. The vault agent creates an ECDSA P-256 key pair at its next check-in. The private key is created on the agent and never leaves it. It is stored there, encrypted to that host.
2. The device card then shows the public key with a copy button. Until the agent has created the key, the card shows Key not generated yet.
3. Add the public key to the SSH keys of the switch user on the switch.

Behavior to know about:

• When an existing switch moves to the generated key, the agent keeps using the switch's previous login (its password or the pasted key) until the generated key has logged in once. The vault still closes while you add the key.
• Meanwhile, the switch's health shows a warning that the switch does not accept the key yet. After the first login with the key, the previous login is no longer used.
• To change that previous password, set the login to Password first. A password saved while the generated key is chosen is refused, because it would not be sent.
• A switch that starts with the generated key has no previous login. The agent can log in only once the key is on the switch.
• If you reinstall the vault agent, its key is lost. The agent makes a new key at its next check-in, and the card shows the new public key. Put that key on the switch. Until then, the agent cannot log in to the switch.
• The key is kept while the device exists. If you switch to another login and back to the generated key, the key the switch already has is reused.
• Each report appears in the QTD Communications tab as SWITCH_SSH_KEY.

Paste an existing private key

Paste or load the private key file in OpenSSH format (-----BEGIN OPENSSH PRIVATE KEY-----) or PEM format (RSA, ECDSA, Ed25519).

• The console checks the key, then sends it to the vault agent encrypted with ML-KEM-1024, exactly like a password.
• The console keeps only the encrypted copy and the public key. The form shows the public key with its fingerprint.
• Keys with a passphrase are refused, because the agent has nobody to type it. Remove the passphrase on a copy of the key file with ssh-keygen -p -f <copy> -N "", and paste that copy.
• For PuTTY .ppk keys, export them in PuTTYgen with Conversions > Export OpenSSH key.
• When you edit the device, leave the key field empty to keep the current key.

Changing the login

Changing the login needs the new secret in the same save:

• A pasted key when you move to a pasted key.
• A password when you move back to Password.
• A password when you change a key-login switch to RESTCONF, which always uses a password.

The old secret is never used for the new login.

A key-login switch has no Send button. Edit the device to replace the key. The card shows SSH key login or Key generated on vault agent for these switches.

Fetch via vault agent

The console usually cannot reach the switch, because the switch sits inside the vault. The selected vault agent therefore reads the fingerprint for you.

1. Choose the vault agent and enter the address and port.
2. Click Fetch via vault agent. The request waits for the agent's next check-in (heartbeat). Keep the form open and it updates by itself, or type the value in meanwhile.
3. The agent connects to the address and port, reads the certificate (RESTCONF) or host key (SSH), and disconnects. It sends no username or password and changes nothing.
4. The form shows the fingerprint. For a certificate it also shows the subject, issuer, and validity. It warns if the value differs from the one already in the field.
5. Compare the fingerprint with a value from the switch administrator or from the switch's own console. Whatever answered on that address gave this value.
6. Click Use this fingerprint to fill the field, or Discard to drop it. Nothing is stored until you click Save.

If the agent cannot connect, the form shows its error, for example cannot connect … Connection refused.

Each fetch appears in the QTD Communications tab as SWITCH_TRUST_FETCH, and the agent's answer appears as SWITCH_TRUST_RESULT.

A fetch that gets no answer fails with a message instead of waiting forever:

• After 10 minutes once the agent has picked it up, for example when the agent restarted meanwhile.
• After twice the agent's heartbeat interval if the agent never checks in.

Fetch again once the agent is back.

Trust badges

• Until the certificate trust (RESTCONF) or host key (SSH) is set, the card shows an amber Trust not set badge and the agent does not connect to the switch.
• Trust belongs to the protocol. Changing a switch from RESTCONF to SSH, or back, clears the other protocol's certificate trust or host key. After you change it back, set the trust again.
• In Log only mode, the card shows a red Log only — airgap NOT enforced badge.

Switches that were added as SSH devices show SSH CLI.

How the vault agent opens and closes the airgap

The vault agent opens the airgap when it needs the outside network, for its heartbeat or a sync. It closes the airgap when the last of those is done.

For every switch in its Quantum Trust Domain, the agent changes the listed interfaces and then reads the result back from the switch. It never trusts the command alone.

Open

1. The agent enables every interface.
2. It checks every 2 seconds, for up to 60 seconds, that they are up. A port-channel usually needs a few seconds for LACP.
3. If at least one interface came up, the vault opens. Interfaces that did not come up raise VA-006 (warning).
4. If none came up, the agent shuts everything again and raises VA-005. The heartbeat or sync does not run.

Close

The close is strict. The airgap counts as closed only when every interface reads back as shut. An interface that no longer exists on the switch counts as not closed.

If the close cannot be confirmed:

• The agent raises VA-007 (critical).
• It retries three times after 5 seconds, then every 60 seconds until it succeeds.
• It starts no new sync meanwhile.
• Its heartbeat keeps reaching the console, because the link is still up.

Retry close now

While a close is not confirmed, the agent's switch cards on this tab show a red Airgap close NOT confirmed box. The agent's Airgap Switches block on the Vault Agents tab shows it too. The box shows the agent's last message and a Retry close now button.

Use the button after you fix the cause, for example a corrected pin or password. The agent then does not wait for its next 60-second retry.

• The request is sent at the agent's next check-in. While a close is not confirmed, the agent checks in at least every 5 minutes, whatever its heartbeat interval.
• The box shows Retry requested … until then and Last retry request sent … afterward.
• The box disappears when the agent reports the close as confirmed. VA-007 then clears itself.
• The agent reports it at once when it can still reach the console with the vault closed. Otherwise it reports at its next check-in.
• Each request appears in the QTD Communications tab as AIRGAP_RETRY_CLOSE.

Other situations

Situation	Behavior
Log only switches	They are read for real, but the agent only logs the change it would make. They never block an open or a close.
Restart	If the agent restarts while it has the vault open (crash, reboot, or self-upgrade), it keeps the vault open so that running copy jobs keep their network. It closes the vault the normal way once they are done.
Drift	Every 5 minutes, and at startup, the agent checks that no enforced interface is up while it has not opened the vault. If one is, it raises VA-008 (critical) at once and does not change the port at that moment. Its normal open and close cycle keeps running, so the next close shuts that port. VA-008 clears itself when every interface reads shut again.
No switch configured	Opening and closing do nothing.
Switch deleted or set to Log only while VA-005, VA-006, VA-007, or VA-008 is up	See below.

The product has no maintenance window that would make a manually opened link expected. A manually opened interface is therefore reported as drift.

When a switch is deleted or set to Log only while one of those alarms is up, the agent has nothing left to open, close, or watch. It reports the open, the confirmed close, or the cleared drift, and the alarm clears.

Nothing was actually opened, shut, or checked in that case. The cleared alarm (Alarms > History, Clear context) carries a note saying so. Check the switch port yourself.

The agent learns about the change at its next check-in. While every open fails, it does not check in unless a close is pending, so it keeps using the switches it already knows until then.

Alarms

Alarm	Severity	Meaning	Clears automatically when
VA-005	Warning	The airgap failed to open. No interface came up.	The next open succeeds.
VA-006	Warning	The airgap opened degraded. Some interfaces did not come up.	An open brings every interface up.
VA-007	Critical	The airgap close is not confirmed. The vault link may be open.	The close is confirmed.
VA-008	Critical	An interface is up while the vault should be closed.	Every interface reads shut again, including after the agent's next close.
VA-009	Warning	Switch health problem: unreachable, certificate or host key mismatch, login rejected, unsupported OS10 version, or a listed interface missing.	A later health report for that switch is healthy.

Alarms found while the vault is closed reach the console at the agent's next heartbeat. Drift is sent at once.

Switch health on the device card

Each time device health is collected (every heartbeat, or Request Health), the agent checks every switch without changing anything. It:

1. Connects to the switch.
2. Verifies the certificate (RESTCONF) or host key (SSH).
3. Logs in.
4. Reads the OS10 version.
5. Reads every listed interface.

The health badge shows Healthy, Degraded (warnings only), Critical (an error), or Unreachable. Expand it to see the problems, the OS10 version, and each interface's admin and link state.

For RESTCONF switches, the OS10 version is also checked:

• Below 10.5 is an error. RESTCONF interface control needs 10.5 or later.
• A build affected by Dell advisory DSA-2021-189, a RESTCONF authentication bypass, is a warning. Upgrade to at least 10.5.0.10, 10.5.1.11, 10.5.2.11, or 10.5.3.5 on that branch. Version 10.5.4 and later, including 10.6, are not affected.

ECS Vault credential sync

ECS Vault devices need the vault agent to receive the ObjectScale management API credentials before it can rotate keys. The credentials are the host, port, management username, and password. The credential sync section appears inline below each ECS Vault device row.

Delivery lifecycle

1. Push Credentials. Click Push Credentials, or let Vault Mode activation trigger it automatically. The console encrypts the management credentials with ML-KEM-1024 and the vault agent's public key, and marks the device QUEUED. A CREDENTIAL_DELIVERY record appears in the Quantum Trust Protocol Audit Log panel.
2. Agent collects. On the vault agent's next heartbeat, it detects the QUEUED status, decrypts the bundle locally, and stores the management credentials in its machine-bound AES-256-GCM store.
3. Agent acknowledges. The vault agent calls /api/vault-devices/{id}/ack-credential. The status advances to DELIVERED, and the QTD record shows Acked in the Quantum Trust Protocol (QTP) pipeline.

Credential sync buttons

Button	When shown	Action
Push Credentials	Status is NONE (not yet delivered).	Encrypts the management credentials and queues them for agent delivery.
Re-Push	Status is QUEUED (queued but not yet acknowledged).	Queues delivery again and replaces the existing bundle.
Re-Sync	Status is DELIVERED.	Queues delivery again. Use it after the management password changes or for troubleshooting.

If the status stays QUEUED for more than a few minutes, check that the vault agent is running and reaching the console (Vault Agents tab > Dashboard).

Switch credential push

For switch devices, credentials are delivered by the same asynchronous encrypted dead-drop mechanism. The credential is a password or a pasted SSH private key.

1. Click the Send (→) button on a device row and enter the new password.
2. The console encrypts the password with ML-KEM-1024 and marks the credential QUEUED.
3. On the vault agent's next heartbeat, the agent decrypts and stores the password locally.
4. The console advances the status to DELIVERED when the agent acknowledges receipt.

Credential status

Status	Meaning
(no badge)	No password has been set for this device.
PQ-Secured	A password is stored on the console, encrypted with ML-KEM-1024. It is shown next to the status badge.
Queued (amber, pulsing)	Credentials are encrypted and stored on the console. They await the next vault agent heartbeat.
Delivered (green)	The vault agent has decrypted and stored the credentials locally. Delivery is confirmed.

Vault device health

The vault agent collects health snapshots from assigned devices on every heartbeat. It reports them to the console over the ML-KEM-1024 QTP encrypted channel. Health data is visible in the device list.

Health badge

Every device row shows a color-coded health badge.

Badge	Color	Meaning
HEALTHY	Green	No active alarms, storage within normal thresholds, and the device is reachable.
DEGRADED	Amber	Minor or warning alarms are present, or storage is 75–89% used.
CRITICAL	Red	Critical or major alarms are present, or storage is 90% used or more.
UNKNOWN	Gray	No health data has been collected yet, or the device type has no health collector.
UNREACHABLE	Dark gray	The management API was not reachable during the last collection.

The badge also shows the alarm count (for example 2) and the storage free percentage (for example 38% free).

Health detail panel

Click the health badge to expand the full health detail panel for that device.

Section	Content
Connectivity	Whether the device management API was reachable, and the latency in ms.
Storage	Capacity bars with used and free GB and the usage percentage. The color turns amber at 75% and red at 90%.
Active Alarms	All reported alarms with a severity badge (CRITICAL, MAJOR, MINOR, WARNING, or INFO), a description, and the acknowledged status.
Vendor data	Device-specific metadata, for example API endpoint, ObjectScale version, node count, and auth status.
Collection errors	Errors found while collecting health data, for example auth failure or connection refused.
Last checked	The date and time of the snapshot, plus the start of the QTP message ID for cross-referencing in the Quantum Trust Protocol Audit Log tab.

Request Health

Click Request Health in the domain card header to request a health collection with an explicit audit record.

The console creates a DEVICE_HEALTH_REQUEST record and sets a flag that is delivered to the vault agent on its next heartbeat. The agent already collects health on every heartbeat, so this does not make the collection come sooner. It records that you asked for it.

After you click Request Health, a confirmation message appears. Health data refreshes after the agent's next heartbeat. The tab reloads devices and health every 30 seconds.

The empty health panel still says "click Poll Now". That text refers to this button.

Quantum Trust Protocol Audit Log

Health exchanges appear in the Quantum Trust Protocol Audit Log tab as two message types:

Type	Direction	Meaning
Health Req	Console > Agent	A health collection was requested with Request Health.
Health Report	Agent > Console	The vault agent posted a health snapshot.

Use the type filter to isolate health messages and track their three-stage pipeline (Req > Del > Ack).

Health data collected per device type

Device type	Alarms	Storage	Connectivity
ECS Vault	GET /vdc/alerts/latest (unacknowledged alerts)	GET /object/capacity (cluster total and free)	HTTPS reachability to port 4443
Switch	Problems found by the switch check. See Switch health on the device card.	Not collected	Connection, certificate or host key, and login to the switch's management address

Health collection is not available for other device types.

Edit a device

Click the key icon on a device row to edit its connection properties:

• Protocol
• IP address and port
• Username
• Interfaces
• Certificate trust or host key
• Mode

You can set a new password in the edit form. This replaces the existing bundle and sets the status back to QUEUED.

Security notes

• ML-KEM-1024 (NIST FIPS 203) is a post-quantum key encapsulation mechanism that resists attacks from both classical and quantum computers.
• The console stores only ciphertext. An attacker who compromises the console database cannot recover device passwords without the vault agent's private key.
• The vault agent's private key is stored on the vault host, encrypted with AES-256-GCM and bound to that host. Credentials are invalidated if the host changes.