Azure
The Azure integration connects one instance per subscription using a service principal. Resources are discovered into the estate; Azure Monitor and Service Health alerts arrive as signals with Azure’s severities mapped onto ISE’s canonical ladder; evidence is fetched on demand; and the write catalogue covers resource lifecycle and tagging — never RBAC or identity.
Capabilities
Section titled “Capabilities”Discovery. VMs, Azure Database servers (SQL and PostgreSQL flexible servers), AKS clusters, load balancers and application gateways, storage accounts, and App Services/Function Apps are enumerated into the estate, with Azure tags flowing into the unified tag pool. Cross-source identity joins VMs onto DataDog hosts and AKS clusters onto Kubernetes cluster entities.
Alerts. Azure Monitor alerts (Sev0–Sev4, mapped onto the canonical ladder) and Service Health events are forwarded as signals exactly as Azure raised them — ISE defers to the source’s detection layer. Recovery at the source recovers the signal.
Evidence. On demand during an investigation: describe_resource, list_resources,
monitor_metrics, activity_log, and — where a Log Analytics workspace is readable —
log_analytics_query (KQL).
Actions. The governed catalogue, each through the tiered approval pipeline:
| Action | Tier | Notes |
|---|---|---|
restart_vm |
T1 | The VM comes back on its own. |
start_vm |
T1 | Start a stopped VM. |
restart_app_service |
T1 | Covers Function Apps too (same resource type). |
set_resource_tag |
T1 | ARM tag merge at the source (fix-at-source tagging). |
deallocate_vm |
T2 | Releases compute (and its cost); requires approval. |
restart_pg_flexible_server |
T2 | Brief database outage; requires approval. |
Long-running ARM operations are polled to completion — an action reports success only when Azure says it finished, never merely when it was accepted. There are no RBAC/identity actions, and Azure SQL has no restart action (ARM offers no restart operation for it — ISE doesn’t fake one).
- Create an app registration (service principal) for reads and grant it the Reader role on the subscription; add Log Analytics Reader if you want KQL evidence. Note the tenant ID, client ID, and create a client secret.
- In ISE, add an Azure integration (Settings → Integrations) with tenant ID, client ID, client secret, and subscription ID. The secret is encrypted at rest and redacted from logs. One integration per subscription; native keys are subscription-scoped.
- The health check verifies the principal immediately; the System card shows the subscription, status, and last sync.
- To enable actions, create a second service principal with the write role assignments the catalogue needs and grant it via the integration’s Grant write flow. Reads and writes never share a credential.
Examples
Section titled “Examples”A Sev1 alert lands on a known VM. Azure Monitor raises a Sev1 alert on a VM. The signal maps onto the canonical ladder, attributes to the VM entity — joined with its DataDog host identity — and opens an incident carrying both sources’ context.
Governed remediation. Diagnosis points at a hung app service. restart_app_service
(T1) is proposed and executed after its tier’s approval; the ARM operation is polled to
completion and the true outcome recorded. A deallocate_vm would instead demand T2
approval before running.
Evidence pull. The Activity Log is queried on demand for recent operations on the resource — surfacing the configuration change behind the incident — and recorded as evidence.