Skip to content

Credentials & auth

The two questions every recipe needs answered:

  1. How do I authenticate from my laptop?
  2. How does a workload running in the cloud authenticate — without shipping a long-lived secret?

Answer for each provider: the CLI signs you in locally; a workload identity (attached to the compute) signs the process in in-cloud. Long-lived static keys are the last-resort fallback and Chiron never recommends them.

Local dev — sign in from your laptop

Official docs verified 2026-08-08

Sign in with Azure CLI

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

Under the hood, az login opens a browser and stores tokens in ~/.azure/. The Python SDK's AzureCliCredential reuses that session (no extra config needed).

Official docs verified 2026-08-08

Application Default Credentials

Two distinct sign-ins in gcloud — they authorize different things:

# (1) Authorize gcloud itself — so `gcloud <command>` works.
gcloud auth login
gcloud config set project MY_PROJECT_ID

# (2) Authorize Application Default Credentials — so
#     Python SDKs picking up ADC on this host use YOUR account.
gcloud auth application-default login

ADC file lands at ~/.config/gcloud/application_default_credentials.json on Linux/macOS, %APPDATA%\gcloud\application_default_credentials.json on Windows.

Official docs verified 2026-08-08

aws configure · boto3 credentials

For a personal IAM user or an IAM Identity Center (SSO) profile:

# Long-lived access key pair (last-resort dev path)
aws configure

# AWS IAM Identity Center (SSO) — RECOMMENDED
aws configure sso
aws sso login --profile <profile-name>

Files land at ~/.aws/credentials (key material) and ~/.aws/config (profile config). boto3 reads both by default.

Workload identity — sign in from the cloud

The zero-secret pattern per provider. Deploy your workload with the right identity attached, and the SDK just works — no keys mounted, no tokens to rotate.

Official docs verified 2026-08-08

Managed identity overview

AKS + Microsoft Entra Workload ID. Enable the workload-identity feature on the cluster, annotate the ServiceAccount with the target user-assigned managed identity's client-id, and the pod gets a projected token that DefaultAzureCredential uses via WorkloadIdentityCredential:

# k8s ServiceAccount → managed identity binding
apiVersion: v1
kind: ServiceAccount
metadata:
  name: chiron-workload
  annotations:
    azure.workload.identity/client-id: "<MI_CLIENT_ID>"

Azure Functions / Container Apps: enable the resource's system-assigned managed identity via the portal / CLI:

az functionapp identity assign --name my-func \
  --resource-group chiron-demo

# Grant it a role
az role assignment create \
  --assignee "$(az functionapp identity show \
      --name my-func --resource-group chiron-demo --query principalId -o tsv)" \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/.../resourceGroups/chiron-demo/providers/Microsoft.Storage/storageAccounts/mystorage

Official docs verified 2026-08-08

Workload Identity Federation · GKE Workload Identity

GKE Workload Identity binds a Kubernetes ServiceAccount to a GCP IAM service account. ADC then hands the SDK an OIDC-federated token — no key file:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: chiron-workload
  annotations:
    iam.gke.io/gcp-service-account: chiron-workload@MY_PROJECT.iam.gserviceaccount.com

Cloud Run / Cloud Functions accept a --service-account flag at deploy time. The runtime metadata server issues the SDK a token for that account:

gcloud run deploy chiron-demo \
  --image us-docker.pkg.dev/cloudrun/container/hello \
  --service-account chiron-workload@MY_PROJECT.iam.gserviceaccount.com \
  --region us-central1

Official docs verified 2026-08-08

IAM roles for service accounts (IRSA) · EC2 instance profiles

EKS IRSA associates a Kubernetes ServiceAccount with an IAM role via OIDC. boto3 picks up AWS_ROLE_ARN + AWS_WEB_IDENTITY_TOKEN_FILE (env vars EKS injects) automatically through the container credential provider — step 11 of the default provider chain per the boto3 docs.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: chiron-workload
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/chiron-workload

Lambda / App Runner take a role ARN at deploy time. The runtime hands the SDK temp creds through EC2's instance-metadata service (169.254.169.254), step 12 of the chain:

aws lambda update-function-configuration \
  --function-name chiron-demo-fn \
  --role arn:aws:iam::123456789012:role/chiron-lambda

SDK snippet — the same three lines everywhere

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

# Local: reuses `az login`. In-cloud: uses managed identity.
credential = DefaultAzureCredential()
client = SecretClient(vault_url="https://my-vault.vault.azure.net",
                      credential=credential)

DefaultAzureCredential walks its credential chain: Env → Workload identity → Managed identity → Azure CLI → …

from google.auth import default
from google.cloud import storage

# Local: reads ~/.config/gcloud/application_default_credentials.json
# In-cloud: uses the attached service-account metadata endpoint.
credentials, project = default()
client = storage.Client(credentials=credentials, project=project)

default() follows the ADC precedence: GOOGLE_APPLICATION_CREDENTIALS → local ADC file → attached service account (metadata server).

import boto3

# Local: reads ~/.aws/{config,credentials}.
# In-cloud: IRSA (EKS), instance profile (EC2), or Lambda role.
client = boto3.client("s3")

boto3.client("s3") walks the 12-step default credential provider chain — no arguments needed for the workload-identity paths.

Long-lived static keys — when to use them

Never for production. They rotate manually, land in every git diff if you're not careful, and don't audit-trail to a human. Use them only as a last resort in a legacy pipeline that can't yet do workload identity, and rotate on a schedule you control.

The three provider paths above (workload identity → managed identity → IRSA) each remove the static key from the picture entirely — the credentials the SDK sees are short-lived, auto-rotated, and scoped to the workload's assigned role.