Managing Azure Credentials Securely

Learn how Azure credentials, Microsoft Entra identities, Azure RBAC, managed identities, Key Vault, and workload federation support secure Azure access.

Azure credentials are proof that an identity is allowed to access Azure resources or call Azure APIs. A credential may be an interactive sign-in, password, client secret, certificate private key, managed identity token, or federated token.

Two concepts must be kept separate:

Authentication verifies who or what is requesting access.
Authorization determines which actions that authenticated identity may perform.

Azure access commonly uses Microsoft Entra ID, Microsoft's cloud identity and access management service. Azure does not rely on one platform-wide username and password. Users, applications, automation systems, and Azure-hosted workloads can use different identity types and authentication methods.

See the related Azure credentials reference while applying these practices.

Azure identity types

An identity that can receive permissions is called a principal. A principal may be a user, group, service principal, or managed identity.

User identity: Represents a person who signs in interactively, usually through a browser, device code, or another supported sign-in method.
Group: Contains users or other supported principals. Assigning a role to a group can be easier to manage than assigning the same role to many individuals.
Service principal: The tenant-specific Microsoft Entra representation of an application or automation workload. Scripts, deployment pipelines, and background services commonly use service principals.
Managed identity: An Azure-managed identity for a supported Azure resource. The workload obtains tokens without storing a client secret in its configuration.
Workload identity federation: Establishes trust with an external identity provider. A CI/CD workload can present a short-lived OpenID Connect token and obtain an Azure token without storing a client secret.

Credential forms and authentication methods

Identity or credential type — Typical use case — Interactive or non-interactive — Secret storage required — Security considerations

User interactive sign-in — Human administration and development — Interactive — Usually no application secret — Protect the account with multifactor authentication and appropriate Conditional Access policies.

Password — Legacy or specially controlled sign-in scenarios — Interactive or non-interactive — Yes — Passwords are high-value secrets; use multifactor authentication and prefer stronger supported methods.

Service principal client secret — Simple scripts and automation — Non-interactive — Yes — Secrets are long-lived unless managed carefully and must be rotated before expiration.

Service principal certificate — Automation requiring an application credential — Non-interactive — Private key must be protected — Certificate authentication can be stronger than a shared secret, but private-key protection and renewal remain responsibilities.

Managed identity — Azure-hosted applications and jobs — Non-interactive — No application-managed secret — Assign only the required Azure roles and resource permissions.

Federated identity credential — External CI/CD and workload platforms — Non-interactive — No stored Azure client secret — Restrict trust to the intended repository, branch, environment, or workload claims.

Common tools use these methods in different ways:

Azure CLI: az login starts an interactive browser sign-in by default. Device-code sign-in is useful when a browser is unavailable.
Azure PowerShell: Its sign-in cmdlets support interactive and non-interactive credential flows.
Azure portal: Uses the signed-in user's Microsoft Entra identity through a browser.
Azure SDKs: Credential libraries can try a sequence of supported sources. DefaultAzureCredential is a common choice because the same application code can use local developer credentials and a managed identity in Azure.

Identifiers versus secrets

Value — Purpose — Example format — Sensitive classification — Where commonly used

Tenant ID — Identifies a Microsoft Entra tenant — UUID — Generally an identifier; follow organizational policy — Login configuration and token requests.

Subscription ID — Identifies an Azure subscription — UUID — Generally an identifier; follow organizational policy — Azure CLI context, SDK configuration, and resource IDs.

Client ID or application ID — Identifies an app registration or service principal — UUID — Generally an identifier, not a secret — Application authentication configuration.

Object ID — Identifies a specific directory object — UUID — Generally an identifier; avoid unnecessary disclosure — Role assignments and directory operations.

Resource ID — Identifies an Azure resource and its scope — Resource path — Generally an identifier; access may still reveal useful infrastructure information — Role assignments, deployment commands, and APIs.

