Skill

Authenticate Azure Services Securely

Python skill for Azure Identity authentication - DefaultAzureCredential's fallback chain, managed identity, and token scopes.

Works with azure

91
Spark score
out of 100
Updated last month
Version 13.12.0

Add to Favorites

Why it matters

Streamline authentication for Azure services by leveraging Microsoft Entra ID (formerly Azure AD). This skill enables secure access for applications and services across various Azure environments, from local development to production deployments.

Outcomes

What it gets done

01

Implement secure authentication using DefaultAzureCredential.

02

Manage service principal and managed identity credentials.

03

Integrate with Azure SDK clients for seamless access.

04

Configure authentication for CI/CD pipelines and Kubernetes.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-azure-identity-py | bash

Overview

Azure Identity SDK for Python

Python skill for azure-identity authentication, covering the eight-credential DefaultAzureCredential fallback chain, managed identity and service-principal credentials, custom ChainedTokenCredential chains, direct token acquisition via get_token, and async credential usage. Use whenever a Python Azure SDK client needs to authenticate to Microsoft Entra ID, or a script needs a raw access token for a specific resource scope.

What it does

This skill authenticates Azure SDK clients using azure-identity (pip install azure-identity), the Python library for Microsoft Entra ID (formerly Azure AD) authentication. Its centerpiece is DefaultAzureCredential, which works unmodified in both local development and production by trying credential sources in order: EnvironmentCredential (CI/CD, containers), WorkloadIdentityCredential (Kubernetes), ManagedIdentityCredential (Azure VMs/App Service/Functions), SharedTokenCacheCredential (Windows only), VisualStudioCodeCredential (VS Code with the Azure extension), AzureCliCredential (az login), AzurePowerShellCredential (Connect-AzAccount), and AzureDeveloperCliCredential (azd auth login) - with interactive browser auth excluded by default. It's customized by excluding specific credential types (exclude_environment_credential, exclude_shared_token_cache_credential, etc.), enabling interactive browser fallback, or setting managed_identity_client_id for a user-assigned identity. Beyond the default chain, it covers ManagedIdentityCredential directly (system-assigned with no arguments, or user-assigned via client_id) for Azure-hosted resources, ClientSecretCredential for service-principal auth with a tenant/client ID and secret, AzureCliCredential reusing the local az login session, and ChainedTokenCredential for building a custom fallback order (e.g. managed identity first, Azure CLI as local fallback) - alongside a reference table covering ClientCertificateCredential, InteractiveBrowserCredential, and DeviceCodeCredential for headless/SSH scenarios. Tokens can be requested directly via credential.get_token(scope) for a specific resource scope, with two concrete scope examples shown: Azure Resource Manager (https://management.azure.com/.default) and Azure Database for PostgreSQL's AAD-auth endpoint (https://ossrdbms-aad.database.windows.net/.default). An async variant (azure.identity.aio) mirrors the sync API, requiring an explicit await credential.close() (or an async context manager) since async credentials hold open resources. Best practices: use DefaultAzureCredential for code that must run both locally and in Azure, never hardcode credentials, prefer managed identity in production, use ChainedTokenCredential for a custom credential order, explicitly close async credentials, set AZURE_CLIENT_ID for user-assigned managed identities, and exclude unused credential types to speed up authentication (since the chain probes each one in order until one succeeds).

When to use - and when NOT to

Use this skill whenever a Python Azure SDK client (Blob Storage, Key Vault, Cosmos DB, and others) needs to authenticate to Microsoft Entra ID, or when a script needs a raw access token for a specific resource scope (e.g. calling Azure Resource Manager or an AAD-authenticated database directly). It is not for authenticating to non-Azure/non-Entra-ID services, and relying on the full DefaultAzureCredential probing chain everywhere adds latency in production compared to a specific, deterministic credential like ManagedIdentityCredential. Service-principal auth is configured the same way via AZURE_TENANT_ID/AZURE_CLIENT_ID/AZURE_CLIENT_SECRET environment variables.

Inputs and outputs

Input is credential configuration (environment variables, a managed identity client ID, or service-principal tenant/client/secret) or a target resource scope. Output is a credential object passed to any Azure SDK client constructor, or a raw access token with an expiration time for direct API calls.

Integrations

Built as azure-identity, integrating with every Azure SDK Python client library that accepts a credential object (Blob Storage, Key Vault, Cosmos DB, etc.), and usable standalone via get_token for direct REST calls to Azure Resource Manager or AAD-authenticated databases.

pip install azure-identity

Who it's for

Python developers authenticating any Azure SDK client to Microsoft Entra ID, who need code that works across local development and Azure-hosted production, or need to request raw access tokens for direct API calls.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.