It solves one important problem:

How does the workload authenticate?

It does not automatically solve another equally important problem:

What can that workload do after authentication succeeds?

That distinction became the central security question behind my AZ-01 Azure Workload Identity Security Lab.

I wanted to build something more substantial than a Terraform deployment that simply demonstrated GitHub OIDC. Instead, I designed the project as a complete security-engineering lifecycle:

Vulnerable workload identity
        ↓
Controlled credential compromise
        ↓
Authorization blast-radius testing
        ↓
Evidence capture
        ↓
Secretless identity redesign
        ↓
Azure RBAC reduction
        ↓
Post-remediation re-attack
        ↓
Explicit positive + negative validation
        ↓
Terraform teardown
        ↓
Cleanup verification
        ↓
CI/CD and repository hardening

The result was an evidence-driven Azure security lab using Microsoft Entra ID, Azure RBAC, Terraform, GitHub Actions, GitHub OIDC, Azure Storage, PowerShell, and Trivy.

The environment used only synthetic data and project-owned Azure resources. Nothing in this project should be interpreted as production penetration testing, universal least-privilege proof, or broad Azure security assurance. Every test was deliberately bounded.

The security problem I wanted to model

Workload identities are everywhere.

Applications, automation platforms, CI/CD pipelines, infrastructure tooling, and background services all need to authenticate to cloud APIs.

Historically, one common approach has been:

Application
    ↓
Client ID + client secret
    ↓
Microsoft Entra service principal
    ↓
Azure RBAC
    ↓
Azure resources

The architecture works.

The problem is the credential lifecycle.

A persistent client secret is replayable. If it is copied from a CI/CD system, exposed through logging, committed accidentally, leaked from configuration, or extracted from another trusted system, an attacker may be able to authenticate as that workload until the credential expires or is revoked.

But authentication is only half of the problem.

Suppose the compromised workload identity also has excessive authorization.

Now the attack becomes:

Credential compromise
        +
Excessive Azure RBAC
        =
Larger authorization blast radius

That was the condition I wanted AZ-01 to demonstrate.

Building a deliberately vulnerable baseline

The first meaningful version of the lab intentionally contained a vulnerable Microsoft Entra workload identity.

The identity had a temporary persistent credential and broader permissions than the workload ultimately required.

I also created two important boundaries:

Workload Resource Group
        |
        +-- workload resources
        +-- private synthetic storage
        +-- authorized test targets

Negative-Control Resource Group
        |
        +-- benign project-owned canary
        +-- NO workload role assignment

The negative control was critical.

Without one, successful access only proves what the compromised identity can reach.

A negative control also tests something it should not reach.

That distinction gave me a concrete authorization boundary rather than relying on assumptions.

Phase 3: Controlled credential-compromise validation

I did not want the attack phase to become arbitrary Azure enumeration.

The tests were restricted to known project-owned resources and synthetic data.

The Phase 3 test matrix was:

The management-plane mutation was deliberately harmless and its original state was restored after testing.

AT-01 — The copied credential worked

The first test answered the most fundamental question:

If an attacker possesses the intentionally exposed workload credential, can it actually authenticate?

The answer was yes.

The Azure CLI session successfully authenticated as the vulnerable service principal.

That established the identity-compromise condition required for every subsequent test.

This result alone did not prove an authorisation problem.

It only proved:

Authentication = compromised

The next tests investigated authorisation.

AT-02 — Resource-group enumeration succeeded

The compromised workload identity could enumerate resources inside the dedicated workload resource group.

That demonstrated management-plane visibility inside the assigned authorisation boundary.

Importantly, I did not expand the test into arbitrary subscription enumeration.

The objective was to measure this identity's permissions against known targets, not discover unrelated Azure infrastructure.

AT-03 — A management-plane mutation succeeded

Next, I wanted a stronger signal than read-only enumeration.

The identity attempted a benign tag modification against a project-owned workload resource.

The mutation succeeded.

After validating the behaviour, the original tag state was restored and verified.

This was significant because the blast radius was no longer theoretical.

