azd pipeline config should detect restrictive org policies (EMU enterprises) and warn users
- 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
Assessment
This issue has not been assessed yet.