integrations.microsoft_sentinel — version 1.1

Source: presets/integrations/microsoft-sentinel.satz

Purpose

Microsoft Sentinel's GCP connector — the federation half, once per customer.

Sentinel reads Google Cloud logs by PULLING them from a Pub/Sub subscription, authenticating through workload identity federation: no service-account key leaves the organisation. This file creates what the federation needs — the pool, the OIDC provider that trusts Microsoft, the service account Sentinel acts as, and the binding that lets the federated principal become it. What it does NOT create is anything to read: each log source is its own topic, subscription and sink, and microsoft-sentinel-auditlogs.satz is the first of them.

TRANSCRIBED FROM MICROSOFT, NOT IMPORTED. The shape is Azure/Azure-Sentinel, DataConnectors/GCP/Terraform/sentinel_resources_creation/. That configuration pins the Google provider at 3.73.0 and uses authoritative google_project_iam_binding, which REPLACES every other member of a role in the project — run as published beside an estate, it silently removes grants the estate made. Everything here is non-authoritative _iam_member.

THE TWO MICROSOFT IDENTIFIERS ARE VENDOR CONSTANTS, not this customer's: the audience is Sentinel's application id and the issuer is Microsoft's commercial tenant, both published in Microsoft's connector documentation and identical for every customer (docs/examples.md lists them). The customer's OWN tenant id is sentinel_workload_pool_id — the pool is named after it, without dashes, which is what Microsoft's script does.

TWO ORGANISATION POLICIES CAN REFUSE THIS, and neither is set by this library:

1. a deny-all on iam.workloadIdentityPoolProviders blocks the provider below — the estate must allow the sts.windows.net/<microsoft tenant> issuer;
2. where iam.managed.allowedPolicyMembers is enforced, the principal set has to be allowed before the binding is applied. The constraints AND together, and an incomplete subject list refuses the grant rather than warning. Both are landing-zone policies an estate inherits; a first apply that fails on either is that policy, not this pack.

RUNNING DEFENDER FOR CLOUD TOO? The two are separate integrations with separate pools, service accounts and topics, and nothing here is shared with microsoft-defender-for-cloud.satz. If both are pointed at ONE project, give them different pool ids: a pool id is unique per project, and the second apply fails on the first pool's name. Different projects need nothing.

ONBOARDING IS TWO-SIDED. This is the Google half; the Sentinel connector in Azure is configured with the pool, provider and service account this creates, and the connector does not work until both sides are done.

NO CLAIM. Sentinel is a SIEM that reads the estate. Exporting logs to it does not satisfy a retention control — monitoring/organization-audit-logsink.satz is what claims those — and Sentinel is itself in no catalog.

Use it

params {
  // the pack's own defaults — copy only the lines you change
  sentinel_project_id = logsink_project_id
  sentinel_project_number = ""
  sentinel_workload_pool_id = ""
  sentinel_sa_account = "sentinel-service-account"
  sentinel_application_id = "2041288c-b303-4ca0-9076-9612db3beeb2"
  microsoft_tenant_id = "33e01921-4d64-4f8c-a055-5bdaffd5e33d"
}

use "presets/integrations/microsoft-sentinel.satz"

Needs from outside the pack:

• logsink_project_id — declared by monitoring.organization_audit_logsink; use one of them alongside, or declare it in the estate.

Params

Questions

What to ask before this pack is configured, and what changing the answer costs.

sentinel_workload_pool_id — It is per customer and cannot be guessed. The pool is created with this id; changing it later is a new pool, a new provider and a connector that has to be onboarded again on the Azure side.

sentinel_project_number — Google assigns it at creation and the federated principal set is built from it, so it cannot be derived from the project id: gcloud projects describe <id> --format='value(projectNumber)'. A wrong number makes a binding that grants nothing, and the connector authenticates against a principal that does not exist.

sentinel_project_id — Whoever administers this project controls what Sentinel can read. The default is the audit-log archive's project, which is where the sinks and topics belong. Moving it later means a new pool, new topics and a re-onboarded connector.

Contributes

Claims

None — this pack proves no control by itself.

History

The whole library's history: the changelog in presets/CHANGELOG.md.

Notes

No notes yet.