Managed Identities

Credentials Azure rotates for you

Storing a connection string or client secret in configuration is the most common way cloud apps leak access. A managed identity removes the secret: Azure creates a service principal for your resource and the code obtains tokens from a local endpoint, with credentials rotated by the platform. A system-assigned identity is tied to one resource and deleted with it. A user-assigned identity is its own resource, can be attached to several resources and survives them, which suits scale sets and blue-green deployments. You then give the identity RBAC roles on targets such as Storage, Key Vault, Service Bus or Azure SQL. In code, the Azure SDKs' DefaultAzureCredential tries a chain of sources: environment variables, managed identity, and on a laptop your az login session, so the same code runs locally and in Azure.

Using DefaultAzureCredential in Python

No keys appear in the code or config; access depends only on the role assigned to the identity.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

credential = DefaultAzureCredential()  # managed identity in Azure, az login locally
service = BlobServiceClient(
    account_url="https://stshopdev123.blob.core.windows.net",
    credential=credential,
)

container = service.get_container_client("invoices")
for blob in container.list_blobs():
    print(blob.name)

Turn off key-based access where you can

Once apps use managed identities, disable shared keys and local authentication on services that support it (for example allowSharedKeyAccess: false on storage accounts). Otherwise an old leaked key still works.

त्वरित जाँच: Several VMs in a scale set and a deployment slot must share one identity that outlives them. What should you use?

• A user-assigned managed identity
• A system-assigned managed identity
• A storage account key
• A personal user account