Request: support for network proxies in the Ingest client

[davidglassborow]

Hi, trialing ADX in a corporate environment where a webproxy is required, needing network credentials, trying to ingest data via the SDK. All my calls end up failing with The proxy tunnel request to proxy 'http://mcafeewebproxy:9090/' failed with status code '407'.

I can find no documentation on how to configure the network connection for the Kusto clients, this made worse because source code is not available.

The equivalent feature in e.g. Azure blob client is configured like:

BlobClientOptions options = new()
{
        Transport = new HttpClientTransport(new HttpClientHandler() { Proxy = new WebProxy() { UseDefaultCredentials = true }})
};

I cannot find anything equivalent in IngestClientOptions class. How do I configure network options in Kusto please ?

[AsafMah]

Currently there is no official way to configure it, we will let you know if this gets implemented.

[davidglassborow]

No way to use it in the usual corporation environment ? Unbelievable.

[davidglassborow]

Currently there is no official way to configure it, we will let you know if this gets implemented.

So it there an un-official way?

[davidglassborow]

Support for proxy in the python sdk:

• https://github.com/Azure/azure-kusto-python/issues/378
• https://github.com/Azure/azure-kusto-python/issues/350

Support for proxy in the java sdk (for AT&T)

• https://github.com/Azure/azure-kusto-java/issues/369

[vplauzon]

If it's important for your use case, we suggest to enter an idea in https://aka.ms/adx.ideas.

Usually SDKs are used in automation servers / services (i.e. not on laptop), but it could make sense to debug in an environment where proxies are mandatory.

[davidglassborow]

Why do you mention a laptop ? Our requirement is to take telemetry from a secure SCADA system, decompress and re-shape the data, and then push into ADX, from a on-prem service. The usual security requirements are in place requiring all outgoing traffic (to azure or anywhere else) to go through a secure proxy.

Clearly other language SDKs have required this feature, and added it, and similar features exist in other Azure SDKs, as well as Google and AWS offerings.

The situation is made worse because no source is available, so my only option would be to decompile your SDK and make the fix myself, or build my own SDK.

Anyway easy option for me to advise my enterprise client that ADX is not ready for what they need if they want to use dotnet, and look at competitors, which I have done.

[AsafMah]

Hey, when using .NET 5+ with our sdk, you can use the HTTPS_PROXY env variable to define a proxy: learn.microsoft.com/en-us/dotnet/azure/sdk/azure-sdk-configure-proxy?tabs=cmd

[davidglassborow]

Thanks, I'll investigate. Doesn't look like you can pickup default network credentials using that method though.