Configure Microsoft Azure Key Vault integration for Tenable One Vulnerability Management

The Tenable Azure Key Vault integration exists as an authentication method within the SSH, Windows, Database, VMware ESXi SOAP API, VMware vCenter API, and Nutanix credential types in Tenable One Vulnerability Management scan policies.

Required permissions

  • A Tenable One Vulnerability Management user account with a minimum role of Standard.

  • A Microsoft Entra ID App registration (service principal) in the tenant that owns the Key Vault. The Application (client) ID and a Client secret from that App registration are required.

  • The service principal must be granted the Key Vault Secrets User built-in role (or a custom role with the Microsoft.KeyVault/vaults/secrets/getSecret/action data action) on the target Key Vault, either through Azure RBAC or the vault's access policies. Granting the role at the individual vault scope is sufficient; subscription-wide access is not required.

  • Every credential stored in the vault must be a JSON object whose keys use the field names described earlier (username, password, ssh_key, ssh_keyphrase, domain). Plain-text secrets are supported and are treated as a password only.

Note: For compliance audits, add audit files to your scan policy. The Azure Key Vault integration provides credentials only.

Scan configuration — Windows, SSH, Database, VMware, and Nutanix

Complete the following steps to configure Tenable One Vulnerability Management with the Azure Key Vault integration using the Windows, SSH, or Database credential types.

  1. Log in to your Tenable One Vulnerability Management user interface.

  2. In the left navigation pane, click Scans. The Scans page appears.

  3. In the upper-right corner of the page, click the Create a Scan button. The Select a Scan Template page appears.

  4. Select a scan template. The scan configuration page appears.

  5. In the Name box, type a name for the scan.

  6. In the Targets box, type an IP address, hostname, or range of IP addresses.

  7. (Optional) Add a description, folder location, scanner location, and specify target groups.

  8. Click the Credentials tab. The Credentials pane appears.

  9. In the Select a Credential menu, select Windows, SSH, Database, VMware ESXi SOAP API, VMware vCenter API, or Nutanix from the options. The Settings pane for the selected credential appears.

  10. In the Auth Type drop-down box, click Azure Key Vault. The Azure Key Vault options appear.

  11. Configure each option for the selected Windows, SSH, Database, VMware, or Nutanix credential using the values in the table below.

    Option Description Required
    Username The username to log in to the target system(s). Optional if a username field is present in the Azure Key Vault secret JSON; when supplied here it overrides the value stored in the secret. No
    Tenant ID The Microsoft Entra ID (Azure AD) Directory (tenant) ID that owns the Key Vault. Used to build the OAuth2 token endpoint https://login.microsoftonline.com/<tenant_id>/oauth2/v2.0/token. Yes
    Application ID The Application (client) ID of the Microsoft Entra ID service principal registered under App registrations. Also referred to as the Client ID. Yes
    Client Secret The client secret value generated for the service principal under Certificates & secrets. Used together with the Application ID and Tenant ID for the OAuth2 client_credentials grant. Yes
    Key Vault Name The name of the Azure Key Vault (not the full URL). Tenable derives the API host from this value as <Key Vault Name>.vault.azure.net. Yes
    Secret Name The name of the Key Vault secret that stores the target credentials. The secret value is expected to be a JSON object containing one or more of the fields: username, password, ssh_key, ssh_keyphrase, domain. Yes
    Use Kerberos KDC (Windows-only) When enabled, Kerberos authentication is used to log in to Windows targets. Selecting Yes reveals the Key Distribution Center (KDC), KDC Port (default 88), KDC Transport (tcp / udp), and Domain fields. No
    Fetch Domain (Windows-only) When enabled, the integration reads the api_domain field from the secret JSON and uses it as the Windows domain for the target authentication. Domain precedence: KDC Domain > manually entered Domain > domain from the secret. No
    Elevate privileges with (SSH-only) The privilege escalation method used after initial authentication. Supported options include Nothing (default), .k5login, Cisco enable, dzdo, pbrun, su, su+sudo, sudo, and Checkpoint Gaia expert. Selecting a value reveals the escalation credential fields described in the Optional features section. No
    Escalation Credential ID (SSH-only) The name of a separate Key Vault secret whose password field is used as the privilege escalation password. If left blank while an escalation method is selected, the primary secret's password is reused. No
    Database Port (Database-only) The TCP port on the target database used for the credentialed check. Defaults to the standard port for the selected database type (for example 1521 for Oracle, 1433 for SQL Server, 3306 for MySQL, 5432 for PostgreSQL, 50000 for DB2, 27017 for MongoDB). Yes
    Database Name / SID (Database-only) The database name, SID, or service name to connect to on the target. Optional for engines where a default database exists (for example postgres for PostgreSQL, admin for MongoDB). No

Do one of the following:

  • If you want to save without launching the scan, click Save.

  • If you want to save and launch the scan immediately, click Save & Launch.

Note: If you scheduled the scan to run at a later time, the Save & Launch option is not available.