Azure / Azure/azure-dev

azd pipeline config should detect restrictive org policies (EMU enterprises) and warn users

Open
#7,967 0 comments 0 reactions 0 assignees View on GitHub
area/pipeline engineering item engsys
Dominant language
Go
Stars
569
Forks
364
Avg merge
2d 19h
Merged PRs (30d)
136

Description

## Description

Microsoft EMU enterprises (and likely other restrictive enterprises) enforce policies that conflict with the workflows `azd pipeline config` generates and assumes. The OIDC subject mismatch fixed in #7374 / #7705 is one symptom of a bigger pattern: **`azd pipeline config` doesn''t know whether it''s running against a restrictive enterprise**, and so it can produce configurations that look right but fail at runtime.

We just lived through this on `coreai-microsoft/forge-chat` (Microsoft EMU). Full post-mortem: https://github.com/coreai-microsoft/forge-chat/blob/main/.status/ci-investigation-2026-04-29.md

## The two collisions we hit (and there are likely more)

### 1. OIDC subject claim format

Already fixed in #7705 — but worth treating as one example of a broader class.

### 2. Third-party GitHub Actions allow-list

EMU enterprises commonly enforce an **allow-list** of GitHub Actions: only `actions/*` (GitHub-owned), Azure-published (`Azure/*`), and a curated list of third-party Actions are permitted. Anything outside the allow-list causes the workflow to fail with `startup_failure` *before* any step runs.

`azd pipeline config` currently generates a workflow that uses `Azure/setup-azd@v2`, which IS allow-listed, so the azd-generated workflow itself doesn''t fail. **But it doesn''t warn the user that other workflows in their repo (e.g. CI, lint, test) are likely to fail if they use third-party Actions.** We hit this with `pnpm/action-setup@v4` in our CI workflow — 25+ failed runs before bisecting to it.

Worse, the failure mode is `startup_failure` with no diagnostic — the user has no way to know which `uses:` line is the culprit. We had to bisect by progressively reducing the workflow.

## Proposed solution: detect restrictive enterprises and warn

`azd pipeline config` should:

1. **Detect EMU / restrictive enterprises early.** Some signals that may help:
- Query the [GitHub Enterprise OIDC customization](https://docs.github.com/en/enterprise-cloud@latest/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-token-claims) settings (already done as of #7705 for OIDC subjects)
- Check the [allowed Actions / reusable workflows policy](https://docs.github.com/en/rest/actions/permissions?apiVersion=2022-11-28#get-allowed-actions-and-reusable-workflows-for-a-repository) at the repo, org, or enterprise level
- Check [GitHub Enterprise Cloud - EMU](https://docs.github.com/en/enterprise-cloud@latest/admin/identity-and-access-management/managing-iam-with-enterprise-managed-users/about-enterprise-managed-users) markers on the org

2. **Display an upfront banner** in `azd pipeline config` output if any restrictive policies are detected:
```
⚠️ This repo is in a restrictive enterprise. Detected:
• OIDC subject claim is customized — federated credentials will use immutable format
• Third-party Actions allow-list enforced — only `actions/*`, `Azure/*`, and approved actions allowed

azd-generated workflow will work, but any custom workflows you add to .github/workflows/
may need adaptation. See https://aka.ms/azd-emu-guide for details.
```

3. **Optionally generate an EMU-compatible CI workflow template** (instead of just `azure-dev.yml`) that uses corepack/built-in Node tooling rather than third-party Actions, so users have a working starting point.

4. **Document the EMU patch checklist** somewhere prominent (could be in the azd docs site or as part of the `azd pipeline config --help` output).

## Why this matters

EMU enterprises are growing — Microsoft has ~150k internal developers and many partner orgs run EMU-style enterprises with similar policies. Each developer hitting this issue spends 1–4 hours bisecting and debugging. That''s a meaningful drag on `azd` adoption inside enterprises.

Even better: the same detection logic could power similar warnings in the [Azure for GitHub Copilot](https://learn.microsoft.com/azure/developer/azure-github-copilot/) integration, the VS Code extension, and the docs.

## Workarounds (what we did)

Documented in our post-mortem above, but in summary:

1. Replace `pnpm/action-setup@v4` with `corepack enable && corepack prepare pnpm@9.15.4 --activate` (built into Node 22+, allow-listed implicitly).
2. Manually add immutable-format FICs alongside the path-based ones azd creates (or, post #7705 merge + release, the new behavior should handle this).

## Environment

- azd version: `setup-azd@v2` (latest stable)
- Repo: `coreai-microsoft/forge-chat` (Microsoft EMU enterprise, internal visibility)
- Tenant: `microsoft.onmicrosoft.com`

## Related

- #7374 — OIDC subject claim mismatch (fixed in #7705)
- #7551 — Initial PR for OIDC fix (superseded by #7705)
- #5473 — Similar AADSTS700213 from GitHub environments

cc @vhvb1989 @wbreza — happy to contribute a PR for any of the above if it''d be useful.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.