Microsoft Azure Integration Guide

Overview

This guide outlines how to prepare Microsoft Azure so the discovery extension can enumerate certificates and keys, how to create the read-only credentials it needs, and how to enter those credentials into the discovery configuration. Steps are given for both the Azure Portal and the Azure CLI.

The discovery reads cryptographic material from across your Azure estate:

• Azure Key Vault: keys (RSA, ECDSA, AES) and certificates with full X.509 metadata and CA hierarchy
• Azure Managed HSM: the extended Key Vault key inventory held in validated HSM hardware
• App Service Certificates: TLS bindings and custom domain SSL configurations
• Azure Application Gateway: SSL profiles, backend certificates, and listener certificates
• Azure Front Door: custom domain SSL bindings
• Azure API Management: API-level certificates and gateway certificates

Discovery is read-only. It reads object metadata such as type, algorithm, key length, and validity. It never creates, changes, exports, or deletes anything in Azure, and private key material is never extracted.

Two ways to work. Everything below can be done two ways. Pick whichever you prefer for each step:

Prerequisites

Before beginning, confirm the following:

1. An Azure subscription containing the Key Vaults, HSMs, or services you want to inventory.
2. Permission to create an app registration (a Service Principal) in your Microsoft Entra ID tenant, or an administrator who can create one for you.
3. Permission to assign read-only roles on the subscriptions, resource groups, or vaults you want scanned.
4. The discovery host must be able to reach the Azure management and Key Vault endpoints over the network.

No software installation is required on your side. You provide the credentials and the scope to scan.

Step-by-Step Guide

Step 1: Choose an Authentication Method

Discovery signs in to Azure using one of the following. Service Principal is recommended for automated use.

The rest of this guide sets up a Service Principal, since it is the most portable option.

Step 2: Create the Discovery Service Principal

Azure Portal

1. Go to Microsoft Entra ID, then App registrations, then New registration.
2. Name it, for example, cbom_discovery, and click Register.
3. On the app overview, copy the Application (client) ID and the Directory (tenant) ID.
4. Go to Certificates and secrets, then New client secret. Set a description and expiry, then click Add.
5. Copy the secret Value immediately. It is shown only once.

Azure CLI

# Creates the app registration, a service principal, and a client secret in one step
az ad sp create-for-rbac --name cbom_discovery --role Reader \
  --scopes /subscriptions/<subscription-id>

The command prints appId (Client ID), password (Client Secret), and tenant (Tenant ID). Copy all three now.

Step 3: Grant Read-Only Access

The Service Principal needs just enough access to list and read metadata, nothing more.

Subscription or resource group scope

Assign the built-in Reader role at the scope you want scanned (a whole subscription, or a single resource group).

Azure Portal

1. Open the subscription or resource group, then Access control (IAM).
2. Click Add, then Add role assignment.
3. Choose the Reader role, then select your cbom_discovery app, then Save.

Azure CLI

az role assignment create --assignee <client-id> \
  --role Reader \
  --scope /subscriptions/<subscription-id>

Key Vault data access

The Reader role sees vault metadata but not the objects inside a vault. Grant read-only data access as well, depending on the vault permission model.

For vaults using Azure RBAC, assign the built-in Key Vault Reader role to cbom_discovery:

az role assignment create --assignee <client-id> \
  --role "Key Vault Reader" \
  --scope /subscriptions/<subscription-id>
# Read-only "get" and "list" on certificates, keys, and secrets metadata

For vaults using access policies (the classic model), open the vault, then Access policies, then add a policy for cbom_discovery granting List and Get on Keys, Certificates, and Secrets only. Do not grant create, import, delete, or purge.

Note: Grant only List and Get. Discovery reads metadata; it never needs write, delete, or key export rights.

Step 4: Collect Your Connection Values

Before configuring discovery, gather these:

Step 5: Enter the Values in the Discovery Configuration

In the CBOM platform, create a new Microsoft Azure discovery task and fill in the form:

Save and run the task.

Step 6: Validate

After running the discovery task, confirm:

• The task completes without an authentication or authorization error.
• Certificates and keys from your Key Vaults appear in the inventory, with algorithm, key length, and validity.
• Service certificates from App Service, Application Gateway, Front Door, or API Management appear where those services are in scope.

You can double-check the credential access with the Azure CLI, using the same Service Principal discovery uses:

az login --service-principal -u <client-id> -p <client-secret> --tenant <tenant-id>
az keyvault list
az keyvault certificate list --vault-name <your-vault>

Troubleshooting

Final Checklist

• A Service Principal (app registration) created for discovery.
• Tenant ID, Client ID, and Client Secret copied.
• Reader role assigned at the subscription or resource group scope.
• Key Vault data access granted (Key Vault Reader, or a List and Get access policy).
• Services chosen: Key Vault, Managed HSM, App Service, Application Gateway, Front Door, API Management.
• Values entered in the Microsoft Azure discovery configuration and the task runs without errors.