Add Client Secret support into azure event hub integrations

[kaiyan-sheng]

Proposed commit message

Add OAuth2 client secret authentication support for Azure Event Hub integrations
This enhancement adds OAuth2 (client_secret) authentication support to all Azure integrations that use Event Hub, following the implementation in elastic/beats#47256.

Changes include:

• Added auth_type parameter to select between connection_string (default) and client_secret authentication
• Added OAuth2 parameters: eventhub_namespace, tenant_id, client_id, client_secret, authority_host
• Made connection_string and storage_account_key optional (conditionally required based on auth_type)
• Updated all affected template files to output OAuth2 parameters
• Version bumped 12 packages with changelog entries

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Author's Checklist

Affected 12 packages:

• azure
• azure_logs
• azure_openai
• azure_functions
• azure_frontdoor
• azure_app_service
• azure_ai_foundry
• microsoft_sentinel
• microsoft_defender_cloud
• m365_defender
• kubernetes
• github

How to test this PR locally

Related issues

• Closes [Azure] Add client secret (Oauth2) support #17030

Screenshots

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[ishleenk17]

@claude pls review the PR

[github-actions]

Claude finished @ishleenk17's task in 2m 35s —— View job

---

PR Review Complete

• Gather repository context
• Review existing PR comments and threads (32 total, 2 unresolved)
• Analyze key changed files
• Check for security, logic, and best practice issues
• Submit formal PR review

I've reviewed this PR and submitted my feedback. The implementation looks solid overall.

Summary:

• ✅ Client secret authentication support is correctly implemented across all 12 Azure Event Hub integrations
• ✅ Template logic properly emits OAuth2 parameters conditionally
• ✅ Documentation is comprehensive with clear setup instructions
• ✅ Changes are backward compatible (existing connection_string auth continues to work)
• ✅ Changelogs are consistently updated

Minor items noted:

• There's an unresolved thread from @zmoog about whether auth_type should be required: true
• The policy tests only cover connection_string path; consider adding client_secret test coverage

No blockers identified - the PR is in good shape for merge.

--- | View PR review

---

Why is Claude responding? | Type @claude to interact further

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[github-actions]

This PR adds client secret authentication support across 12 Azure Event Hub integrations. The implementation is well-structured and consistent across packages. A few observations:

Overall Quality

• The implementation follows the pattern from beats PR #47256 correctly
• Documentation is comprehensive with clear setup instructions for both authentication methods
• The template logic properly conditionally emits authority_host only when auth_type is client_secret
• Changelogs are consistently updated across all 12 packages

Minor Considerations

1. Unresolved Review Thread: There's an unresolved comment from @zmoog asking whether auth_type should be required: true (currently required: false with default connection_string). While the current approach maintains backward compatibility, making it required would be more explicit. Worth discussing.

2. Test Coverage: The policy tests for m365_defender only cover the connection_string path. Consider adding a test case for client_secret auth to verify the template correctly outputs the OAuth2 parameters and omits connection_string/storage_account_key.

3. Pre-existing Issue (out of scope for this PR): The packages/github/data_stream/audit/agent/stream/azure-eventhub.yml.hbs file uses filebeat-graphactivitylogs-{{eventhub}} as the default container name, which appears to be copy-pasted from the azure graphactivitylogs template. This is a pre-existing issue not introduced by this PR.

No Blockers - The PR is ready to merge from a technical standpoint. The implementation is solid and the changes are backward compatible.

---

Why is Claude responding? | Type @claude to interact further

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[kaiyan-sheng]

What about (1) using actual field names that match the UI and (2) use bold/italics to field highlight dependencies?

@zmoog Good point! I think this is definitely worth improving. I'm changing them to use the actual parameter names in the UI instead of names in Filebeat!

But for the README files I see we are using param names from Filebeat:

Do you think it's worth changing too?

[efd6]

/test

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 93c03f7

History

• 💔 Build #38644 failed 93c03f7
• 💚 Build #38622 succeeded c8014b8
• 💚 Build #38551 succeeded 3e895bf
• 💔 Build #38455 failed 03323d8
• 💔 Build #38454 failed 0d52a09

cc @kaiyan-sheng

[zmoog]

Do you think it's worth changing too?

Yeah, makes sense.

We should probably align this section with what we have at https://www.elastic.co/docs/reference/integrations/azure/events, adding the new options in the "Event Hub Processor v2 only" seciton.

[kaiyan-sheng]

adding the new options in the "Event Hub Processor v2 only" seciton.

@zmoog and I talked about this in slack, the decision is to keep the new options with authentication section so all the params around auth are together.

Also I see some benefits of keeping the config parameters in documentation instead of the UI names when we are trying to debug using config files instead of UI. So I think we can keep it as is for now (tbh maybe we should document both the UI name and the param name).

[elastic-vault-github-plugin-prod]

Package azure - 1.36.0 containing this change is available at https://epr.elastic.co/package/azure/1.36.0/

[elastic-vault-github-plugin-prod]

Package azure_ai_foundry - 0.9.0 containing this change is available at https://epr.elastic.co/package/azure_ai_foundry/0.9.0/

[elastic-vault-github-plugin-prod]

Package azure_app_service - 1.1.0 containing this change is available at https://epr.elastic.co/package/azure_app_service/1.1.0/

[elastic-vault-github-plugin-prod]

Package azure_frontdoor - 2.3.0 containing this change is available at https://epr.elastic.co/package/azure_frontdoor/2.3.0/

[elastic-vault-github-plugin-prod]

Package azure_functions - 0.12.0 containing this change is available at https://epr.elastic.co/package/azure_functions/0.12.0/

[elastic-vault-github-plugin-prod]

Package azure_logs - 0.6.0 containing this change is available at https://epr.elastic.co/package/azure_logs/0.6.0/

[elastic-vault-github-plugin-prod]

Package azure_openai - 1.11.0 containing this change is available at https://epr.elastic.co/package/azure_openai/1.11.0/

[elastic-vault-github-plugin-prod]

Package github - 2.22.0 containing this change is available at https://epr.elastic.co/package/github/2.22.0/

[elastic-vault-github-plugin-prod]

Package kubernetes - 1.85.0 containing this change is available at https://epr.elastic.co/package/kubernetes/1.85.0/

[elastic-vault-github-plugin-prod]

Package m365_defender - 5.9.0 containing this change is available at https://epr.elastic.co/package/m365_defender/5.9.0/

[elastic-vault-github-plugin-prod]

Package microsoft_defender_cloud - 3.3.0 containing this change is available at https://epr.elastic.co/package/microsoft_defender_cloud/3.3.0/

[elastic-vault-github-plugin-prod]

Package microsoft_sentinel - 1.3.0 containing this change is available at https://epr.elastic.co/package/microsoft_sentinel/1.3.0/