Use AKS Workload Identity to Login with "az login" in a Container with Azure CLI

 We have discussed "Setting Up Azure Workload Identity for Containers in Azure Kubernetes Services" previously. We can use Azure CLI  to interact with Azure resources in a container which is using base docker image "mcr.microsoft.com/azure-cli:latest-amd64". Instead of using specific credential information directly in the Azure CLI script in the container, we can use the workload identity to do an az login in a container where workload identity is enabled. Let's look at how to do that in this post.

Resolve "System.ArgumentNullException: Value cannot be null. (Parameter 'sharedKeyCredential')" in Generaiting SaS Uri for Azure Storage Blob while using DefaultAzureCredential

 To share an Azure blob for  downloading or editing requires sharing a link with a shared access signature (SaS) with required permissions. The BlobContainerClient.GenerateSasUri Method helps to generate a Uri to share. The  BlobContainerClient.GenerateSasUri Method works only if the BlobServiceClient is created using storage access signature as shown below.

string connectionString = "DefaultEndpointsProtocol=https;AccountName=cheuw001assetssthot;AccountKey=xxxxxxxxxxxxxxxxxxxxxxx==;EndpointSuffix=core.windows.net";
BlobServiceClient blobServiceClient = new(connectionString);

The usage of paswordless authentication using managed identities is the recommended approach to use Azure resources.  If the DefaultAzureCredential is used with managed identity (user assigned or system assigned) to create BlobServiceClient as shown below,  BlobContainerClient.GenerateSasUri Method  failes with error "System.ArgumentNullException: Value cannot be null. (Parameter 'sharedKeyCredential')".

BlobServiceClient blobServiceClient = new(
    new Uri("https://cheuw001assetssthot.blob.core.windows.net/"),
    new DefaultAzureCredential());

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,