AzureML Workspace Configuration via Environment Variables

General Python For Data Science & Machine Learning
, , ,
1

Purpose

Standardize how engineers configure the Azure Machine Learning (AzureML) workspace context on local machines and CI/CD runners using environment variables. This pattern avoids hard-coding workspace identifiers in code and reduces accidental leakage of sensitive identifiers into repos, logs, or notebooks.

Sensitive Information Handling

The following values must be treated as sensitive operational identifiers:

  • Subscription ID

  • Tenant ID

  • Resource Group name

  • Workspace name (often encodes org/project/environment)

Do not paste real values into:

  • Git repos (including private repos)

  • Documentation that’s broadly shared

  • Issue trackers, chat tools, or screenshots

  • Notebook outputs (especially if shared)

Use placeholders in documentation (as below) and store real values in secret managers or protected CI variables.

Recommended Environment Variables

Use a consistent naming convention so scripts, notebooks, and CLIs can reliably discover the current workspace context.

Bash / Zsh (Linux/macOS)

# AzureML workspace context (use real values locally; do not commit)
export AZUREML_WORKSPACE_NAME="<your-aml-workspace-name>"
export AZUREML_RESOURCE_GROUP="<your-resource-group-name>"
export AZUREML_SUBSCRIPTION="<your-subscription-id>"
export AZUREML_TENANT_ID="<your-tenant-id>"   # optional, but useful in multi-tenant setups

PowerShell (Windows)

$env:AZUREML_WORKSPACE_NAME = "<your-aml-workspace-name>"
$env:AZUREML_RESOURCE_GROUP = "<your-resource-group-name>"
$env:AZUREML_SUBSCRIPTION   = "<your-subscription-id>"
$env:AZUREML_TENANT_ID      = "<your-tenant-id>"

Where to Set These Variables

Option A: Per-terminal session (fastest)

Set exports in the current shell session when you need them (best for quick experiments).

Option B: Shell profile (persistent for your user)

Add to one of:

  • ~/.bashrc, ~/.bash_profile (bash)

  • ~/.zshrc (zsh)

Caution: ensure the profile file is not synced to a shared dotfiles repo.

Option C: .env file (recommended for projects)

Create a local-only .env and load it from your tooling.

Example .env (DO NOT COMMIT):

AZUREML_WORKSPACE_NAME=<your-aml-workspace-name>
AZUREML_RESOURCE_GROUP=<your-resource-group-name>
AZUREML_SUBSCRIPTION=<your-subscription-id>
AZUREML_TENANT_ID=<your-tenant-id>

Add to .gitignore:

.env
.env.*

Load in Python:

from dotenv import load_dotenv
load_dotenv()

Quick Validation Checks

1) Confirm variables are set

echo "$AZUREML_WORKSPACE_NAME"
echo "$AZUREML_RESOURCE_GROUP"
echo "$AZUREML_SUBSCRIPTION"

2) Confirm Azure CLI login aligns with the subscription (optional but recommended)

az account show --query "{name:name, id:id, tenantId:tenantId}" -o json

If needed:

az account set --subscription "$AZUREML_SUBSCRIPTION"

Common Pitfalls

  • Accidentally logging environment variables in notebooks/CI logs.

  • Using multiple Azure tenants and authenticating into the wrong one.

  • Committing .env or writing workspace IDs into code/config that gets checked in.

Mitigations:

  • Use Key Vault / CI secret variables for pipelines.

  • Mask secrets in CI logs.

  • Prefer managed identity/service principal in automation instead of user auth.

Metadata

Category: Engineering → MLOps → AzureML
Tags: azureml, azure, mlops, workspace, env-vars, secrets, dotenv