Wiz solution v4.0.0: replace legacy Azure Function connector with DCR push integration#14491
Wiz solution v4.0.0: replace legacy Azure Function connector with DCR push integration#14491marekq wants to merge 3 commits into
Conversation
… push integration Migrate the Wiz Microsoft Sentinel solution from the legacy Azure Function (REST API pull, shared-key / HTTP Data Collector API) connector to the new Microsoft Sentinel push integration, where Wiz pushes to a Data Collection Rule/Endpoint using its service principal and the customer only grants RBAC. - Remove the v2 connector + its Function App/Key Vault ARM template (template_WIZ.json, azuredeploy_Connector_Wiz_API_AzureFunction.json). - Add the v3 push connector (WizSentinel.json, title "Wiz for Microsoft Sentinel") and the RBAC deployment template (azuredeploy_WizSentinelIntegration.json); the connector Deploy button points at the in-repo template via its raw master URL. - Data is now pushed to WizIssuesV3_CL, WizDetectionsV3_CL, WizAuditLogsV3_CL and WizVulnerabilitiesV3_CL (Issues, Detections, Audit Logs, Vulnerability Findings) -- a lossless superset of v2 plus Detections. - Rewrite the WizFindings workbook to the V3 tables/columns and update the central Workbooks/WorkbooksMetadata.json dependencies + connector id. - Regenerate the package (createSolutionV3) to 4.0.0; drop stale 2.0.0/3.0.0 zips. Passes the repo ARM-TTK gate (run-arm-ttk.ps1): Pass=48 Fail=0. DRAFT -- local only, not for push yet. Open items before submission: confirm the dynamic sub-fields (entitySnapshot.cloudPlatform/.type, vulnerableAsset.type) in-portal, and coordinate the offer update with the Partner Center owner. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@microsoft-github-policy-service agree company="Wiz" |
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Updates the Wiz solution to v4.0.0 by replacing the legacy Azure Function (pull) connector with a push-based DCR/DCE + RBAC integration, and aligning the workbook + metadata to the new V3 custom tables.
Changes:
- Replaced legacy Wiz connector assets (Function App ARM template + legacy connector JSON) with a new
WizSentinelpush/RBAC connector and RBAC deployment template. - Rewrote the WizFindings workbook queries to use
Wiz*V3_CLtables (including Detections) and updated workbook metadata dependencies/version. - Bumped solution packaging artifacts to 4.0.0 and updated release notes accordingly.
Reviewed changes
Copilot reviewed 10 out of 13 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| Workbooks/WorkbooksMetadata.json | Updates workbook dependencies and connector ID to WizSentinel and V3 tables. |
| Solutions/Wiz/Workbooks/WizFindings.json | Rewrites workbook queries to target V3 custom tables and adds Detections visualizations. |
| Solutions/Wiz/ReleaseNotes.md | Adds v4.0.0 entry describing connector migration and workbook rewrite. |
| Solutions/Wiz/Package/mainTemplate.json | Regenerated package content for v4.0.0 and updates connector/workbook packaged metadata. |
| Solutions/Wiz/Package/createUiDefinition.json | Updates solution description and workbook text to reflect push integration and V3 tables. |
| Solutions/Wiz/Data/Solution_Wiz.json | Points solution data to the new connector and bumps solution version to 4.0.0. |
| Solutions/Wiz/Data Connectors/template_WIZ.json | Removes legacy connector definition (Azure Functions-based). |
| Solutions/Wiz/Data Connectors/azuredeploy_WizSentinelIntegration.json | Adds ARM template to provision custom RBAC role + assignments for Wiz push ingestion. |
| Solutions/Wiz/Data Connectors/azuredeploy_Connector_Wiz_API_AzureFunction.json | Removes legacy Azure Function deployment template. |
| Solutions/Wiz/Data Connectors/WizSentinel.json | Adds new Wiz connector definition for push/RBAC onboarding flow and V3 data types. |
| "actions": [ | ||
| "Microsoft.Insights/DataCollectionRules/Read", | ||
| "Microsoft.Insights/DataCollectionRules/Write", | ||
| "Microsoft.Insights/DataCollectionRules/Delete", | ||
| "Microsoft.OperationalInsights/workspaces/tables/read", | ||
| "Microsoft.OperationalInsights/workspaces/tables/write", | ||
| "Microsoft.OperationalInsights/workspaces/read", | ||
| "Microsoft.OperationalInsights/workspaces/sharedKeys/action", | ||
| "Microsoft.Insights/DataCollectionEndpoints/Read", | ||
| "Microsoft.Insights/DataCollectionEndpoints/Write" | ||
| ], | ||
| "dataActions": [ | ||
| "Microsoft.Insights/Telemetry/Write" | ||
| ], |
There was a problem hiding this comment.
Confirmed this is not used at runtime — the integration pushes via the DCR / Logs Ingestion API using an AAD bearer token, so workspace shared keys are never read. I am deferring the removal in this PR: the data-connector validator's RestAPI permission template requires the connector to declare sharedKeys, and the action also lives in our authoritative roles.sh / Terraform / CLI sources. I would rather remove it as a deliberate cross-artifact change than introduce a connector-vs-role mismatch here. Open to guidance on the right permission pattern for a DCR-push / RBAC connector that fits neither the RestAPI nor AzureFunction template.
| "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", | ||
| "contentVersion": "1.0.0.0", | ||
| "metadata": { | ||
| "description": "Provisions the RBAC required by the Wiz Azure Sentinel integration (ARM port of wiz-azure-sentinel-integration.sh). Deploy this INTO the resource group that hosts the Log Analytics workspace. It creates a custom role definition (assignable at the subscription) and assigns it to the Wiz service principal at that resource group, plus optionally at an existing Data Collection Endpoint in any resource group. Resource-group scoped so it can be deployed via a Deploy to Azure button, the Azure portal Build your own template editor (paste/upload), or az deployment group create. ARM cannot create the Entra service principal, so its object ID is supplied via the wizPrincipalObjectId parameter." |
There was a problem hiding this comment.
Fixed in debbc60 — metadata.description now says "Microsoft Sentinel".
| "variables": { | ||
| "roleDefName": "[guid(subscription().id, parameters('customRoleName'))]", | ||
| "roleDefId": "[subscriptionResourceId('Microsoft.Authorization/roleDefinitions', variables('roleDefName'))]", | ||
| "roleDescription": "Wiz Custom Role For Azure Sentinel Integration", |
There was a problem hiding this comment.
Fixed in debbc60 — roleDescription is now "Wiz Custom Role For Microsoft Sentinel Integration".
| "BasePath": "C:\\GitHub\\Azure-Sentinel", | ||
| "Version": "4.0.0", |
There was a problem hiding this comment.
Kept intentionally. This matches the repo-standard build path used by existing solutions, and BasePath is not embedded in the published package — it is only used at packaging time. A repo-relative value like Solutions/Wiz actually breaks the V3 packaging tool here, because the content paths in this file are repo-root-relative (e.g. Solutions/Wiz/Data Connectors/WizSentinel.json).
| "query": "WizIssuesV3_CL \n| summarize count() by bin(TimeGenerated, 1h)", | ||
| "title": "Issues over time", |
There was a problem hiding this comment.
Good suggestion — tracking as a follow-up enhancement (add a TimeRange (type 4) parameter and apply {TimeRange} to each query). Kept out of this PR to scope it to the v2 to v3 migration.
| "name": "Vulnerabilities by asset type" | ||
| } | ||
| ], | ||
| "fromTemplateId": "sentinel-Alerts overview", |
There was a problem hiding this comment.
Fixed in debbc60 — now sentinel-WizFindings (space-free).
| "instructionSteps": [ | ||
| { | ||
| "title": "STEP 1 - Get the Wiz service principal object ID", | ||
| "description": "ARM cannot resolve a Microsoft Entra object, so you supply the Wiz service principal **object ID**. In Azure Cloud Shell (no install or login needed) run the line below — it prints the object ID, creating the service principal first if it does not yet exist in your tenant:\n\n```bash\naz ad sp show --id ae69b94b-e367-4660-9b35-cfb4b5966728 --query id -o tsv 2>/dev/null \\\n || az ad sp create --id ae69b94b-e367-4660-9b35-cfb4b5966728 --query id -o tsv\n```" |
There was a problem hiding this comment.
Fixed in debbc60 — reworded to "no local install required", and added that creating the service principal requires permission to register enterprise applications in Microsoft Entra ID.
…op Vulnerabilities
CI fixes for the v4.0.0 push-integration PR:
- Register KQL custom-table schemas (WizIssuesV3_CL, WizDetectionsV3_CL,
WizAuditLogsV3_CL) under .script/tests/KqlvalidationsTests/CustomTables/ so
KqlValidations recognizes the DCR-created tables.
- The data-connector validator classifies any _CL connector whose instructions
contain the literal "[Deploy To Azure]" as an Azure Function connector and
then requires the Function-App permission set. Relabel the deploy badge
("Deploy the Wiz RBAC role") so it classifies as RestAPI, and set
permissions.resourceProvider to the RestAPI template (workspace
read/write/delete + sharedKeys action) — which the Wiz custom role genuinely
grants (workspaces/read, tables/write, sharedKeys/action).
Drop Vulnerabilities from the solution: although the integration provisions a
WizVulnerabilitiesV3_CL stream, the push model is automation-rule driven and
there is no automation-rule trigger for vulnerability findings, so the table is
never populated. The solution now advertises only Issues, Detections, and Audit
Logs (WizIssuesV3_CL, WizDetectionsV3_CL, WizAuditLogsV3_CL) across the
connector, workbook, workbook metadata, and KQL custom tables. Package
regenerated.
Note: the remaining WorkbooksValidations failure is unrelated to Wiz — a
pre-existing missing-logo entry (akamai-guardicore.svg) in the shared
Workbooks/WorkbooksMetadata.json, surfaced because this PR edits that file.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Rebrand "Azure Sentinel" -> "Microsoft Sentinel" in the RBAC template's
metadata.description and roleDescription.
- Reword the connector Step 1: Cloud Shell needs no local install, but note that
creating the service principal requires permission to register enterprise
applications in Microsoft Entra ID (the previous "no install or login" was
misleading).
- Make the workbook fromTemplateId space-free ("sentinel-WizFindings").
- Regenerate the package.
Deferred from Copilot's review (intentional): removing
Microsoft.OperationalInsights/workspaces/sharedKeys/action (entangled with the
data-connector validator's RestAPI permission template and the authoritative
roles.sh / Terraform / CLI sources — needs a deliberate cross-artifact change).
BasePath kept as the repo-standard path. Workbook TimeRange parameter left as a
possible follow-up.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Thanks for the review. Addressed the actionable items in the latest commit:
Intentionally not changed, with rationale:
|
Proposed Changes
Updates the Wiz solution to v4.0.0, replacing the legacy Azure Function (REST API pull) data connector with the new Microsoft Sentinel push integration: Wiz pushes to a Data Collection Rule / Endpoint using its service principal, and the customer only grants RBAC — no customer-hosted Function App and no workspace shared keys.
template_WIZ.json,azuredeploy_Connector_Wiz_API_AzureFunction.json).WizSentinel.json(title "Wiz for Microsoft Sentinel") and the RBAC deployment templateazuredeploy_WizSentinelIntegration.json; the connector's Deploy to Azure button targets that template via its rawmasterURL.WizIssuesV3_CL,WizDetectionsV3_CL,WizAuditLogsV3_CL,WizVulnerabilitiesV3_CL(a superset of the prior solution — adds Detections).Workbooks/WorkbooksMetadata.jsondependencies + connector id.Validation
Tools/Create-Azure-Sentinel-Solution/V3/createSolutionV3.ps1..script/local-validation/run-arm-ttk.ps1: Pass=48, Fail=0 (thecontentProductId/identries are the documented filtered case).🤖 Generated with Claude Code