The compromised workload credential could authenticate and exercise an authorisation path capable of modifying workload infrastructure.

AT-04 — Synthetic data access succeeded

The workload was also deliberately granted access to known synthetic Azure Storage data.

Using the compromised identity, access to that known blob succeeded.

Again, the point was not to collect data.

The point was to answer:

Does credential possession expose the data-plane permissions already granted to this workload?

Yes.

AT-05 — The negative control was denied

Then came one of the most valuable results in the lab.

The same compromised identity attempted to access a benign canary in the separate negative-control resource group.

The request was denied.

This prevented an important overstatement.

The correct interpretation was not:

“The credential compromise gave access to Azure.”

It was:

“The credential compromise exposed the permissions already assigned to that workload identity within the tested authorization boundary.”

That is a much more defensible security conclusion.

What the vulnerable tests actually demonstrated

The Phase 3 attack taught an important lesson:

Authentication compromise and authorisation blast radius are separate controls

A stolen client secret answers:

Who can authenticate as this workload?

Azure RBAC answers:

What can the authenticated workload do?

You can therefore have several combinations:

Strong authentication + excessive RBAC = still dangerous

Weak authentication + narrow RBAC = compromised identity,
                                     but reduced blast radius

Strong authentication + narrow RBAC = preferred design

This meant my remediation needed two separate changes.

I had to:

1. eliminate the persistent workload credential; and

2. reduce the workload's Azure authorization.

Fixing only one would have left the architecture incomplete.

Remediation: moving to GitHub OIDC federation

The vulnerable Phase 2/3 Azure environment was destroyed after its evidence was captured.

For the remediation tests, I created a fresh validation deployment.

This detail matters.

AZ-01 does not claim that I mutated the original identity in place and proved the old Phase 3 secret could no longer authenticate.

The preserved Phase 3 deployment and the later Phase 4/5 deployment represent different validation windows.

The remediated authentication architecture became:

GitHub Actions
      ↓
GitHub-issued OIDC token
      ↓
Microsoft Entra federated identity credential
      ↓
Workload service principal
      ↓
Azure RBAC
      ↓
Authorized Azure resource

There is no persistent Azure workload client secret in this path.

How the federation trust was constrained

The Microsoft Entra application trusts GitHub through a federated identity credential.

Conceptually, the Terraform looks like this:

resource "azuread_application_federated_identity_credential" "github_main" {
  application_id = azuread_application.workload.id

  display_name = "az01-github-main-oidc"

  audiences = [
    "api://AzureADTokenExchange"
  ]

  issuer = "https://token.actions.githubusercontent.com"

  subject = "<reviewed repository identity>:ref:refs/heads/main"
}

The important security property is the subject restriction.

The trust is not intended to cover arbitrary repositories, pull requests, branches, tags, or an entire GitHub organization.

The reviewed federation boundary is tied to the intended repository identity and main branch.

Publishing the trust tuple does not provide a credential. Authentication still requires a valid GitHub-issued OIDC token that satisfies the configured trust conditions.

Authentication hardening was not enough

OIDC removed the persistent workload-secret problem.

But I still needed to address authorization.

The workload did not need broad management-plane control.

Its legitimate function was much narrower:

Read the intended synthetic data from one known Azure Storage container.

So the remediated RBAC assignment became container-scoped:

resource "azurerm_role_assignment" "workload_synthetic_data_reader" {
  scope                = azurerm_storage_container.synthetic_data.id
  role_definition_name = "Storage Blob Data Reader"
  principal_id         = azuread_service_principal.workload.object_id
}

The workload had no corresponding Contributor assignment, management-plane Reader assignment, storage-write role, storage-owner role, or negative-control resource-group assignment in the remediated Terraform.

This was the key architectural transition:

Now I needed to prove the new behavior at runtime.

Phase 4: Proving the OIDC positive path

A configuration that looks correct is not sufficient evidence.

I created a manual GitHub Actions validation workflow and used it to test the new identity.

The workflow successfully:

GitHub Actions
      ↓
Obtained GitHub OIDC token
      ↓
