What Information Does the Keeper Commander Integration Collect?

The Keeper Commander PAM integration collects credentials from the Keeper Commander Service Mode REST API. The Keeper Commander PAM integration collects only the credential material required to authenticate to a scan target. The integration retrieves a Keeper Commander record and reads the following fields from it:

  • login: The target account username (required for all record types).

  • password: The target account password, read from pamUser records.

  • keyPair.privateKey: A PEM-encoded SSH private key, read from sshKeys records.

  • passphrase: The passphrase for an encrypted SSH private key. Stored as a separate field on the sshKeys record (not nested inside keyPair). Extracted automatically when present — no additional configuration is required.

Note: password vs. SSH private key — The integration infers the credential type from the Keeper record itself. For pamUser records it extracts login and password. For sshKeys records it extracts login and keyPair.privateKey, plus passphrase if the record includes one. If the expected field is absent, credential retrieval fails and an error is written to the debug log

Keeper Commander REST API Versions

The Keeper Commander Service Mode REST API exposes two API generations. The current Tenable integration requires the v2 async API.

Note: If your Keeper Commander deployment only exposes the v1 endpoint, upgrade Keeper Commander to a version that includes the v2 async API (17.1.7 and later) before configuring this integration.

The v2 API uses a three-step async pattern:

  1. POST /api/v2/executecommand-async — submits the command and returns a request_id immediately.

  2. GET /api/v2/status/<request_id> — poll for completion. The integration polls once per second for up to 30 seconds. The status field in the response is one of pending, completed, failed, or expired.

  3. GET /api/v2/result/<request_id> — fetches the final result once the status is completed.

The Engine URL field in the scan credential is an optional base prefix for the Commander service (for example, if the Keeper Commander executecommand-async endpoint is found at /commander/api/v2/executecommand-async, then the appropriate Engine URL value would be /commander. The integration appends the correct API path for each step.

API Requests per Target

For each distinct Keeper Commander record referenced in the scan policy, the integration makes the following API calls to the Keeper Commander service:

  • Three requests to retrieve the primary credential: one POST to submit the get <uid> --unmask --format json command, up to 30 GET polls for status, and one GET to fetch the result.

  • If Query Mode is set to Search string, one additional set of three requests is made first to execute the search <term> command and resolve the record UID before the record retrieval above. If Search scan target is also enabled, the search term includes the target's IP address or hostname, so each distinct target that resolves to a different record produces a separate set of requests (results are still cached per unique search term).

  • If privilege escalation is configured with a separate Escalation Credential ID or Escalation Search Text, one extra set of three requests is made to retrieve the escalation record. If Escalation Query Mode is Search String and Escalation search scan target is enabled, the same per-target expansion applies.

Retrieved credentials are cached for the duration of the scan, keyed by lookup mode and lookup value (record UID or search term), to avoid redundant requests for the same record. The cache is not shared between scan chunks, so each chunk produces a minimum of one credential retrieval sequence.

Credentialed Scans

Credentialed scans allow the Tenable scanner to log in to the target system directly and perform a deeper assessment than is possible without credentials. This includes checking installed software versions, configuration settings, patch levels, and compliance status.

What the Keeper Commander Integration Does Not Collect

  • The integration does not collect vulnerability data, software inventory, device inventory, or configuration details from target systems — it only retrieves credentials that Tenable then uses to authenticate to those targets.

  • The integration does not parse other record types (such as login, bankAccount, or custom types), and attempting to use them causes credential retrieval to fail.

  • The integration does not enumerate vault contents or discover scan targets. Specify targets explicitly in the scan.