Client secret — Confidential application credential — Generated string — Sensitive secret — Service principal authentication.

Password — Secret used to authenticate a user or account — User-defined or generated string — Sensitive secret — Interactive or controlled automation sign-in.

Access token — Short-lived token presented to an Azure service or API — Token string — Sensitive while valid — API and Azure service requests.

Certificate private key — Private portion of a certificate credential — Key material — Highly sensitive — Service principal certificate authentication.

Connection string — Often contains endpoint and authentication material — Configuration string — Sensitive when it contains keys or passwords — Application connections to services.

Identifiers are not usually sufficient to authenticate a caller, but they should still be handled according to organizational policy. Passwords, access tokens, private keys, connection strings, and client secrets must be treated as confidential.

App registrations and service principals

An app registration is an application identity definition in Microsoft Entra ID. It describes an application and can contain redirect settings, API permissions, federated identity credentials, and application credentials.

A service principal is the application identity's representation inside a particular tenant. The app registration describes the application globally within the directory model; the service principal is the tenant-local principal that can receive Azure role assignments.

Creating a client secret or certificate credential through the app registration does not automatically grant Azure resource access. The service principal must receive an Azure RBAC role assignment at an appropriate scope.

az ad sp create-for-rbac --name "<automation-name>" --role "Contributor" --scopes "/subscriptions/<subscription-id>/resourceGroups/<resource-group>"

Client secrets have expiration dates. Certificate credentials also require private-key protection, renewal, and planned replacement. Do not wait for expiration to discover that a deployment depends on one credential.

Authorization with Azure RBAC

Azure role-based access control (Azure RBAC) assigns permissions to principals at Azure resource scopes.

Role definition: A named collection of allowed actions, such as reading resources or deploying resources.
Role assignment: Connects a role definition to a principal at a scope.
Principal: The user, group, service principal, or managed identity receiving the assignment.
Scope: The boundary where the assignment applies.

Scope — Resources affected — When to use it — Least-privilege caution

Management group — Subscriptions and resources beneath the management group — Organization-wide governance — Broad inheritance can grant more access than intended.

Subscription — All supported resources in a subscription — Subscription-level administration — Prefer a resource group or resource scope when possible.

Resource group — Resources contained in the group — A deployment pipeline managing one application environment — Confirm that every resource in the group should receive the role.

Individual resource — One resource — A workload needing access to one vault, storage account, or service — Narrowest common scope; verify that dependent data-plane permissions are also present.

Use the narrowest suitable role and scope. Also distinguish the management plane, which controls resources and configuration, from the data plane, which accesses data inside a service. For example, being able to view a Key Vault resource does not necessarily grant permission to read its secrets.

az role assignment list --assignee "<principal-id-or-client-id>" --all --output table

Managed identities

Managed identities remove the need to place application-managed credential material in code, configuration files, or deployment variables. Azure provides the identity endpoint and the workload requests a short-lived token for a target service.

System-assigned managed identity: Created as part of an Azure resource and removed when that resource is deleted. It is normally tied to one resource lifecycle.
User-assigned managed identity: A standalone Azure resource that can be assigned to one or more supported Azure resources. Its lifecycle is managed independently.

The general setup is:

Enable a system-assigned identity on the application host, or create a user-assigned identity.
Attach the user-assigned identity to the supported compute resource when using one.
Assign the identity an Azure RBAC role or resource-specific permission at the narrowest required scope.
Use an SDK default credential provider in application code to acquire a token.

az identity create --name "<identity-name>" --resource-group "<resource-group>"
az identity show --name "<identity-name>" --resource-group "<resource-group>"

After retrieving the identity's principal ID, assign only the required role at the intended resource scope. The platform-specific attachment command depends on the compute service; configure that service to use the user-assigned identity's resource ID or enable its system-assigned identity setting.

# Application code pattern
credential = DefaultAzureCredential()
# Use credential with the Azure SDK client for the target service