Exchanged token with Microsoft Entra
      ↓
Authenticated Azure CLI
      ↓
Accessed metadata for exact known synthetic blob
      ↓
Cleaned up Azure CLI session

The workflow deliberately validated metadata access, rather than printing the blob contents.

The Phase 4 run verified OIDC authentication, the intended metadata-only synthetic-blob access, and CLI cleanup.

It did not claim that management-plane or write operations were denied. Those checks were reserved for Phase 5.

At this point I had established:

Secretless authentication: PASS
Intended read path:         PASS

But I still had not proved least-privilege behavior.

That required re-attacking the remediated identity.

Phase 5: Re-attacking the remediated workload identity

This was arguably the most important phase of AZ-01.

Many security projects stop here:

Terraform changed
        ↓
OIDC enabled
        ↓
Project complete

I wanted the opposite.

The remediation needed to survive controlled authorization tests.

The final post-remediation matrix was:

These are bounded runtime observations, not universal Azure permission claims.

Positive controls mattered

One subtle design decision was to keep a positive control inside the authorization tests.

Suppose a command fails.

Without a positive control, several explanations are possible:

Expected RBAC denial
Network failure
Authentication failure
Wrong resource
Broken workflow
Wrong Azure context
CLI failure

Those are not equivalent.

So the tests repeatedly confirmed that:

OIDC authentication works
        +
Known permitted access works
        +
Specific excessive operation receives authorization denial

That gives much stronger evidence that the negative result came from the intended authorization boundary rather than a broken test environment.

Explicit denial classification

I also avoided treating every failure as a security success.

A generic failure or ambiguous HTTP response was not automatically classified as PASS.

For denial tests, the workflow expected explicit Azure authorization-denial behavior.

If an operation unexpectedly succeeded, the test was a failure.

If the result was ambiguous, it was not enough to claim enforcement.

This distinction prevents one of the easiest mistakes in security testing:

Interpreting “command failed” as “security control worked.”

RT-02 — Resource enumeration denied

The remediated workload attempted the resource-list operation against the known workload resource group.

It received an explicit authorization denial.

The same capability that had succeeded during the vulnerable baseline was no longer available to the tested identity.

RT-03 — Management-plane mutation denied

The benign tag-mutation probe was then executed separately.

It received an explicit authorization denial.

The claim here is intentionally narrow:

The tested tag mutation against the known workload resource group was denied.

Not:

The identity can never perform any Azure management-plane action anywhere.

RT-04R — Required access still worked

Least privilege should not mean “nothing works.”

The exact known synthetic blob metadata path still succeeded through Microsoft Entra authentication.

That proved the remediation preserved the workload's legitimate function.

Required read access → PASS

RT-04W — Storage write denied

The next test attempted to create a dedicated synthetic write-probe blob.

It received an explicit authorization denial.

The original baseline synthetic blob was never overwritten.

Again, this does not prove every possible storage write API would fail.

It proves the exact tested write action was denied against the known target.

RT-05 — Negative control still denied

The project-owned canary remained inaccessible.

This gave me a useful comparison across both security states:

Vulnerable deployment:
Compromised identity → negative control DENIED

Remediated deployment:
Federated identity → negative control DENIED

The negative control continued to establish a known boundary outside the workload's intended authorization scope.

RT-06 — Account-level container listing denied

Finally, account-level container enumeration against the known workload storage account received an explicit authorization denial.

Meanwhile, the narrower known synthetic blob metadata path continued to work.

That contrast illustrates the outcome I wanted:

Known required operation
        → allowed

Broader tested operation
        → denied

Why I ran mutation tests separately

RT-03 and RT-04W were opt-in mutation probes.

They were never enabled together.

That was deliberate.

Running mutation tests one at a time reduces uncertainty if something unexpected succeeds and makes cleanup responsibility much clearer.

The Phase 5 evidence therefore consolidates multiple dispatches rather than pretending all tests occurred in one giant workflow run.

That may sound like a small procedural detail, but it reflects an important security-testing principle:

Reduce the blast radius of the test harness itself.

