Azure File Share with DefaultAzureCredential in .NET with Azure.Storage.Files.Shares - Is it possible?

 Using DefaultAzureCredential with most of the Azure resources is straight forward and simple with most of the Azure resources with relevant Azure .NET SDKs (We can use nuget packages Azure.Storage.Blobs and Azure.Identity). For example, with storage blob we can easily use DefaultAzureCredential as shown in below code.

    private static BlobServiceClient GetBlobServiceClient(string accountName)

    {

        return new(new Uri($"https://{accountName}.blob.core.windows.net"),

            new DefaultAzureCredential());

    }

However, we cannot simply create ShareClient with .NET SDK Azure.Storage.Files.Shares to use DefaultAzureCredential . as shown below.

ShareClient share = new(new Uri(fileShareUri),

    new DefaultAzureCredential());

With the above setup, we will get runtime errors when we try to perform operations with the Azure file share. As per the GitHub issue here it is not possible to use DefaultAzureCredential with Azure File Share with .NET SDK Azure.Storage.Files.Shares  due to "SMB Files cannot authenticate with a TokenCredential". So is it impossible to use DefaultAzureCredential  to perform operations with an Azure File Share using Azure.Storage.Files.Shares ? Let's look at a wokaround, which can help if desperately need to use DefaultAzureCredential with Azure.Storage.Files.Shares .

Setting Up Azure Workload Identity for Containers in Azure Kubernetes Services (AKS) Using Terraform - Improved Security for Containers in AKS

 Azure Workload Identity allows your containers in AKS touse amanaged identity to access Azure resources securely without having to depend on connection strings, passwords, access keys or secrets. In other works you can just use DefaultAzureCredential in your containers running in AKS, which will be using workload identity assigned to the container, to get access to the required Azure resource. The roale based access permissions will be in effect and the user assigned managed identity (we can use AD app registration as well bu user assigned managed identity is recommended) used to setup the workload identity in AKS should be given the necessary roles in the target Azure resource. This is far better than having to store secrets or connection stigs to utilized by the dotnet applications. In this post let's understand how to setup workload identity in AKS deployed containers and explore how it simplifies the dotnet application code allowing the application to access Azure resources securely with a managed identity.

Full example source code with terraform and a .NET application using default credentials to access app config service and keyvault is available here in my GitHub repo,

Setting Up Helm in WSL

 Kubernetes applications can be deployed easily with helm. Meny useful tools such as KEDA (Kubernetes Event Driven Autoscaler) deployments can be done with helm, using few simple steps. In this post let's look at how to setup helm in WSL so that we can use it to setup applications using helm charts.