Key less access to Azure Services using AD Authentication using Managed Identity, User Managed Identity or Service Principal. Some samples include Cosmos DB, Azure Storage, Application Insight, Key Vault, etc.,

1. Secure Azure Services using AD
Authentication
Udaiappa Ramachandran ( Udai )
https://udai.io

2. About me
• Udaiappa Ramachandran ( Udai )
• CTO/CSO-Akumina, Inc.
• Microsoft Azure MVP
• Cloud Expert
• Microsoft Azure, Amazon Web Services, and Google
• New Hampshire Cloud User Group (http://www.meetup.com/nashuaug )
• https://udai.io

3. Agenda
• Introduction
• Managed Identity, User Managed Identty, and Service Principal
• RBAC
• Local Auth Mode
• Securing Services using AD Auth
• Demo…Demo…Demo…

4. RBAC Why?
• The Problem:
• Connecting to services requires knowing the key
• Key vault is secure, but is one more secret to manage
• Key rotation is more complicated because it needs to be synced with key vault
• Keys are all-or-nothing; if the key leaks, any caller can use it, unless your services are guard railed by
private network/private link
• The Solution:
• RBAC access removes the need to store any key in key vault
• Key rotation does not need because no key is even used
• Key access can be disabled entirely so even if the key is leaked, it is not usable
• Fine-grained control can be granted on an app-by-app basis
• Caveats:
• Not everything can be managed in portal; may need command line tools (ex., local auth for
CosmosDB)
• ComsosDB data explorer in azure portal requires key be enabled to function properly
• Cosmos Emulator does not support RBAC; must connect with key

5. Managed Identity
• Automatically managed by Azure.
• Scoped to a particular Azure resource.
• Useful when an application running on that resource needs to access other Azure
resources securely.
• Simplifies authentication and avoids the need to handle and store credentials
within the application's code.

6. User-Assigned Managed Identity
• Manually created by you.
• Separated from any specific resource, making it more flexible and reusable.
• Suitable when you want to share the same identity across multiple resources,
enabling central management of access.
• Offers better control over the lifecycle of the identity, allowing you to manage it
independently from the lifecycle of the resources it's used with.

7. Service Principal
• It's typically used when an application or script needs to access Azure
resources from outside of Azure (like a CI/CD pipeline).
• It can have different levels of access (roles/permissions) depending on what
it needs to do.
• It's manually created and managed by an Azure AD administrator.
• It's often used for long-running processes or automation tasks.

8. Sample Flow

9. Managed Identity Flow
1.An Azure resource (e.g., Virtual Machine) with a Managed Identity needs to
access another Azure service (e.g., Azure Key Vault).
2.The application running on the Azure resource sends a request to access the
target Azure service.
3.The Azure resource's Managed Identity sends an authentication request to
Azure Active Directory (Azure AD) automatically.
4.Azure AD validates the Managed Identity's request and provides an access
token to the Managed Identity.
5.The Managed Identity uses the received token to authenticate with the target
Azure service.
6.The target Azure service validates the token and, if authorized, allows the
Managed Identity to access the service's resources.

10. User-Assigned Managed Identity Flow
1.You create a User-Assigned Managed Identity in Azure.
2.You assign the User-Assigned Managed Identity to one or more Azure
resources (e.g., Virtual Machines, Azure Functions).
3.The application running on one of the assigned resources sends a request to
access an Azure service.
4.The User-Assigned Managed Identity associated with the resource sends an
authentication request to Azure AD.
5.Azure AD validates the Managed Identity's request and provides an access
token to the Managed Identity.
6.The Managed Identity uses the token to authenticate with the target Azure
service.
7.The target Azure service validates the token and, if authorized, allows the
Managed Identity to access the service's resources.

11. Service Principal Flow
1.An external application (e.g., a CI/CD pipeline) needs to interact with Azure
services.
2.The external application uses a Service Principal's credentials (client ID and
client secret) to request an access token from Azure AD.
3.Azure AD validates the Service Principal's credentials and provides an
access token to the application.
4.The application uses the received token to authenticate with the target Azure
service.
5.The target Azure service validates the token and, if authorized, allows the
application (through the Service Principal) to access the service's resources.

12. TokenCredential
var defaultTokenCredential = new DefaultAzureCredential();
var systemManagedTokenCredential = new ManagedIdentityCredential();
var userManagedTokenCredential = new ManagedIdentityCredential("[clientId]");
var spTokenCredential = new ClientSecretCredential("[TenantId]", "[clientId]","[clientSecret]");

13. Azure service that supports AAD authentication
• API Management
• Azure App Configuration
• Azure App Services
• Azure Batch
• Azure Container Registry
• Azure Cognitive Services
• Azure Communication Services
• Azure Cosmos DB
• Azure Databricks
• Azure Data Explorer
• Azure Data Lake Storage Gen1
• Azure Database for PostgreSQL
• Azure Digital Twins
• Azure Event Hubs
• Azure IoT Hub
• Azure Key Vault
• Azure Kubernetes Service (AKS)
• Azure Machine Learning Services
• Azure Maps
• Azure Media services
• Azure Monitor
• Azure Resource Manager
• Azure Service Fabric
• Azure Service Bus
• Azure SignalR Service
• Azure SQL
Azure Managed Instance
• Azure Static Web Apps
• Azure Storage
• Azure Virtual Machines
https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-id-
authentication-support

14. Demo
• Key vault
• App Insight – local auth disabled
• Cosmos DB – local auth disabled and keyless
• Azure Storage (Blob, Table, Queue, Files)
• Etc.,

15. CosmosDB – Disabling LocalAuth, R/W access
$subscriptionId="[YOUR SUBSCRIPTION ID]"
$cosmosDbAccountName = "[YOUR COSMOS ACCOUNT NAME]"
$resourceGroupName = "[YOUR RESOURCE GROUP]"
$objectId="[YOUR OBJECT ID]"
$roleName="[YOUR CUSTOM ROLE NAME]"
az account set --subscription $subscriptionId
$cosmosdb = az cosmosdb show --name $cosmosDBAccountName --resource-group
$resourceGroupName | ConvertFrom-Json
#Disable Local Auth
az resource update --ids $cosmosdb.id --set properties.disableLocalAuth=true
#For Built-in Data Read/Write
$roleDefId= '00000000-0000-0000-0000-000000000002' #001 -readonly #002-
read/write
az cosmosdb sql role assignment create --account-name $cosmosDbAccountName -
-resource-group $resourceGroupName --role-definition-id $roleDefId --
principal-id $objectId --scope "/"

16. Application Insight
• Disable Enable Local auth from Overview
• Give “Monitoring Metrics Publisher” permissions from Access Control section of the App Insight.

17. Reference
• https://learn.microsoft.com/en-us/azure/app-service/tutorial-connect-msi-sql-
database?WT.mc_id=AZ-MVP-5004665
• https://learn.microsoft.com/en-us/azure/azure-monitor/app/azure-ad-
authentication?WT.mc_id=AZ-MVP-5004665
• https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-setup-
rbac#permission-model?WT.mc_id=AZ-MVP-5004665

18. Thanks for your time and trust!
New Hampshire CLOUD .NET User Group