Phase 6: Hardening the repository and CI/CD path

Cloud runtime security was only part of the project.

Once the validated Terraform became the project baseline, I wanted the repository itself to resist accidental regression.

I added a static security CI pipeline with three required checks:

The Terraform path executes:

terraform fmt -check -recursive
terraform init -backend=false
terraform validate

There is intentionally no:

terraform plan
terraform apply
terraform destroy
Azure login
OIDC token request

The static CI pipeline does not need to recreate the Azure environment.

Its GitHub Actions permission is restricted to:

permissions:
  contents: read

Checkout does not persist credentials, external actions are pinned to reviewed commit SHAs, and scanner reports remain in runner-temporary storage rather than being uploaded with potentially sensitive context.

A scanner finding I chose not to hide

One of the more useful engineering moments happened when the IaC scan identified AZU-0012 around storage public-network reachability.

It would have been easy to suppress the finding just to make CI green.

Instead, I treated it as a design decision.

The lab needed the synthetic storage endpoint reachable during its bounded validation window from owner-controlled systems and GitHub-hosted runners.

Compensating controls included:

Shared-key authentication disabled
OAuth-based authentication
TLS 1.2 minimum
Private container
Synthetic data only
Destroyed validation environment

Rather than making an unrelated infrastructure change purely to satisfy the scanner, I documented a narrow, time-bounded exception expiring on December 31, 2026.

All other unexcepted HIGH/CRITICAL findings remain fail-closed.

That is closer to real security engineering than pretending every scanner finding can be solved by blindly changing configuration.

Then I deliberately broke CI

A green pipeline proves the success path.

It does not prove the pipeline will reject anything.

So I introduced CF-01, a controlled CI failure.

The test created a valid but deliberately misformatted Terraform fixture only under the GitHub runner's temporary directory.

The sequence was:

Normal Terraform checks → PASS

Create temporary misformatted fixture
        ↓
terraform fmt -check
        ↓
REJECTED as expected
        ↓
terraform fmt
        ↓
Remediated
        ↓
terraform fmt -check
        ↓
PASS
        ↓
Delete temporary fixture
        ↓
Verify cleanup
        ↓
Intentionally fail controlled run

The controlled workflow failed exactly as intended.

Then the temporary failure-injection logic was removed, the normal workflow was restored, and all three production CI jobs passed again.

This gave me something more meaningful than:

“My CI pipeline is green.”

I could instead say:

“I deliberately exercised one known negative path, observed the gate reject it, remediated the condition, and revalidated the production pipeline.”

Protecting the validated baseline

The final repository-hardening phase added or verified:

• pull requests required for main;

• conversation resolution;

• all three security CI jobs required;

• required branches kept current with the protected baseline;

• force-push protection;

• branch-deletion protection;

• read-only default GitHub Actions permissions;

• GitHub Actions PR approval disabled;

• historical Phase 4/5 Azure OIDC workflows disabled;

• stale runtime repository variables removed;

• weekly Dependabot visibility retained;

• major dependency/provider changes kept behind explicit compatibility review.

A particularly important choice was to disable historical runtime workflows rather than delete or rewrite them.

Their source remains available as engineering provenance.

Their execution path is retired.

That preserves history without leaving unnecessary Azure authentication automation active.

Phase 7: Destroying the environment was part of the project

I do not consider an ephemeral security lab complete because terraform destroy returned success.

The cleanup itself needed validation.

After Phase 5 evidence was reviewed, the later secretless validation environment was destroyed.

The teardown matrix was:

The checks were limited to exact known project-owned resources.

They do not claim universal subscription cleanup.

The final cloud state is therefore simple:

Live AZ-01 Azure validation environment: NONE

Persistent workload client secret:       NOT RECREATED

Historical runtime OIDC workflows:        DISABLED

Protected static CI baseline:             ACTIVE

Evidence hygiene mattered throughout

Security labs have an uncomfortable property:

The most interesting output is often exactly what should not be published.

So the public repository intentionally excludes credential values, tokens, Terraform state and plan files, Azure CLI caches, raw authentication logs, and sensitive runtime identifiers.