In supported Azure-hosted production environments, prefer managed identity over a stored service principal secret.

Secure credential storage

Never commit secrets to source control, embed them in application code, place them in container images, or write them to logs. Removing a visible copy later does not invalidate a credential that may already have been copied.

Azure Key Vault

Azure Key Vault stores and controls access to secrets, cryptographic keys, and certificates. Use Azure RBAC or the vault's selected permission model to grant an application only the required operation, such as reading one secret.

az keyvault secret set --vault-name "<key-vault-name>" --name "<secret-name>" --value "<secret-value>"
az keyvault secret show --vault-name "<key-vault-name>" --name "<secret-name>"

Do not place real production values in shell history, examples, tickets, or lesson files. A web application can use its system-assigned managed identity, receive a narrowly scoped Key Vault data-plane permission, and retrieve the secret at runtime.

Environment variables and local stores

Environment variables can keep development values out of source files, but they are not automatically safe. Values may appear in shell history, process inspection, crash reports, CI configuration, or diagnostic output. Use a local secret store or development-only configuration mechanism where available, and keep local values separate from production credentials.

For a specifically configured service principal, common SDK environment variables include:

AZURE_TENANT_ID=<tenant-id>
AZURE_CLIENT_ID=<client-id>
AZURE_CLIENT_SECRET=<client-secret>

This pattern is useful for controlled non-production testing, but a production Azure workload should generally use managed identity or workload identity federation instead.

Local development authentication

Use an interactive sign-in for local development rather than copying production secrets to a workstation.

az login
az account show
az account list --output table
az account set --subscription "<subscription-id-or-name>"

When multiple subscriptions are available, explicitly select the intended subscription and confirm the active context before running commands that create, modify, or delete resources.

Azure SDK default credential libraries can discover a local Azure CLI sign-in or another supported developer credential. This lets application code use the developer's local identity while the same code uses a managed identity after deployment. Test the exact credential source rather than assuming that every environment has the same chain.

Automation and CI/CD authentication

Method — Best for — Rotation burden — Risk of long-lived secret exposure — Recommended status

Client secret — Simple legacy automation — High — High — Use only when necessary; protect and rotate it.

Certificate — Automation that supports private-key credentials — Moderate — Lower than a plain secret if the key is well protected — Suitable with managed renewal and secure key storage.

Managed identity — Azure-hosted automation — Low — Low; no application-managed secret — Preferred for supported Azure-hosted workloads.

Workload identity federation — External CI/CD platforms — Low — Low; uses short-lived federated tokens — Preferred where supported.

A deployment pipeline should have only the permissions needed to deploy its target. Assign a narrowly scoped role at the resource group or individual resource rather than the whole subscription when possible. Keep deployment credentials separate from the identity used by the running application; these identities often require different permissions and have different lifecycles.

With workload identity federation, configure a federated identity credential between the pipeline platform and Microsoft Entra ID. Restrict its claims to the intended repository, branch, environment, or workload context. The pipeline presents an external OpenID Connect token, and Microsoft Entra ID exchanges trust in that token for a short-lived Azure access token.

Credential lifecycle management

Create: Generate only the credential type required by the workload and document its owner, purpose, scope, and expiration.
Inventory: Track app registrations, service principals, managed identities, certificates, secrets, role assignments, and dependent applications.
Rotate: Replace credentials before expiration. Where supported, create a replacement while the old credential remains valid, deploy the replacement, verify it, and then revoke the old one.
Expire and revoke: Set appropriate expiration periods and immediately revoke credentials that are exposed, unused, or no longer owned.
Remove: Delete unused service principals, stale role assignments, obsolete secrets, and old certificates.
Review: Inspect sign-in logs, audit records, role assignments, and Key Vault access records for unexpected activity.

Rotation is a deployment process, not only an identity-administration task. Test replacement credentials in a non-production environment and ensure rollback does not require restoring an expired or exposed secret.

Responding to a compromised credential

