Identity Checklist
Use this checklist for every new Azure workload or remediation involving managed identity, workload identity federation, or passwordless Azure access.
Discovery
- Runtime identified: App Service, Function App, Container App, VM/VMSS, AKS, Azure DevOps, GitHub Actions, local development, or other.
- Effective runtime identity identified by principal ID/object ID/client ID.
- Target resource, operation, and permission model identified.
- Management-plane and data-plane permissions are separated.
- Human/developer permissions are not assumed to apply to workload identities.
Identity selection
- System-assigned identity used for single-purpose Azure resources.
- User-assigned identity used when identity must be stable, shared, pre-provisioned, or survive resource recreation.
- AKS pods use Microsoft Entra Workload ID, not Microsoft Entra pod-managed identity.
- Azure DevOps and GitHub Actions use workload identity federation/OIDC, not client secrets.
- Separate identities are used per workload and environment unless sharing is explicitly justified.
Credential usage
- Production code uses
ManagedIdentityCredential,WorkloadIdentityCredential,AzurePipelinesCredential, or an intentionally constrained credential chain. - Unrestricted
DefaultAzureCredentialis limited to local development. - User-assigned identity client ID is explicitly configured where multiple identities can exist.
- Credential instances are reused; credentials are not created per request.
- Direct token use includes refresh handling, or an Azure SDK client handles refresh automatically.
Permissions
- Built-in data-plane roles used where possible.
- Custom roles used only when built-in roles are too broad or unavailable.
- Roles scoped to the smallest practical target: container/queue/topic/event hub/resource before resource group before subscription.
- Application identities are not granted
Owner,Contributor,User Access Administrator, or RBAC-admin permissions for data access. - Role assignment names are deterministic and idempotent in IaC.
-
principalType: 'ServicePrincipal'is set for service identity role assignments.
Service-specific authorization
- Azure SQL has Microsoft Entra authentication configured, a contained database user for the identity, and database roles/grants.
- Cosmos DB for NoSQL uses native Cosmos data-plane RBAC for data access.
- Key Vault uses the Azure RBAC permission model when possible.
- Service Bus/Event Hubs use sender/receiver roles rather than namespace owner permissions.
- Storage uses blob/file/queue/table data roles as applicable, not account keys.
Local authentication and secrets
- Storage shared key access disabled where supported:
allowSharedKeyAccess: false. - Cosmos DB local/key auth disabled where supported:
disableLocalAuth: true. - Service Bus local/SAS auth disabled:
disableLocalAuth: true. - Event Hubs local/SAS auth disabled:
disableLocalAuth: true. - Application Insights local auth disabled where supported.
- Azure SQL Entra-only authentication enabled where operationally safe.
- No app settings, pipeline variables, IaC outputs, or logs expose keys, SAS tokens, client secrets, or credential-bearing connection strings.
Federation
- Issuer, subject, and audience are exact and environment-specific.
- GitHub Actions workflow has
permissions: id-token: writeand production uses protected environments. - Azure DevOps service connection is not granted to all pipelines by default.
- Federated credential subjects are updated when repository, branch, environment, project, organization, or service connection names change.
- Tenant restrictions for workload identity federation have been checked if token exchange fails.
Verification
- Identity token can be acquired in the runtime environment.
- Correct principal has the required data-plane access.
- Secret/key/SAS connection path fails after local auth is disabled.
- App startup retries tolerate RBAC propagation delays.
- Logs identify the credential type without logging tokens or secrets.
- Rollback plan does not silently reintroduce long-lived secrets.