Using Blobclient with managed identity

[Oliver-CI]

Using Blobclient with managed identity

Currently it is not possible to use managed identity in combination with the use_sdk_type feature.
As in the Hydrator we always check for the AzureWebJobsStorage env to be present. Whilst using managed identity this property is not used as it only accepts formatting for a connectionString.

Example

I have the following function trigger

    @FunctionName("BlobFunction")
    fun handle(
        @BlobTrigger(
            name = "content",
            path = "container/{fileName}.json"
        ) blob: BlobClient,
        @BindingName("fileName") fileName: String,
        context: ExecutionContext
    ) {
       logger.info {  "received $fileName" }
    }

With the following environment variables defined:
AzureWebJobsStorage__accountName = mystorageaccount
JAVA_ENABLE_SDK_TYPES = true

Problem

Yet when starting this function the BlobClientHydrator will complain the AzureWebJobsStorage is not set.
https://github.com/Azure/azure-functions-java-additions/blob/dev/azure-functions-java-sdktypes/src/main/java/com/microsoft/azure/functions/sdktype/blob/BlobClientHydrator.java#L29

If you then also configure the AzureWebJobsStorage with a dummyvalue "foo=bar"
The default net sdk will then fail as the AzureWebJobsStorage is not correctly formatted.

https://github.com/Azure/azure-sdk-for-net/blob/593527287e9274f87cf00fa3192d499226423616/sdk/storage/Azure.Storage.Common/src/Shared/StorageConnectionString.cs#L238

Suggestion

I believe we could resolve this by not specifically checking the envVar but also checking if any of the 3 suffix variants are defined.

• System.getenv(envVar + "__accountName");
• System.getenv(envVar + "__serviceUri");
• System.getenv(envVar + "__blobServiceUri");

final note

If my assumptions mentioned above are incorrect please advise towards a working example.

[ahmedmuhsin]

Thanks @Oliver-CI, for pointing out this issue. We are actively working on a fix and that will go into our next release of the Java Worker.

A work around for this issue would be to use the BlobContainerClient as the type for the BlobTrigger. You can then use it to get the BlobClient for the triggering blob.

For example,

public class Function {
    @FunctionName("BlobTriggerTest")
    @StorageAccount("AzureWebJobsStorage")
    public void run(
            @BlobTrigger(name = "triggerBlob", path = "test-triggerinput-blobclient/{name}") BlobContainerClient triggerBlobContainerClient,
            @BindingName("name") String fileName,
            final ExecutionContext context
    ) {
        context.getLogger().info("BlobTriggerTest triggered for Blob: " + fileName);

        BlobClient triggerBlobClient = triggerBlobContainerClient.getBlobClient(fileName);

        context.getLogger().info("Trigger Blob name:" + triggerBlobClient.getBlobName());
    }
}

[Oliver-CI]

Thanks @ahmedmuhsin this does indeed work as a workaround.

Perhaps both BlobClientHydrator & BlobContainerHydrator should share the same logic to determine the credentials.

[ahmedmuhsin]

I'm glad that is working for you. Yes, that's exactly the change that I'm working on now.

[ahmedmuhsin]

The fix for this issue has been merged, #48.