Configure Azure Secrets for CI/CD

This document explains why Azure-specific secrets are required in the CI/CD pipeline and provides clear, step-by-step instructions to create and configure each one correctly.

These secrets enable your GitHub Actions workflow to:

Authenticate to Azure using OIDC (no passwords or client secrets)
Push container images to Azure Container Registry (ACR)
Deploy services to Azure Container Apps (ACA)

🧩 Inputs

Environment

GitHub Org

Service Repo

Product Short Form

Domain (optional)

Overview: Azure secrets used in the pipeline

Your CI/CD pipeline uses the following Azure-related repository secrets:

Secret Name	Purpose
`AZURE_DEV_CLIENT_ID`	Identifies the Azure AD App Registration used by CI for this environment
`AZURE_TENANT_ID`	Identifies your Azure Active Directory tenant
`AZURE_SUBSCRIPTION_ID`	Identifies the Azure subscription where resources live

These secrets are consumed by the azure/login@v2 GitHub Action using OIDC authentication.

Why we use Azure OIDC (Important)

Your pipeline does NOT use:

Azure client secrets
Azure passwords
Long-lived credentials

Instead, it uses OpenID Connect (OIDC), which provides:

Short-lived access tokens
No stored secrets in GitHub
Automatic token rotation
Strong security and auditability

This is the Microsoft-recommended best practice for GitHub Actions → Azure authentication.

Secret 1 — AZURE_DEV_CLIENT_ID

What this is

AZURE_DEV_CLIENT_ID is the Application (client) ID of an Azure AD App Registration that:

Trusts GitHub Actions via OIDC
Has permission to deploy Azure resources

Each environment (dev, qa, prod) should have its own App Registration and Client ID.

How this secret is used in the pipeline

- uses: azure/login@v2
  with:
    client-id: ${{ env.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

At runtime, the workflow selects the correct client ID based on the branch:

dev → AZURE_DEV_CLIENT_ID
qa → AZURE_QA_CLIENT_ID
prod → AZURE_PROD_CLIENT_ID

How to create and fetch AZURE_DEV_CLIENT_ID

Create an App Registration

Go to the Azure Portal and navigate to:

Azure Active Directory → App registrations → New registration

Set:

Name: se-ci-dev-app
Supported account types: Single tenant
Redirect URI: Leave empty

Click Register.

Copy the Client ID

After creation:

Open the App Registration
Copy the value labeled:

Application (client) ID

This value becomes:

AZURE_DEV_CLIENT_ID

Add GitHub OIDC federation

In the App Registration, navigate to:

Certificates & secrets → Federated credentials → Add credential

Configure:

Federated credential scenario: GitHub Actions deploying Azure Resources
Organization:
```
ShelveraApp
```
Repository:
```
se-gw-srvc
```
Entity type:
```
branch
```
GitHub branch name:
```
dev
```
(Credential details) Name:
```
creds-se-gw-srvc-dev-branch
```

This allows GitHub Actions to authenticate without storing secrets.

Assign Azure roles

Assign the required Azure roles to the App Registration used by CI/CD.

a. Assign AcrPush role (for pushing images to ACR)

Go to the Azure Portal.

Navigate to:

dev-se-resource-group → devseacr → Access control (IAM)

Click:
```
Add role assignment
```
Under Job function roles, select:
- AcrPush
Click Next.
Under Select members, search for:
```
se-ci-dev-app
```
Select se-ci-dev-app.
Click Next.
Click:
```
Review + assign
```

b. Assign Contributor role (for Azure Container Apps deployment)

Navigate to:

dev-se-resource-group → Access control (IAM)

Click:
```
Add role assignment
```
Under Privileged administrator roles, select:
- Contributor
Click Next.
Under Select members, search for:
```
se-ci-dev-app
```
Select se-ci-dev-app.
Click Next.
Click:
```
Review + assign
```

✅ Result: CI/CD can push Docker images to ACR and deploy/manage Azure Container Apps. OIDC login via azure/login@v2 will work correctly.

Save as a GitHub repository secret

In GitHub:

Repository → Settings
Secrets and variables → Actions
Add a new secret:

Name: AZURE_DEV_CLIENT_ID
Value: <Client ID copied earlier>

Secret 2 — AZURE_TENANT_ID

What this is

AZURE_TENANT_ID identifies your Azure Active Directory tenant. This value is shared across all environments.

How to fetch AZURE_TENANT_ID

Go to Azure Portal and navigate to:

Azure Active Directory → Overview

Copy:

Tenant ID

Save as GitHub secret

Name: AZURE_TENANT_ID
Value: <Tenant ID>

Secret 3 — AZURE_SUBSCRIPTION_ID

What this is

AZURE_SUBSCRIPTION_ID identifies the Azure subscription where:

Azure Container Registry lives
Azure Container Apps are deployed
Resource Groups exist

How to fetch AZURE_SUBSCRIPTION_ID

Go to Azure Portal and navigate to:

Subscriptions → Select your subscription

Copy:

Subscription ID

Save as GitHub secret

Name: AZURE_SUBSCRIPTION_ID
Value: <Subscription ID>

Where these se-gw-srvc repository secrets are used (Summary)

Secret	Used By	Purpose
`AZURE_DEV_CLIENT_ID`	`azure/login@v2`	OIDC authentication
`AZURE_TENANT_ID`	`azure/login@v2`	Azure AD context
`AZURE_SUBSCRIPTION_ID`	`azure/login@v2`	Azure resource scope

Validation checklist

App Registration exists per environment
Federated credential added for repo + branch
Azure roles assigned (Contributor, AcrPush)
GitHub secrets added:
- AZURE_DEV_CLIENT_ID
- AZURE_TENANT_ID
- AZURE_SUBSCRIPTION_ID
azure/login@v2 step succeeds
ACR push succeeds
ACA deployment succeeds

Key takeaways

No Azure passwords or client secrets are stored
Authentication uses short-lived OIDC tokens
Each environment has isolated identities
This model scales cleanly as services grow

✅ This is the recommended, production-grade Azure CI/CD authentication setup.