Screenshots were captured and sanitized before publication.

Raw GitHub Actions authentication logs were also intentionally not copied into the repository because expanded workflow context can contain values that are unnecessary for demonstrating the result.

The goal was:

Enough evidence to support the claim

but

Not enough sensitive runtime material to create a new problem

What AZ-01 taught me

The biggest lesson was not simply:

“GitHub OIDC is better than client secrets.”

That is true, but incomplete.

The deeper lesson was:

Authentication architecture and authorization architecture must be engineered independently and then tested together.

OIDC reduced the credential-lifecycle risk.

Container-scoped Azure RBAC reduced the authorization blast radius.

Runtime testing verified the tested behavior.

Negative controls helped prevent exaggerated conclusions.

Positive controls prevented broken test environments from masquerading as successful security enforcement.

Controlled mutation testing demonstrated real authorization behavior without turning the lab into destructive testing.

Static CI protected the resulting source baseline.

Controlled CI failure validated one enforcement path.

Teardown verification completed the cloud-resource lifecycle.

And evidence hygiene made the results publishable without preserving sensitive runtime material.

What this project does not prove

Being precise about the limitations is just as important as documenting the successful tests.

AZ-01 does not claim:

Universal Azure least privilege
Universal authorization denial
Production readiness
Old-secret replay failure
In-place Phase 3 credential revocation
Arbitrary storage-read denial
Universal storage-write denial
Subscription-wide cleanup
Clean full Git history
Penetration-testing coverage

Phase 3 and the secretless Phase 4/5 environment were separate deployment windows.

The tested denials apply to the exact actions and known project-owned targets exercised by the lab.

Blob metadata access does not imply unrestricted content access.

Current-content secret scanning does not establish that every historical Git revision has always been clean.

Static Terraform and IaC checks do not replace Azure runtime authorization testing.

Those limitations do not weaken the project.

They make the claims defensible.

Final architecture

The project began with:

Long-lived workload credential
        ↓
Microsoft Entra service principal
        ↓
Excessive bounded Azure RBAC
        ↓
Credential compromise
        ↓
Authorized excessive operations

It finished with:

GitHub Actions
        ↓
Short-lived GitHub OIDC token
        ↓
Microsoft Entra workload identity federation
        ↓
Workload service principal
        ↓
Container-scoped Storage Blob Data Reader
        ↓
Required access succeeds
        +
Tested excessive actions explicitly denied

And around that cloud architecture now sits a repository control plane:

Pull Request
     ↓
Terraform validation
     +
IaC scanning
     +
Secret scanning
     ↓
Required checks
     ↓
Protected main

That complete lifecycle is what made AZ-01 valuable to me.

It was not just an OIDC implementation.

It was an exercise in attack-path reasoning, identity architecture, authorization design, security validation, evidence engineering, DevSecOps controls, and teardown discipline.

Final project state

AZ-01 is now closed as a synthetic, evidence-driven Azure workload-identity security lab.

The vulnerable baseline is preserved as historical evidence.

The later OIDC architecture was validated.

The tested authorization boundary was re-attacked.

The Azure validation environment was destroyed.

The long-lived workload client secret was not recreated.

Historical Azure runtime workflows are disabled.

The validated Terraform baseline is protected by repository-static security controls.

You can review the complete implementation, evidence, Terraform, architecture decisions, and validation records here:

GitHub: nagasesank/AZ-01-azure-workload-identity-security-lab

If you are designing CI/CD identities in Azure, the main takeaway I would leave you with is this:

Removing secrets improves authentication security. Reducing permissions improves authorization security. Testing both is what turns the design into evidence.

Technology stack

Microsoft Azure · Microsoft Entra ID · Azure RBAC · Terraform · GitHub Actions · GitHub OIDC · Azure Storage · PowerShell · Trivy

About this project

AZ-01 is a controlled cloud-security engineering lab built with synthetic data and project-owned resources only. The repository preserves the implementation and evidence, while the Azure validation environment itself has been destroyed after testing.