See the following sections for the configuration settings required by the Key Vault plugin.

Configuration

To use the plugin, you must provide a configuration file (JSON) with the following required fields:

{
  "vaultNames": "<vault-selector>",
  "clientId": "<azure-client-id>",
  "clientSecret": "<azure-client-secret>",
  "tenantId": "<azure-tenant-id>",
  "subscriptionNames": "<subscription-selector>"
}

• vaultNames: Comma-separated vault selectors. Each entry may be an exact vault name or a * wildcard pattern used by the plugin input.
• clientId: Azure AD Application (client) ID
• clientSecret: Azure AD Application client secret
• tenantId: Azure AD Directory (tenant) ID
• subscriptionNames: Comma-separated subscription selectors. Each entry must be an exact subscription display name or a * wildcard pattern. Subscription IDs (UUIDs) are not accepted.

Legacy fields are not supported: requests containing vaultUrl or subscriptionId are rejected during test and scan.

Migration requirement:

• Delete old configurations that contain legacy fields and create a new configuration using only vaultNames and subscriptionNames.
• If an old configuration is loaded in UI and triggers an immediate test, that failure is expected until the configuration is recreated in the new schema.

Selector Usage

The plugin matches subscriptionNames and vaultNames as selectors, not Azure resource-name syntax.

Subscription selectors

• Exact display names are matched case-insensitively.
• * is supported as a wildcard inside selector entries.
• Subscription IDs (UUIDs) are not accepted — use the subscription display name.

Vault selectors

• Exact vault names are matched case-insensitively.
• * is supported as a wildcard inside selector entries.

Examples:

• prod-* matches any subscription or vault whose name begins with prod-
• * selects all discovered subscriptions or vaults
• Production East matches that subscription display name exactly (case-insensitive)

The * character is only a plugin selector token. It is not a literal Azure resource name character.

Example Input Configurations

Exact names — scan specific vaults in specific subscriptions:

{
  "config": {
    "subscriptionNames": "prod-east, shared-services",
    "vaultNames": "vault-payments, vault-iam",
    "tenantId": "<azure-tenant-id>",
    "clientId": "<azure-client-id>",
    "clientSecret": "<azure-client-secret>"
  }
}

Wildcard names — scan all matching vaults across matching subscriptions:

{
  "config": {
    "subscriptionNames": "prod-*",
    "vaultNames": "colo-*",
    "tenantId": "<azure-tenant-id>",
    "clientId": "<azure-client-id>",
    "clientSecret": "<azure-client-secret>"
  }
}

Tenant-wide scan — omit both selectors to discover every accessible vault:

{
  "config": {
    "tenantId": "<azure-tenant-id>",
    "clientId": "<azure-client-id>",
    "clientSecret": "<azure-client-secret>"
  }
}

Legacy migration — replace subscriptionId + vaultUrl with selector fields:

Legacy fields subscriptionId and vaultUrl are no longer accepted. Delete the old configuration and recreate it using subscriptionNames and vaultNames. Use the subscription display name (not its UUID) in subscriptionNames; use the vault name (not its full URL) in vaultNames. Run az account list --output table to find the display name for a subscription ID.

{
  "config": {
    "subscriptionNames": "My Production Subscription",
    "vaultNames": "my-legacy-vault",
    "tenantId": "<azure-tenant-id>",
    "clientId": "<azure-client-id>",
    "clientSecret": "<azure-client-secret>"
  }
}

Required Azure Permissions

The service principal identified by clientId must satisfy two independent permission layers:

1. ARM management plane (required before test/scan can target any vault)

   • Grant Reader on each target subscription.
   • This is required even for Access Policy mode vaults, and even when subscriptionNames is omitted (tenant-wide scan).
   • Without this role, test can fail with no accessible subscriptions resolved for tenant.
   • Grant command: az role assignment create --assignee <clientId> --role Reader --scope /subscriptions/<subscriptionId>

2. Key Vault data plane (required to enumerate certificates, keys, and secrets within each vault). Secret Get is optional — secret List alone is sufficient for generic secret discovery; see the secret-value note below.

Each vault uses one of two mutually exclusive authorization models. Check which applies: az keyvault show --name <vault-name> --query "properties.enableRbacAuthorization"

Secret values and least privilege: The recommended Key Vault Reader role (RBAC) grants read access to certificate, key, and secret metadata, plus the public bodies of certificates and asymmetric keys, but cannot read secret values or private key material. Under Key Vault Reader, secrets are reported using metadata only; a secret whose value is a PEM-encoded private or symmetric key is reported as a generic secret rather than classified as a key (classification requires reading the value). To classify PEM keys stored inside secret values, additionally grant the higher-privilege Key Vault Secrets User role (RBAC) or secret get (Access Policy). The Key Vault Reader role only applies to vaults using the Azure RBAC permission model.

Both layers are required: subscription-level Reader does not grant vault object data access, and vault data-plane permissions do not make subscriptions visible to ARM discovery.