|
| 1 | +# Non-interactive authentication for Azure CLI |
| 2 | + |
| 3 | +This document explains recommended non-interactive authentication modes for automation (CI/CD, scripts, headless servers) and provides safe examples and a small helper script. |
| 4 | + |
| 5 | +Supported modes |
| 6 | + |
| 7 | +- Service Principal (client secret) — recommended for CI systems where a secret can be stored securely. |
| 8 | +- Managed Identity (MSI) — recommended when running inside Azure (VM, VMSS, App Service, Function) and you can assign a managed identity. |
| 9 | +- Device Code — useful for ad-hoc non-browser sign-ins when interactive approval is acceptable. |
| 10 | +- Workload Identity — recommended for Kubernetes-based workloads using federated credentials. |
| 11 | + |
| 12 | +Environment variables |
| 13 | + |
| 14 | +The helper scripts and CI examples below use the following environment variables (common conventions): |
| 15 | + |
| 16 | +- AZURE_AUTH_MODE: one of `service-principal`, `managed-identity`, `device-code`, `workload-identity` (optional; script will try to auto-detect) |
| 17 | +- AZURE_CLIENT_ID |
| 18 | +- AZURE_CLIENT_SECRET |
| 19 | +- AZURE_TENANT_ID |
| 20 | +- AZURE_FEDERATED_TOKEN_FILE (for workload identity / token file) |
| 21 | + |
| 22 | +Security guidance |
| 23 | + |
| 24 | +- Store secrets in your CI secret store (GitHub Secrets, Azure DevOps variable groups, etc.). |
| 25 | +- Prefer managed identities or workload identity federation where possible to avoid long-lived secrets. |
| 26 | +- Limit permissions using least-privilege service principals. |
| 27 | + |
| 28 | +Examples |
| 29 | + |
| 30 | +Service principal (GitHub Actions) |
| 31 | + |
| 32 | +```yaml |
| 33 | +# GitHub Actions snippet |
| 34 | +env: |
| 35 | + AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }} |
| 36 | + AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }} |
| 37 | + AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }} |
| 38 | + |
| 39 | +steps: |
| 40 | +- name: Install Azure CLI |
| 41 | + uses: azure/CLI@v1 |
| 42 | + |
| 43 | +- name: Login with service principal |
| 44 | + run: az login --service-principal -u "$AZURE_CLIENT_ID" -p "$AZURE_CLIENT_SECRET" --tenant "$AZURE_TENANT_ID" |
| 45 | +``` |
| 46 | +
|
| 47 | +Managed Identity (Azure VM / App Service) |
| 48 | +
|
| 49 | +On an Azure VM with a system-assigned or user-assigned managed identity you can run: |
| 50 | +
|
| 51 | +```bash |
| 52 | +az login --identity |
| 53 | +``` |
| 54 | + |
| 55 | +Device code (interactive) |
| 56 | + |
| 57 | +```bash |
| 58 | +az login --use-device-code |
| 59 | +``` |
| 60 | + |
| 61 | +Workload identity (Kubernetes with federated credentials) |
| 62 | + |
| 63 | +Use Azure AD Workload Identity or federated credential to obtain a token and then use `az account get-access-token` or configure the environment according to your runtime. For CI that provides a token file, a short helper can run `az login --federated-token` style workflows; see the example helper script in `scripts/non_interactive_login.py`. |
| 64 | + |
| 65 | +Helper script |
| 66 | + |
| 67 | +A small helper script `scripts/non_interactive_login.py` is included that demonstrates safe detection of environment variables and returns the recommended `az login` command for common automation scenarios. The script is intentionally conservative and does not run `az` by default in unit tests. |
| 68 | + |
| 69 | +Further reading |
| 70 | + |
| 71 | +- https://docs.microsoft.com/azure/active-directory/develop/howto-create-service-principal-portal |
| 72 | +- https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview |
| 73 | +- https://learn.microsoft.com/azure/aks/workload-identity-overview |
0 commit comments