Treat an exposed password, client secret, access token, certificate private key, or connection string as compromised, even if exposure was brief.

Revoke or delete the exposed credential immediately.
Create and deploy a replacement credential if the workload still needs that authentication method.
Review sign-in, activity, and audit logs for misuse during the exposure window.
Inspect role assignments and reduce permissions if the identity had unnecessary access.
Remove the value from active configuration, logs, source files, and repository history according to organizational procedures. Remember that deleting a visible copy does not invalidate the credential.
Add preventive controls such as secret scanning, protected pipeline variables, Key Vault storage, log redaction, expiration alerts, and stronger identity methods.

Practical patterns

Developer signs in locally

The developer runs az login, lists subscriptions, selects the intended subscription, and confirms it with az account show. An SDK using DefaultAzureCredential can discover the same local developer sign-in without putting a production secret in the project.

Deployment script uses a service principal

Create an app registration and service principal, assign the minimum required role at the target resource group, and provide the tenant ID, client ID, and protected credential through the automation environment. Plan replacement before the client secret or certificate expires, or migrate to federation.

Web application reads a Key Vault secret

Enable a system-assigned managed identity on the application host. Grant that identity only the Key Vault data-plane permission needed for the intended secret. The application uses its default credential chain to request a token and reads the secret at runtime without placing it in application configuration.

CI/CD uses federation

Configure workload identity federation between the pipeline and Microsoft Entra ID. Restrict the federated identity credential to the correct repository, branch, environment, or workload claims, then assign deployment permissions at the narrowest practical scope.

An accidental client-secret exposure

Revoke the secret immediately, create and deploy a replacement, review logs and role assignments, remove the exposed value from configuration and repository history, and add scanning and protected secret storage to prevent recurrence.

Troubleshooting guide

Symptom — Likely cause — How to verify — Resolution

No subscription is selected or the wrong subscription is used — Multiple subscriptions or unchanged CLI context — Run az account list --output table and az account show — Run az account set --subscription with the intended ID or name, then confirm the context.

Authentication succeeds but the operation returns AuthorizationFailed — Missing role, wrong scope, or management-plane permission without required data-plane access — Identify the principal and run az role assignment list — Grant the minimum role at the correct scope and allow time for permission propagation.

A service principal suddenly fails — Client secret or certificate expired, was revoked, or a tenant policy changed — Check the app registration credential expiration and sign-in records — Deploy a controlled replacement and prefer managed identity or federation where applicable.

An Azure-hosted app cannot access Key Vault — Identity is disabled, unattached, or lacks data-plane permission; target settings may be wrong — Confirm the principal ID, vault URI, secret name, tenant, and permission model — Enable or attach the identity and grant the required least-privilege Key Vault role or permission.

Default credential works locally but fails after deployment — Local CLI or IDE credentials are available, but deployment has no managed identity or workload credential — Determine which local credential source succeeded and inspect deployment identity settings — Configure the intended production identity and test in a matching non-production environment.

A secret appears in a repository or log — Configuration, command-line output, pipeline output, or debug logging exposed it — Search repository history, pipeline records, and logs — Revoke and replace it immediately, sanitize copies, enable scanning, use protected storage, and redact logs.

Exam-relevant notes

Authentication proves identity; authorization grants permissions.
A client ID, tenant ID, or subscription ID identifies something but is not normally a secret. A client secret, password, access token, and certificate private key are confidential.
An app registration defines an application identity; its service principal is the tenant-local principal that receives Azure role assignments.
A service principal cannot manage Azure resources merely because it exists; it needs an appropriate role assignment and scope.
Managed identities remove application-managed secrets from Azure-hosted workloads.
System-assigned identities follow a resource's lifecycle; user-assigned identities are independent resources that can be reused.
Least privilege means selecting both the narrowest suitable role and the narrowest suitable scope.
Workload identity federation uses external OIDC trust and short-lived tokens instead of a stored client secret.