Identity Bindings: A Cleaner Model for Multi‑Cluster Identity in AKS
AKS has supported assigning Azure Managed Identities to pods for some time, first through Pod Identity and then later through Workload Identity. Using these tools it is possible to give a pod an Azure Identity that it can use to interact with other Azure services - pull secrets from Key Vault, read a file from Blob Storage or write to a database. Workload Identity is the latest incarnation of this feature and significantly simplified this feature, removing the need to run additional management pods in the cluster and to have the identity injected in every node however it does have some issues of it's own. These issues are particularly evident when operating at scale and wanting to share the same Managed Identity across multiple workloads in the same cluster, or across multiple clusters. Workload Identity relies on creating a Federated Identity Credential (FIC) in Azure that defines the trust relationship between the AKS OIDC issuer and Entra ID. Each combination of Service Account and Namespace that uses the same Managed Identity requires a separate FIC, as do services running in different clusters. As your scale grows, this can start to become a problem. Each managed identity can only support up to 20 FICs. Once you hit that limit, your only option is to create another Managed Identity. This leads to the proliferation of Managed Identities that have the same permissions and do the same job, but only exist to work around this problem. In addition to the 20 FIC limit, there are some other issues with Workload Identity: Creation of the FIC is an Azure Resource creation that often needs to occur alongside Kubernetes resource creation and makes automation of app deployment harder There can be a cyclic dependency issue where the service account in Kubernetes needs to know the Identity details before the pod is created, but the FIC needs the service account and namespace details to create the OIDC binding Additional outbound rules are required to allow the AKS cluster to access the Entra ID (login.microsoftonline.com) endpoints Introducing Identity Bindings Identity Bindings are currently in preview. Previews are provided "as is" and "as available," and they're excluded from the service-level agreements and limited warranty. AKS previews are partially covered by customer support on a best-effort basis. As such, these features aren't meant for production use. Identity Bindings introduce a cleaner, RBAC-driven approach to identity management in AKS. Instead of juggling multiple federated credentials and namespace scoping, you define bindings that link Kubernetes RBAC roles to Azure identities. Pods then request tokens via an AKS-hosted proxy, no external egress required. Key benefits: Centralised Access Control: Authorisation flows through Kubernetes RBAC. Cross-Cluster Identity Reuse: Federated credentials can be shared across namespaces and clusters. Reduced Networking Requirements: No outbound calls for token acquisition; everything stays within the cluster. Simplified IaC: Eliminates the “chicken-and-egg” problem when deploying identities alongside workloads. Identity Bindings act as the link between applications running in AKS and the Azure managed identities they need to use. Instead of every cluster or namespace requiring its own federated identity configuration, each application is authorised through an Identity Binding defined inside the cluster. The binding expresses which workloads (via service accounts and RBAC) are allowed to request tokens for a given identity. When a pod needs a token, AKS validates the request against the binding, and if it matches, the request is routed through the cluster’s identity proxy to the single Federated Identity Credential (FIC) associated with the managed identity. The FIC then exchanges the pod’s OIDC token for an Azure access token. This pattern allows multiple clusters or namespaces to share one managed identity cleanly, while keeping all workload‑level authorisation decisions inside Kubernetes. With Workload Identity, every workload using a managed identity required its own Federated Identity Credential (FIC) tied to a specific namespace and service account, and you had to repeat that for every cluster. Hitting the 20‑FIC limit often forced teams to create duplicate managed identities, and deployments had to be carefully ordered to avoid cyclic dependencies. You also needed outbound access to Entra ID for token requests. Identity Bindings significantly simplifies this. You create a single binding per cluster–identity pair, authorise workloads through RBAC, and let AKS handle token exchange internally with no external egress. There is no FIC sprawl, no need for identity duplication and less complexity in your automation. Using Identity Bindings To get started with using Identity Bindings, you need an AKS cluster and a Managed Identity created. Your Managed Identity should be granted permissions to access the Azure resources you require. The first thing you need to do is ensure the feature is registered. az feature register --namespace Microsoft.ContainerService --name IdentityBindingPreview Next, we need to do is create the identity binding. This is a one-to-one mapping between AKS cluster and Managed Identity, so only needs to be created once for each clusters/identity mapping. You provide the name of the cluster you want the binding mapped to, the full resource ID of the Managed Identity resources, and the name you want to give this binding, and this maps the two resources together. This only needs to be created once per cluster and all further administration is done via Kubernetes. az aks identity-binding create -g "<resource group name>" --cluster-name "<cluster name>" -n "<binding name>" --managed-identity-resource-id "<managed identity Azure Resource ID>" Once this has been created, we need to configure access to it inside Kubernetes. To do this we create a ClusterRole which references the Managed Identity ID. Note that this must be a ClusterRole, it cannot just be a Role. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: identity-binding-user rules: - verbs: ["use-managed-identity"] apiGroups: ["cid.wi.aks.azure.com"] resources: ["<MI_CLIENT_ID>"] Once this ClusterRole is created, we can assign it to any Namespace and Service Account combination we require, using a ClusterRoleBinding. Indentity Bindings are accessible to all Pods that use that Service Account, in that Namespace. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: <clusterrole name> roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: identity-binding-user subjects: - kind: ServiceAccount name: <service account name> namespace: <namespace of service account> Now all that is left to do is configure the Pod to use the Identity Binding, there are a two steps to this. First we need to apply the required labels and annotations to the pod to enable Identity Binding support: metadata: labels: azure.workload.identity/use: "true" annotations: azure.workload.identity/use-identity-binding: "true" Then, we need to ensure that the Pod is running using the Service Account we granted permission to use the Identity Binding. spec: serviceAccountName: <service account name> Below is an example deployment that uses Identity Bindings. apiVersion: apps/v1 kind: Deployment metadata: name: keyvault-demo namespace: identity-binding-demo spec: replicas: 1 selector: matchLabels: app: keyvault-demo template: metadata: labels: app: keyvault-demo azure.workload.identity/use: "true" annotations: azure.workload.identity/use-identity-binding: "true" spec: serviceAccountName: keyvault-demo-sa containers: - name: keyvault-demo ... Once this Pod has been created, the Identity Binding should be attached and you should then be able to use it within your application using your SDK and language of choice. You can see an example of consuming an Identity Binding in GO here . Demo App If you want to deploy a demo workload to test out your bindings, you can use the Pod definition below. This requires you to deploy a Key Vault, and grant your managed identity the "Key Vault Secret User" role on that Key Vault. You will also need to update the service principle and namespace to match your environment. apiVersion: v1 kind: Pod metadata: name: demo namespace: demo labels: azure.workload.identity/use: "true" annotations: azure.workload.identity/use-identity-binding: "true" spec: serviceAccount: demo containers: - name: azure-sdk # source code: https://github.com/Azure/azure-workload-identity/blob/feature/custom-token-endpoint/examples/identitybinding-msal-go/main.go image: ghcr.io/bahe-msft/azure-workload-identity/identitybinding-msal-go:latest-linux-amd64 env: - name: KEYVAULT_URL value: ${KEYVAULT_URL} - name: SECRET_NAME value: ${KEYVAULT_SECRET_NAME} restartPolicy: Never Once deployed, if you look at the logs, you should see that it is able to read the secret from Key Vault. kubectl logs demo -n demo I1107 20:03:42.865180 1 main.go:77] "successfully got secret" secret="Hello!" Conclusion Identity Bindings offer a much cleaner model for managing workload identities in AKS, especially once you start operating at scale. By moving authorisation decisions into Kubernetes and relying on a single Federated Identity Credential per managed identity, they avoid the FIC sprawl, cyclic dependencies, and networking requirements that made Workload Identity harder to operate in larger environments. The end result is a simpler, more predictable way to let pods acquire Azure tokens. If you’re already using Workload Identity today, Identity Bindings are a natural evolution that reduces operational friction while keeping the security properties you expect. Further Reading Identity Bindings Overview Setup Identity BindingsTroubleshooting Azure Virtual Desktop Sign-In Failures After Tenant Migration
Migrating an Azure subscription between tenants can sometimes surface unexpected authentication issues, especially for environments like Azure Virtual Desktop (AVD) that depend deeply on Microsoft Entra ID (formerly Azure AD) for identity and access control. This post walks through a real-world scenario where users were suddenly locked out of AVD sessions after a tenant migration, the investigation that followed, and the steps taken to restore access. Scenario Overview Shortly after an Azure subscription was migrated from Tenant A to Tenant B, several users reported being unable to connect to their virtual desktops. The error message displayed: “Your account does not exist in this organization’s directory.” This problem appeared immediately after the migration—even though access roles had been correctly reassigned under the new tenant. Interestingly, users who had active sessions before the migration remained signed in until their tokens eventually expired. Symptoms Observed Authentication failures during AVD sign-in Error code AADSTS53003, indicating a Conditional Access policy block The issue primarily affected macOS clients Reinstalling or resetting the AVD client did not resolve the problem Root Cause Analysis The investigation uncovered that cached tokens on user devices were still attempting to authenticate against the legacy tenant. Contributing Factors Token persistence in macOS Keychain Cached refresh tokens still bound to the old tenant’s directory ID This mismatch meant that even though users had permission in the new tenant, their local authentication context still pointed to the previous one. Understanding Token Behavior on macOS The AVD client on macOS uses tokens stored in the system Keychain. Token Type Default Lifetime Renewal Behavior Access Token ~1 hour Automatically renewed via refresh token Refresh Token 90 days of inactivity (rolling) Each successful refresh resets the timer Persistent Session Until refresh token expiry or manual deletion Cached in Keychain until removed Key Takeaways: Conditional Access (CA) or Sign-In Frequency policies can shorten token validity (e.g., 12 hours or 7 days). Cached tokens remain active until: The refresh token expires. They are manually deleted from Keychain. A tenant mismatch triggers forced re-authentication. Resolution Steps Validate AVD Configuration Verify that the host pool, workspace, and application group references all point to the new tenant’s directory ID. Confirm that the appropriate service principals and role assignments exist under the new tenant. Clear Cached Tokens On macOS, manually remove AVD’s cached MSAL tokens from Keychain Access. Once users signed out and back in, authentication succeeded without further issues. Mitigation Options Option 1 – Revoke Active Sessions via Microsoft Graph PowerShell Connect-MgGraph -Scopes "User.RevokeSessions.All" Revoke-MgUserSignInSession Option 2 – Manual Cleanup Instruct affected users to delete cached credentials or MSAL tokens from macOS Keychain. Have them sign back in to re-establish authentication with the correct tenant. Key Learnings Cached tokens can retain old tenant information long after migration—especially on macOS devices. Conditional Access policies may inadvertently block token issuance during silent sign-ins. Proactively revoking sessions and clearing tokens helps minimize user disruption. Best Practices for Future Tenant Migrations Validate all AVD resources (host pools, workspaces, app groups) against the new directory ID. Instruct users to clear cached credentials before reconnecting. Allow sufficient propagation time for identity and access updates to take effect. Review Conditional Access policies to prevent unintended sign-in blocks during transition periods. Closing Thoughts Tenant migrations are complex, and even small gaps in token or directory synchronization can interrupt access to services like Azure Virtual Desktop. By planning token cleanup and access validation steps in advance, you can ensure a smoother transition with minimal user downtime.Azure Container Registry Repository Permissions with Attribute-based Access Control (ABAC)
General Availability announcement Today marks the general availability of Azure Container Registry (ACR) repository permissions with Microsoft Entra attribute-based access control (ABAC). ABAC augments the familiar Azure RBAC model with namespace and repository-level conditions so platform teams can express least-privilege access at the granularity of specific repositories or entire logical namespaces. This capability is designed for modern multi-tenant platform engineering patterns where a central registry serves many business domains. With ABAC, CI/CD systems and runtime consumers like Azure Kubernetes Service (AKS) clusters have least-privilege access to ACR registries. Why this matters Enterprises are converging on a central container registry pattern that hosts artifacts and container images for multiple business units and application domains. In this model: CI/CD pipelines from different parts of the business push container images and artifacts only to approved namespaces and repositories within a central registry. AKS clusters, Azure Container Apps (ACA), Azure Container Instances (ACI), and consumers pull only from authorized repositories within a central registry. With ABAC, these repository and namespace permission boundaries become explicit and enforceable using standard Microsoft Entra identities and role assignments. This aligns with cloud-native zero trust, supply chain hardening, and least-privilege permissions. What ABAC in ACR means ACR registries now support a registry permissions mode called “RBAC Registry + ABAC Repository Permissions.” Configuring a registry to this mode makes it ABAC-enabled. When a registry is configured to be ABAC-enabled, registry administrators can optionally add ABAC conditions during standard Azure RBAC role assignments. This optional ABAC conditions scope the role assignment’s effect to specific repositories or namespace prefixes. ABAC can be enabled on all new and existing ACR registries across all SKUs, either during registry creation or configured on existing registries. ABAC-enabled built-in roles Once a registry is ABAC-enabled (configured to “RBAC Registry + ABAC Repository Permissions), registry admins can use these ABAC-enabled built-in roles to grant repository-scoped permissions: Container Registry Repository Reader: grants image pull and metadata read permissions, including tag resolution and referrer discoverability. Container Registry Repository Writer: grants Repository Reader permissions, as well as image and tag push permissions. Container Registry Repository Contributor: grants Repository Reader and Writer permissions, as well as image and tag delete permissions. Note that these roles do not grant repository list permissions. The separate Container Registry Repository Catalog Lister must be assigned to grant repository list permissions. The Container Registry Repository Catalog Lister role does not support ABAC conditions; assigning it grants permissions to list all repositories in a registry. Important role behavior changes in ABAC mode When a registry is ABAC-enabled by configuring its permissions mode to “RBAC Registry + ABAC Repository Permissions”: Legacy data-plane roles such as AcrPull, AcrPush, AcrDelete are not honored in ABAC-enabled registries. For ABAC-enabled registries, use the ABAC-enabled built-in roles listed above. Broad roles like Owner, Contributor, and Reader previously granted full control plane and data plane permissions, which is typically an overprivileged role assignment. In ABAC-enabled registries, these broad roles will only grant control plane permissions to the registry. They will no longer grant data plane permissions, such as image push, pull, delete or repository list permissions. ACR Tasks, Quick Tasks, Quick Builds, and Quick Runs no longer inherit default data-plane access to source registries; assign the ABAC-enabled roles above to the calling identity as needed. Identities you can assign ACR ABAC uses standard Microsoft Entra role assignments. Assign RBAC roles with optional ABAC conditions to users, groups, service principals, and managed identities, including AKS kubelet and workload identities, ACA and ACI identities, and more. Next steps Start using ABAC repository permissions in ACR to enforce least-privilege artifact push, pull, and delete boundaries across your CI/CD systems and container image workloads. This model is now the recommended approach for multi-tenant platform engineering patterns and central registry deployments. To get started, follow the step-by-step guides in the official ACR ABAC documentation: https://aka.ms/acr/auth/abacDevelop Custom Engine Agent to Microsoft 365 Copilot Chat with pro-code
There are some great articles that explain how to integrate an MCP server built on Azure with a declarative agent created using Microsoft Copilot Studio. These approaches aim to extend the agent’s capabilities by supplying it with tools, rather than defining a fixed role. Here were some of the challenges w encountered: The agent's behavior can only be tested through the Copilot Studio web interface, which isn't ideal for iterative development. You don’t have control over which LLM is used as the orchestrator—for example, there's no way to specify GPT-4o. The agent's responses don’t always behave the same as they would if you were prompting the LLM directly. These limitations got me thinking: why not build the entire agent myself? At the same time, I still wanted to take advantage of the familiar Microsoft 365 Copilot interface on the frontend. As I explored further, I discovered that the Microsoft 365 Copilot SDK makes it possible to bring in your own custom-built agent.Superfast using Web App and Managed Identity to invoke Function App triggers
TOC Introduction Setup References 1. Introduction Many enterprises prefer not to use App Keys to invoke Function App triggers, as they are concerned that these fixed strings might be exposed. This method allows you to invoke Function App triggers using Managed Identity for enhanced security. I will provide examples in both Bash and Node.js. 2. Setup 1. Create a Linux Python 3.11 Function App 1.1. Configure Authentication to block unauthenticated callers while allowing the Web App’s Managed Identity to authenticate. Identity Provider Microsoft Choose a tenant for your application and it's users Workforce Configuration App registration type Create Name [automatically generated] Client Secret expiration [fit-in your business purpose] Supported Account Type Any Microsoft Entra Directory - Multi-Tenant Client application requirement Allow requests from any application Identity requirement Allow requests from any identity Tenant requirement Use default restrictions based on issuer Token store [checked] 1.2. Create an anonymous trigger. Since your app is already protected by App Registration, additional Function App-level protection is unnecessary; otherwise, you will need a Function Key to trigger it. 1.3. Once the Function App is configured, try accessing the endpoint directly—you should receive a 401 Unauthorized error, confirming that triggers cannot be accessed without proper Managed Identity authorization. 1.4. After making these changes, wait 10 minutes for the settings to take effect. 2. Create a Linux Node.js 20 Web App and Obtain an Access Token and Invoke the Function App Trigger Using Web App (Bash Example) 2.1. Enable System Assigned Managed Identity in the Web App settings. 2.2. Open Kudu SSH Console for the Web App. 2.3. Run the following commands, making the necessary modifications: subscriptionsID → Replace with your Subscription ID. resourceGroupsID → Replace with your Resource Group ID. application_id_uri → Replace with the Application ID URI from your Function App’s App Registration. https://az-9640-faapp.azurewebsites.net/api/test_trigger → Replace with the corresponding Function App trigger URL. # Please setup the target resource to yours subscriptionsID="01d39075-XXXX-XXXX-XXXX-XXXXXXXXXXXX" resourceGroupsID="XXXX" # Variable Setting (No need to change) identityEndpoint="$IDENTITY_ENDPOINT" identityHeader="$IDENTITY_HEADER" application_id_uri="api://9c0012ad-XXXX-XXXX-XXXX-XXXXXXXXXXXX" # Install necessary tool apt install -y jq # Get Access Token tokenUri="${identityEndpoint}?resource=${application_id_uri}&api-version=2019-08-01" accessToken=$(curl -s -H "Metadata: true" -H "X-IDENTITY-HEADER: $identityHeader" "$tokenUri" | jq -r '.access_token') echo "Access Token: $accessToken" # Run Trigger response=$(curl -s -o response.json -w "%{http_code}" -X GET "https://az-9640-myfa.azurewebsites.net/api/my_test_trigger" -H "Authorization: Bearer $accessToken") echo "HTTP Status Code: $response" echo "Response Body:" cat response.json 2.4. If everything is set up correctly, you should see a successful invocation result. 3. Invoke the Function App Trigger Using Web App (nodejs Example) I have also provide my example, which you can modify accordingly and save it to /home/site/wwwroot/callFunctionApp.js and run it cd /home/site/wwwroot/ vi callFunctionApp.js npm init -y npm install azure/identity axios node callFunctionApp.js // callFunctionApp.js const { DefaultAzureCredential } = require("@azure/identity"); const axios = require("axios"); async function callFunctionApp() { try { const applicationIdUri = "api://9c0012ad-XXXX-XXXX-XXXX-XXXXXXXXXXXX"; // Change here const credential = new DefaultAzureCredential(); console.log("Requesting token..."); const tokenResponse = await credential.getToken(applicationIdUri); if (!tokenResponse || !tokenResponse.token) { throw new Error("Failed to acquire access token"); } const accessToken = tokenResponse.token; console.log("Token acquired:", accessToken); const apiUrl = "https://az-9640-myfa.azurewebsites.net/api/my_test_trigger"; // Change here console.log("Calling the API now..."); const response = await axios.get(apiUrl, { headers: { Authorization: `Bearer ${accessToken}`, }, }); console.log("HTTP Status Code:", response.status); console.log("Response Body:", response.data); } catch (error) { console.error("Failed to call the function", error.response ? error.response.data : error.message); } } callFunctionApp(); Below is my execution result: 3. References Tutorial: Managed Identity to Invoke Azure Functions | Microsoft Learn How to Invoke Azure Function App with Managed Identity | by Krizzia 🤖 | Medium Configure Microsoft Entra authentication - Azure App Service | Microsoft Learn
Use managed identity instead of AzureWebJobsStorage to connect a function app to a storage account
In a function app, usually we use appsetting AzureWebJobsStorage to connect to storage. This blog shows you how to configure a function app using Azure Active Directory identities instead of secrets or connection strings, where possible. Using identities helps you avoid accidentally leaking sensitive secrets and can provide better visibility into how data is accessed. This will not work if the storage account is in a sovereign cloud or has a custom DNS. IMPORTANT! When running in a Consumption or Elastic Premium plan, your app uses the WEBSITE_AZUREFILESCONNECTIONSTRING and WEBSITE_CONTENTSHARE settings when connecting to Azure Files on the storage account used by your function app. Azure Files doesn't support using managed identity when accessing the file share. That is to say, if your functio app is running on Consumption/EP, plan, you can only delete and recreate function app on app service plan to avoid using File Share. For more information, see Azure Files supported authentication scenarios Below are the steps to do configuration. 1. Enable system assigned identity in your function app and save it. 2. Give storage access to your function app. Search for Storage Blob Data Owner, select it. 3. If you configure a blob-triggered function app, repeat the step 2 to add Storage Account Contributor and Storage Queue Data Contributor roles which will be used for blob trigger. 4. Return to Access Control (IAM), click Role assignments, search for your function app name to confirm the roles are added successfully. 5. Navigate to your function app. Select Configuration and edit AzureWebJobsStorage. Change the name to AzureWebJobsStorage__accountname. Change the value to your storage account name. (The new setting uses a double underscore ( __ ), which is a special character in application settings.) 6. Delete the previous AzureWebJobsStorage. Then you will find your function app still works fine.Azure Kubernetes Service Baseline - The Hard Way, Third time's a charm
1 Access management Azure Kubernetes Service (AKS) supports Microsoft Entra ID integration, which allows you to control access to your cluster resources using Azure role-based access control (RBAC). In this tutorial, you will learn how to integrate AKS with Microsoft Entra ID and assign different roles and permissions to three types of users: An admin user, who will have full access to the AKS cluster and its resources. A backend ops team, who will be responsible for managing the backend application deployed in the AKS cluster. They will only have access to the backend namespace and the resources within it. A frontend ops team, who will be responsible for managing the frontend application deployed in the AKS cluster. They will only have access to the frontend namespace and the resources within it. By following this tutorial, you will be able to implement the least privilege access model, which means that each user or group will only have the minimum permissions required to perform their tasks. 1.1 Introduction In this third part of the blog series, you will learn how to: Harden your AKS cluster. - Update an existing AKS cluster to support Microsoft Entra ID integration enabled. Create a Microsoft Entra ID admin group and assign it the Azure Kubernetes Service Cluster Admin Role. Create a Microsoft Entra ID backend ops group and assign it the Azure Kubernetes Service Cluster User Role. Create a Microsoft Entra ID frontend ops group and assign it the Azure Kubernetes Service Cluster User Role. Create Users in Microsoft Entra ID Create role bindings to grant access to the backend ops group and the frontend ops group to their respective namespaces. Test the access of each user type by logging in with different credentials and running kubectl commands. 1.2 Prequisities: This section outlines the recommended prerequisites for setting up Microsoft entra ID with AKS. Highly recommended to complete Azure Kubernetes Service Baseline - The Hard Way here! or follow the Microsoft official documentation for a quick start here! Note that you will need to create 2 namespaces in kubernetes one called frontend and the second one called backend. 1.3 Target Architecture Throughout this article, this is the target architecture we will aim to create: all procedures will be conducted by using Azure CLI. The current architecture can be visualized as followed: 1.4 Deployment 1.4.1 Prepare Environment Variables This code defines the environment variables for the resources that you will create later in the tutorial. Note: Ensure environment variable $STUDENT_NAME and placeholder <TENANT SUB DOMAIN NAME>is set before adding the code below. # Define the name of the admin group ADMIN_GROUP='ClusterAdminGroup-'${STUDENT_NAME} # Define the name of the frontend operations group OPS_FE_GROUP='Ops_Fronted_team-'${STUDENT_NAME} # Define the name of the backend operations group OPS_BE_GROUP='Ops_Backend_team-'${STUDENT_NAME} # Define the Azure AD UPN (User Principal Name) for the frontend operations user AAD_OPS_FE_UPN='opsfe-'${STUDENT_NAME}'@<SUB DOMAIN TENANT NAME HERE>.onmicrosoft.com' # Define the display name for the frontend operations user AAD_OPS_FE_DISPLAY_NAME='Frontend-'${STUDENT_NAME} # Placeholder for the frontend operations user password AAD_OPS_FE_PW=<ENTER USER PASSWORD> # Define the Azure AD UPN for the backend operations user AAD_OPS_BE_UPN='opsbe-'${STUDENT_NAME}'@<SUB DOMAIN TENANT NAME HERE>.onmicrosoft.com' # Define the display name for the backend operations user AAD_OPS_BE_DISPLAY_NAME='Backend-'${STUDENT_NAME} # Placeholder for the backend operations user password AAD_OPS_BE_PW=<ENTER USER PASSWORD> # Define the Azure AD UPN for the cluster admin user AAD_ADMIN_UPN='clusteradmin'${STUDENT_NAME}'@<SUB DOMAIN TENANT NAME HERE>.onmicrosoft.com' # Placeholder for the cluster admin user password AAD_ADMIN_PW=<ENTER USER PASSWORD> # Define the display name for the cluster admin user AAD_ADMIN_DISPLAY_NAME='Admin-'${STUDENT_NAME} 1.4.2 Create Microsoft Entra ID Security Groups We will now start by creating 3 security groups for respective team. Create the security group for Cluster Admins az ad group create --display-name $ADMIN_GROUP --mail-nickname $ADMIN_GROUP 2. Create the security group for Application Operations Frontend Team az ad group create --display-name $OPS_FE_GROUP --mail-nickname $OPS_FE_GROUP 3. Create the security group for Application Operations Backend Team az ad group create --display-name $OPS_BE_GROUP --mail-nickname $OPS_BE_GROUP Current architecture can now be illustrated as follows: 1.4.3 Integrate AKS with Microsoft Entra ID 1. Lets update our existing AKS cluster to support Microsoft Entra ID integration, and configure a cluster admin group, and disable local admin accounts in AKS, as this will prevent anyone from using the --admin switch to get full cluster credentials. az aks update -g $SPOKE_RG -n $AKS_CLUSTER_NAME-${STUDENT_NAME} --enable-azure-rbac --enable-aad --disable-local-accounts Current architecture can now be described as follows: 1.4.4 Scope and Role Assignment for Security Groups This chapter describes how to create the scope for the operation teams to perform their daily tasks. The scope is based on the AKS resource ID and a fixed path in AKS, which is /namespaces/. The scope will assign the Application Operations Frontend Team to the frontend namespace and the Application Operation Backend Team to the backend namespace. Lets start by constructing the scope for the operations team. AKS_BACKEND_NAMESPACE='/namespaces/backend' AKS_FRONTEND_NAMESPACE='/namespaces/frontend' AKS_RESOURCE_ID=$(az aks show -g $SPOKE_RG -n $AKS_CLUSTER_NAME-${STUDENT_NAME} --query 'id' --output tsv) 2. Lets fetch the Object ID of the operations teams and admin security groups. Application Operation Frontend Team. FE_GROUP_OBJECT_ID=$(az ad group show --group $OPS_FE_GROUP --query 'id' --output tsv) Application Operation Backend Team. BE_GROUP_OBJECT_ID=$(az ad group show --group $OPS_BE_GROUP --query 'id' --output tsv Admin. ADMIN_GROUP_OBJECT_ID=$(az ad group show --group $ADMIN_GROUP --query 'id' --output tsv) 3) This commands will grant the Application Operations Frontend Team group users the permissions to download the credential for AKS, and only operate within given namespace. az role assignment create --assignee $FE_GROUP_OBJECT_ID --role "Azure Kubernetes Service RBAC Writer" --scope ${AKS_RESOURCE_ID}${AKS_FRONTEND_NAMESPACE} az role assignment create --assignee $FE_GROUP_OBJECT_ID --role "Azure Kubernetes Service Cluster User Role" --scope ${AKS_RESOURCE_ID} 4) This commands will grant the Application Operations Backend Team group users the permissions to download the credential for AKS, and only operate within given namespace. az role assignment create --assignee $BE_GROUP_OBJECT_ID --role "Azure Kubernetes Service RBAC Writer" --scope ${AKS_RESOURCE_ID}${AKS_BACKEND_NAMESPACE} az role assignment create --assignee $BE_GROUP_OBJECT_ID --role "Azure Kubernetes Service Cluster User Role" --scope ${AKS_RESOURCE_ID} 5) This command will grant the Admin group users the permissions to connect to and manage all aspects of the AKS cluster. az role assignment create --assignee $ADMIN_GROUP_OBJECT_ID --role "Azure Kubernetes Service RBAC Cluster Admin" --scope ${AKS_RESOURCE_ID} Current architecture can now be described as follows: 1.4.5 Create Users and Assign them to Security Groups. This exercise will guide you through the steps of creating three users and adding them to their corresponding security groups. Create the Admin user. az ad user create --display-name $AAD_ADMIN_DISPLAY_NAME --user-principal-name $AAD_ADMIN_UPN --password $AAD_ADMIN_PW 2. Assign the admin user to admin group for the AKS cluster. First identify the object id of the user as we will need this number to assign the user to the admin group. ADMIN_USER_OBJECT_ID=$(az ad user show --id $AAD_ADMIN_UPN --query 'id' --output tsv) 3. Assign the user to the admin security group. az ad group member add --group $ADMIN_GROUP --member-id $ADMIN_USER_OBJECT_ID 4. Create the frontend operations user. az ad user create --display-name $AAD_OPS_FE_DISPLAY_NAME --user-principal-name $AAD_OPS_FE_UPN --password $AAD_OPS_FE_PW 5. Assign the frontend operations user to frontend security group for the AKS cluster. First identify the object id of the user as we will need this number to assign the user to the frontend security group. FE_USER_OBJECT_ID=$(az ad user show --id $AAD_OPS_FE_UPN --query 'id' --output tsv) 6. Assign the user to the frontend security group. az ad group member add --group $OPS_FE_GROUP --member-id $FE_USER_OBJECT_ID 7. Create the backend operations user. az ad user create --display-name $AAD_OPS_BE_DISPLAY_NAME --user-principal-name $AAD_OPS_BE_UPN --password $AAD_OPS_BE_PW 8. Assign the backend operations user to backend security group for the AKS cluster. First identify the object id of the user as we will need this number to assign the user to the backend security group. BE_USER_OBJECT_ID=$(az ad user show --id $AAD_OPS_BE_UPN --query 'id' --output tsv) 9. Assign the user to the backend security group. az ad group member add --group $OPS_BE_GROUP --member-id $BE_USER_OBJECT_ID Current architecture can now be described as follows: 1.4.6 Validate your deployment in the Azure portal. Navigate to the Azure portal at https://portal.azure.com and enter your login credentials. Once logged in, on your top left hand side, click on the portal menu (three strips). From the menu list click on Microsoft Entra ID. On your left hand side menu under Manage click on Users. Validate that your users are created, there shall be three users, each user name shall end with your student name. On the top menu bar click on the Users link. On your left hand side menu under Manage click on Groups. Ensure you have three groups as depicted in the picture, the group names should end with your student name. Click on security group called Ops_Backend_team-YOUR STUDENT NAME. On your left hand side menu click on Members, verify that your user Backend-YOUR STUDENT NAME is assigned. On your left hand side menu click on Azure role Assignments, from the drop down menu select your subscription. Ensure the following roles are assigned to the group: Azure Kubernetes service Cluster User Role assigned on the Cluster level and Azure Kubernetes Service RBAC Writer assigned on the namespace level called backend. 11.On the top menu bar click on Groups link. Repeat step 7 - 11 for Ops_Frontend_team-YOUR STUDENT NAME and ClusterAdminGroup-YOUR STUDENT NAME 1.4.7 Validate the Access for the Different Users. This section will demonstrate how to connect to the AKS cluster from the jumpbox using the user account defined in Microsoft Entra ID. Note: If you deployed your AKS cluster using the quick start method We will check two things: first, that we can successfully connect to the cluster; and second, that the Operations teams have access only to their own namespaces, while the Admin has full access to the cluster. Navigate to the Azure portal at https://portal.azure.com and enter your login credentials. Once logged in, locate and select your rg-hub where the Jumpbox has been deployed. Within your resource group, find and click on the Jumpbox VM. In the left-hand side menu, under the Operations section, select Bastion. Enter the credentials for the Jumpbox VM and verify that you can log in successfully. First remove the existing stored configuration that you have previously downloaded with Azure CLI and kubectl. From the Jumpbox VM execute the following commands: rm -R .azure/ rm -R .kube/ Note: The .azure and .kube directories store configuration files for Azure and Kubernetes, respectively, for your user account. Removing these files triggers a login prompt, allowing you to re-authenticate with different credentials. 7. Retrieve the username and password for Frontend user. Important: Retrieve the username and password from your local shell, and not the shell from Jumpbox VM. echo $AAD_OPS_FE_UPN echo $AAD_OPS_FE_PW 8. From the Jumpbox VM initiate the authentication process. az login Example output: bash azureuser@Jumpbox-VM:~$ az login To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XXXXXXX to authenticate. 9. Open a new tab in your web browser and access https://microsoft.com/devicelogin. Enter the generated code, and press Next 10. You will be prompted with an authentication window asking which user you want to login with select Use another account and supply the username in the AAD_OPS_FE_UPN variable and password from variable AAD_OPS_FE_PW and then press Next. Note: When you authenticate with a user for the first time, you will be prompted by Microsoft Authenticator to set up Multi-Factor Authentication (MFA). Choose "I want to setup a different method" option from the drop-down menu, and select Phone, supply your phone number, and receive a one-time passcode to authenticate to Azure with your user account. 11. From the Jumpbox VM download AKS cluster credential. SPOKE_RG=rg-spoke STUDENT_NAME= AKS_CLUSTER_NAME=private-aks az aks get-credentials --resource-group $SPOKE_RG --name $AKS_CLUSTER_NAME-${STUDENT_NAME} You should see a similar output as illustrated below: bash azureuser@Jumpbox-VM:~$ az aks get-credentials --resource-group $SPOKE_RG --name $AKS_CLUSTER_NAME-${STUDENT_NAME} Merged "private-aks" as current context in /home/azureuser/.kube/config azureuser@Jumpbox-VM:~$ 12. You should be able to list all pods in namespace frontend. You will now be prompted to authenticate your user again, as this time it will validate your newly created user permissions within the AKS cluster. Ensure you login with the user you created i.e $AAD_OPS_FE_UPN, and not your company email address. kubectl get po -n frontend Example output: azureuser@Jumpbox-VM:~$ kubectl get po -n frontend To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XXXXXXX to authenticate. NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 89m 13. Try to list pods in default namespace bash kubectl get pods Example output: bash azureuser@Jumpbox-VM:~$ kubectl get po Error from server (Forbidden): pods is forbidden: User "opsfe-test@xxxxxxxxxx.onmicrosoft.com" cannot list resource "pods" in API group "" in the namespace "default": User does not have access t o the resource in Azure. Update role assignment to allow access. 14. Repeat step 6 and 13 for the remaining users, and see how their permissions differs. # Username and password for Admin user execute the command from your local shell and not from Jumpbox VM echo $AAD_ADMIN_UPN echo $AAD_ADMIN_PW # Username and password for Backend user execute the command from your local shell and not from Jumpbox VM echo $AAD_OPS_BE_UPN echo $AAD_OPS_BE_PW 🎉 Congratulations, you made it to the end! You’ve just navigated the wild waters of Microsoft Entra ID and AKS — and lived to tell the tale. Whether you’re now a cluster conqueror or an identity integration ninja, give yourself a high five (or a kubectl get pods if that’s more your style). Now go forth and secure those clusters like the cloud hero you are. 🚀 And remember: with great identity comes great responsibility.
Streamline & Modernise ASP.NET Auth: Moving enterprise apps from IIS to App Service with Easy Auth
Introduction When modernising your enterprise ASP.NET (.NET Framework) or ASP.NET Core applications and moving them from IIS over to Azure App Service, one of the aspects you will have to take into consideration is how you will manage authentication (AuthN) and authorisation (AuthZ). Specifically, for applications that leverage on-premises auth mechanisms such as Integrated Windows Authentication, you will need to start considering more modern auth protocols such as OpenID Connect/OAuth which are more suited to the cloud. Fortunately, App Service includes built-in authentication and authorisation support also known as 'Easy Auth', which requires minimal to zero code changes. This feature is integrated into the platform, includes a built-in token store, and operates as a middleware running the AuthN logic outside of your code logic, as illustrated by the image below:- More information on how EasyAuth works can be found here. Easy Auth supports several providers as illustrated above, but in this blog we will purely focus on using Entra ID (formerly known as Azure Active Directory) as the provider. It also assumes all of the Active Directory users have been synced up to Entra ID. With a few clicks, you can enable Entra ID authentication across any of your web, mobile or API apps in App Service, restrict which tenants or even specific identities are allowed access – all without touching code. This can be quite powerful in many scenarios, such as when you do not have access to the source control to implement your own auth logic, reducing the maintenance overhead of maintaining libraries or simply want a quick path to apply auth across your apps. For more detailed scenarios and comparison on when it makes sense using Easy Auth versus other authentication methods can be found here. Setting up Easy Auth Let’s see Easy Auth in action. As you can see below I have a sample ASP.NET app hosted on App Service which is accessible without any authentication:- Now let’s demonstrate how quickly it is to setup Easy Auth for my app:- 1) I navigated to my App Service resource within the Azure Portal 2) I went to Authentication and used the below configuration o Selected Microsoft as the Identity provider o Workforce configuration (current tenant) o Create a new app registration (appropriate Entra ID roles are required) o Entra ID app name:- sot-easyauth o Client secret expiry:- 180 days (this means I must renew the secret in advance of the 180 days otherwise my app/authentication will fail to function upon expiry causing downtime). o Allow requests only from this application itself. o Current tenant – Single tenant (i.e users outside of my tenant will be denied access) o Identity requirement:- Allow requests from any identity o Restrict access:- Require authentication (this will require authentication across my whole app, whereas “Allow unauthenticated access” means it is up to my app to decide when authentication is required). o HTTP 302 Found redirect (redirects unauthenticated users to the login page rather than just a page stating 401 unauthorised for example). o Token store:- Enabled (also allows the app to have access to the token). 3) For permissions, I left the default User.Read Graph API permission selected. More information on the different permissions can be found here. Now if I go back to the app and refresh the page again, I am redirected to the login page which is surfaced by the Easy Auth middleware:- Only after successful authentication, will I be able to see the Welcome page again:- Now that is pretty impressive, but you might want to go even further and have questions such as: how will my app know who’s logged in? How can I access the claims? How do I perform more granular AuthZ? Well for starters, Easy Auth essentially creates the claims in the incoming token and exposes them to your app as request headers which your app can then leverage to interpret accordingly. The list of headers can be found here. Typically, you will be tasked with creating custom logic to decode and interpret these claims, but with the likes of ASP.NET (.NET Framework), App Service can populate the claims of the authenticated user without additional code logic. However for ASP.NET Core this does not hold true. Thus, given the approach differs between ASP.NET (.NET Framework) and ASP.NET Core (starting from .NET Core), I will split these up into two different sections after touching upon AuthZ and Entra ID app roles. AuthZ and Entra ID App Roles If your IIS ASP.NET app leverages Windows Authentication for AuthN, but your app manages AuthZ itself, perhaps by mapping the domain credentials (e.g. CONTOSO\Sam) to specific AuthZ roles stored in somewhere like a database and remains a requirement to do, you can achieve a similar outcome by using the claims provided by Easy Auth. However, it is not recommended to use fields such as domain credentials, e-mail or UPN (e.g. dan.long@contoso.com) given such attributes can change and even be re-used over time. For example, an employee called Dan Long has the UPN of dan.long@contoso.com leaves the company and another employee with the same name joins the company and is assigned the same UPN dan.long@contoso.com – potentially giving unauthorised access to resources belonging to the former employee. Instead you may consider using the oid (i.e objectId), which is a globally unique GUID that identifies the user across applications within a single tenant. You might also consider pairing oid with tid (i.e tenant ID) for sharding/routing if required. A note for multi-tenancy applications: the same user that exists in different tenants will have a different oid. More information on how to reliably identify a user and the different claim types available can be found here. Alternatively, if the built-in authorisation policies do not suffice, you can leverage Entra ID app roles to apply authorisation within your ASP.NET App, which we will cover in more depth further down below. For demonstration purposes, I have created an app role called Member in my Entra ID App Registration and assigned the Entra ID group “Contoso EA Members” to this role via the associated Entra ID Enterprise Application, which my identity is part of as shown below:- I am leveraging said role to restrict only the role Member from being able to access the Member Area page (more on this further down). More information on creating your own Entra ID app roles can be found here. ASP.NET (.NET Framework) claims and Entra ID App roles For ASP.NET 4.6 apps, App Service populates the user’s claims through ClaimsPrincipal.Current, which means you can easily reference the claims without additional logic. I have created sample code which demonstrates this here, and the output of this in App Service can be found below:- You will notice Easy Auth has picked up my Entra ID app role called Member under claim type roles. In the screenshot and sample, you will notice I have a link located on the top nav bar called Member Area which is guarded by an [Authorize] tag to restrict only members with the role Member access. Unfortunately, at this stage, if we were to access the page it will return with 401 Access Denied, regardless of my identity having the appropriate app role. The reason behind this, is because ASP.NET is looking for the claim type “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” instead of “role”. Fortunately, Easy Auth can be configured to display the long claim name instead by configuring the Environment Variable WEBSITE_AUTH_USE_LEGACY_CLAIMS to False, as shown in the below screenshot:- After the change, if I logout and back in again, I will see this being reflected back into my application and the Member Area page will grant me access as shown in the screenshots below:- Voila, we now have claims and Entra ID app roles working within our ASP.NET application. ASP.NET Core claims and Entra ID App roles Out-of-the-box, Easy Auth does not support populating ASP.NET Core with the current user’s authentication context like it does for ASP.NET (.NET Framework) with ClaimsPrincipal. However, this can be achieved by using the nuget package Microsoft.Identity.Web which has built-in capability to achieve this. What I did was as follows:- 1) Installed the nuget package Microsoft.Identity.Web into my solution. 2) In my Program.cs file, I loaded in the library:- builder.Services.AddMicrosoftIdentityWebAppAuthentication(builder.Configuration); 3) I also added app.UseAuthorization() after app.UseAuthentication() app.UseAuthentication(); After these changes, User.Identities will now be populated with the claims, and the [Authorize] tag will work permitting only the role Member when visiting the Member Area page. The full sample code can be found here. Unlike with ASP.NET (.NET Framework), the downside with this approach is the added responsibility of managing an additional library (Microsoft.Identity.Web). Conclusion App Service Easy Auth can provide a streamlined and efficient way to manage authentication and authorisation for your ASP.NET applications. By leveraging Easy Auth, you can apply modern auth protocols with minimal to zero code changes. The built-in support for various identity providers, including Entra ID, can help developers implement flexible and robust auth mechanisms. As demonstrated, Easy Auth simplifies the process of integrating authentication and authorisation into your applications, making it an valuable tool for modernising enterprise apps. Good to know and additional resources Limitations of Entra ID app roles. For example “A user, group, or service principal can have a maximum of 1,500 app role assignment”:- Service limits and restrictions - Microsoft Entra ID | Microsoft Learn. You can leverage Azure Policy to audit across the organisation when App Service does not have Easy Auth enabled by turning on “App Service apps should have authentication enabled”:- Built-in policy definitions for Azure App Service - Azure App Service | Microsoft Learn. Work with User Identities in AuthN/AuthZ - Azure App Service | Microsoft Learn Configure Microsoft Entra Authentication - Azure App Service | Microsoft Learn Work with OAuth Tokens in AuthN/AuthZ - Azure App Service | Microsoft LearnConnect Azure SQL Server via System Assigned Managed Identity under ASP.NET
TOC Why we use it Architecture How to use it References Why we use it This tutorial will introduce how to integrate Microsoft Entra with Azure SQL Server to avoid using fixed usernames and passwords. By utilizing System-assigned managed identities as a programmatic bridge, it becomes easier for Azure-related PaaS services (such as Container Apps) to communicate with the database without storing connection information in plain text. Architecture I will introduce each service or component and their configurations in subsequent chapters according to the order of A-C: A: The company's account administrator needs to create or designate a user as the database administrator. This role can only be assigned to one person within the database and is responsible for basic configuration and the creation and maintenance of other database users. It is not intended for development or actual system operations. B: The company's development department needs to create a Container App (or other service) as the basic unit of the business system. Programmers within this unit will write business logic (e.g., accessing the database) and deploy it here. C: The company's data department needs to create or maintain a database and designate Microsoft Entra as the only login method, eliminating other fixed username/password combinations. How to use it A: As this article does not dive into the detailed configuration of Microsoft Entra, it will only outline the process. The company's account administrator needs to create or designate a user as the database administrator. In this example, we will call this user "cch," and the account, "cch@thexxxxxxxxxxxx" will be used in subsequent steps. B-1: In this example, we can create a Container App with any SKU/region. Please note that during the initial setup, we will temporarily use the nginx:latest image from docker.io. After creating our own ASP.NET image, we will update it accordingly. For testing convenience, please enable Ingress traffic and allow requests from all regions. Once the Container App has been created, please enable the System Assigned Managed Identity. Lastly, please make a note of your App Name (e.g., mine is az-1767-aca) as we will use it in the following steps. C-1: Create a database/SQL server. During this process, you need to specify the user created in Step A as the database administrator. Please note that to select "Microsoft Entra-only authentication." In this mode, the username/password will no longer be used. Then, click on "Next: Networking." Microsoft Entra and Username & Password login methods are selected, for security reasons, it is strongly recommended to choose Microsoft Entra Only. The Username & Password option will not be used in this tutorial.) Since this article does not cover the detailed network configuration of the database, temporarily allow public access during the tutorial. Use the default values for other settings, click on "Review + Create," and then click "Create" to finish the setup. During this process, you need to specify the system-assigned managed identity created in Step B as the entity that will actually operate the database. And leave it default from the rest of the parts, and finally create the Database. C-2: After the database has created, you can log in using the identity "cch@thexxxxxxxxxxxx" you've get from Step A which is the database administrator. Open a PowerShell terminal and using the "cch" account, enter the following command to log in to SQL Server. You will need to change the <text> to follow your company's naming conventions. sqlcmd -S <YOUR_SERVER_NAME>.database.windows.net -d <YOUR_DB_NAME> -U <YOUR_FULL_USER_EMAIL> -G You will be prompt for a 2 step verification. dentities setup from Step B. First, we will introduce the method for the system-assigned managed identity. The purpose of the commands is to grant database-related operational permissions to the newly created user. This is just an example. In actual scenarios, you should follow your company's security policies and make the necessary adjustments accordingly. Please enter the following command. CREATE USER [<YOUR_APP_NAME>] FROM EXTERNAL PROVIDER; USE [<YOUR_DB_NAME>]; EXEC sp_addrolemember 'db_owner', '<YOUR_APP_NAME>'; For testing purposes, we will create a test table, and insert some data. CREATE TABLE TestTable ( Column1 INT, Column2 NVARCHAR(100) ); INSERT INTO TestTable (Column1, Column2) VALUES (1, 'First Record'); INSERT INTO TestTable (Column1, Column2) VALUES (2, 'Second Record'); B-2: Developers can now start building the Docker image. In my sample development environment, I'm using .NET 8.0. Run the following command in your development environment to create a Hello World project: dotnet new web -n WebApp --no-https This command will generate many files used for the project. You will need to modify both Program.cs and WebApp.csproj. using Microsoft.Data.SqlClient; var builder = WebApplication.CreateBuilder(args); var app = builder.Build(); app.MapGet("/", async context => { var response = context.Response; var connectionString = "Server=az-1767-dbserver.database.windows.net;Database=az-1767-db;Authentication=ActiveDirectoryMsi;TrustServerCertificate=True;"; await response.WriteAsync("Hello World\n\n"); try { using var conn = new SqlConnection(connectionString); await conn.OpenAsync(); var cmd = new SqlCommand("SELECT Column1, Column2 FROM TestTable", conn); using var reader = await cmd.ExecuteReaderAsync(); while (await reader.ReadAsync()) { var line = $"{reader.GetInt32(0)} - {reader.GetString(1)}"; await response.WriteAsync(line + "\n"); } } catch (Exception ex) { await response.WriteAsync($"[Error] {ex.Message}"); } }); app.Run("http://0.0.0.0:80"); <Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>net8.0</TargetFramework> <Nullable>enable</Nullable> <ImplicitUsings>enable</ImplicitUsings> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.Data.SqlClient" Version="5.1.4" /> </ItemGroup> </Project> Please note the connectionString in Program.cs. The string must follow a specific format — you’ll need to replace az-1767-dbserver and az-1767-db with your own server and database names. After making the modifications, run the following command in the development environment. It will compile the project into a DLL and immediately run it (press Ctrl+C to stop). dotnet run Once the build is complete, you can package the entire project into a Docker image. Create a Dockerfile in the root of your project. FROM mcr.microsoft.com/dotnet/sdk:8.0 # Install ODBC Driver RUN apt-get update \ && apt-get install -y unixodbc odbcinst unixodbc-dev curl vim \ && curl -sSL -O https://packages.microsoft.com/debian/12/prod/pool/main/m/msodbcsql18/msodbcsql18_18.5.1.1-1_amd64.deb \ && ACCEPT_EULA=Y DEBIAN_FRONTEND=noninteractive dpkg -i msodbcsql18_18.5.1.1-1_amd64.deb \ && rm msodbcsql18_18.5.1.1-1_amd64.deb # Setup Project Code RUN mkdir /WebApp COPY ./WebApp /WebApp # OTHER EXPOSE 80 CMD ["dotnet", "/WebApp/bin/Debug/net8.0/WebApp.dll"] In this case, we are using mcr.microsoft.com/dotnet/sdk:8.0 as the base image. To allow access to Azure SQL DB, you’ll also need to install the ODBC driver in the image. Use the following command to build the image and push it to your Docker Hub (docker.io). Please adjust the image tag, for example az-1767-aca:202504091739 can be renamed to your preferred version, and replace theringe with your own Docker Hub username. docker build -t az-1767-aca:202504091739 . --no-cache docker tag az-1767-aca:202504091739 theringe/az-1767-aca:202504091739 docker push theringe/az-1767-aca:202504091739 After building and uploading the image, go back to your Container App and update the image configuration. Once the new image is applied, visit the app’s homepage and you’ll see the result. References: Connect Azure SQL Server via User Assigned Managed Identity under Django | Microsoft Community Hub Managed identities in Azure Container Apps | Microsoft Learn Azure Identity client library for Python | Microsoft Learn
