Feature description
I want to be able to deploy a S360 connector via bicep with zero portal touches, but it appears that the S360Connector extends KustoApiHubConnector, which requires delegated user OAuth via Microsoft.Web/connections, blocking fully automated deployment.
In addition, we need to be able to set the Service Tree ID for the connector via bicep, or at least via a script that can be run as part of a bicep deploymentScript resource (using managed identity). Right now this is controlled in the data layer, which makes this more difficult.
Use case
Our team does 100% of our azure deployment via bicep. We don't want to have to configure anything in the azure portal or rely on individual user permissions like the current implementation does.
Current workaround
No work around other than manually creating the resource in the azure portal using oauth (not acceptable for our team).
Proposed approach
A new S360 connector mode where identity: 'system' uses the agent's MI to query Kusto directly via SdkKustoClient (runtime plumbing already exists in CheckKustoViaSdkAsync()). This would require the MI to have RBAC reader on the necessary S360 Kusto clusters, which is not ideal.
More details
I'm currently trying to deploy via bicep the following bicep but hit errors:
resource s360Connector 'Microsoft.App/agents/connectors@2026-01-01' = {
parent: sreAgent
name: 'bicep-s360'
properties: {
dataConnectorType: 'S360'
#disable-next-line use-secure-value-for-secure-inputs // Placeholder — ARM requires a valid HTTPS URI but runtime ignores it for S360 (GitHub #839)
dataSource: 'https://placeholder.azure-apihub.net'
identity: 'system'
}
}
Feature description
I want to be able to deploy a S360 connector via bicep with zero portal touches, but it appears that the S360Connector extends KustoApiHubConnector, which requires delegated user OAuth via Microsoft.Web/connections, blocking fully automated deployment.
In addition, we need to be able to set the Service Tree ID for the connector via bicep, or at least via a script that can be run as part of a bicep
deploymentScriptresource (using managed identity). Right now this is controlled in the data layer, which makes this more difficult.Use case
Our team does 100% of our azure deployment via bicep. We don't want to have to configure anything in the azure portal or rely on individual user permissions like the current implementation does.
Current workaround
No work around other than manually creating the resource in the azure portal using oauth (not acceptable for our team).
Proposed approach
A new S360 connector mode where identity: 'system' uses the agent's MI to query Kusto directly via SdkKustoClient (runtime plumbing already exists in CheckKustoViaSdkAsync()). This would require the MI to have RBAC reader on the necessary S360 Kusto clusters, which is not ideal.
More details
I'm currently trying to deploy via bicep the following bicep but hit errors: