Azure Credentials

Azure Credentials

An azure deploy environment collects an ARM service principal: three identifiers and one secret. All three identifiers are GUIDs, they look alike, and putting one in the wrong box produces an authentication error that names none of them — so this page is mostly about telling them apart.

Perhatian

Check which target actually deploys before you create a service principal. In the admin console today only the greentic_cloud target has a working deploy pipeline; an azure environment stores what you enter but a deploy attempt is refused with “this target’s deploy pipeline has been retired”. See Cloud Deploy Environments.

The fields

Field	Environment variable	What it identifies
Subscription ID	ARM_SUBSCRIPTION_ID	the billing container the resources are created in
Tenant ID	ARM_TENANT_ID	your Entra ID directory — the organisation
Client ID	ARM_CLIENT_ID	the application (service principal) that signs in
Client secret	ARM_CLIENT_SECRET	that application’s password

The first three are GUIDs — 8-4-4-4-12 hex, for example 3f2504e0-4f89-11d3-9a0c-0305e82c3301. The client secret is not a GUID: it is a longer opaque string, and Azure shows it once.

Tips

The single commonest mistake is pasting the client secret’s Secret ID — which is a GUID, and sits right next to the value in the portal — instead of the secret Value. If your secret looks like a GUID, you copied the wrong column.

Creating the service principal

The one-command route gives you every value at once:

az ad sp create-for-rbac \
  --name greentic-deployer \
  --role Contributor \
  --scopes /subscriptions/00000000-0000-0000-0000-000000000000

It prints:

{
  "appId": "…",
  "displayName": "greentic-deployer",
  "password": "…",
  "tenant": "…"
}

Map it as:

Output	Field
appId	Client ID
password	Client secret
tenant	Tenant ID
the --scopes subscription	Subscription ID

password is printed once and is not retrievable afterwards.

Your subscription ID, if you do not have it to hand:

az account show --query id --output tsv

Through the portal

1. Entra ID → App registrations → New registration. Name it, leave the redirect URI blank, register.

2. On the overview page, copy Application (client) ID and Directory (tenant) ID.

3. Certificates & secrets → Client secrets → New client secret. Pick an expiry, then copy the Value column — not Secret ID.

4. Subscriptions → your subscription → Access control (IAM) → Add role assignment. Assign the role your deploy needs to the app you just registered, and copy the subscription ID from the subscription overview.

Which role?

Contributor on the target subscription or resource group is the usual starting point and is what az ad sp create-for-rbac grants by default. It is broad — it can create and delete anything in scope except role assignments.

Greentic does not publish a minimum Azure role definition, and this page will not invent one: the Azure deploy lineage in the admin console has been retired, so there is no live pipeline whose calls could be enumerated into a role that is actually correct. Scope the assignment to a single resource group rather than the whole subscription if you want to limit the blast radius.

Alternatives to a client secret

The deployer also recognises Azure OIDC — workload identity federation, where the runner exchanges a short-lived OIDC token instead of holding a secret. It uses ARM_USE_OIDC=true with ARM_CLIENT_ID, ARM_TENANT_ID and ARM_SUBSCRIPTION_ID (or the AZURE_-prefixed equivalents). The admin console’s environment form collects the client-secret style only; the OIDC style is available when you run a deploy yourself with the environment set.

Rotating

Secrets expire — Azure caps a client secret’s lifetime, and an expired secret fails with the same unhelpful error as a wrong one. Add the new secret before removing the old:

az ad app credential reset --id <appId> --append

Then update the environment and delete the superseded credential.

See also

• Cloud Deploy Environments
• Google Cloud Credentials
• AWS Credentials