entra-workload-identity

Name: entra-workload-identity
Author: vinayaklatthe

161stars34forks

How to install entra-workload-identity?

vinayaklatthe/microsoft-security-skills/entra-workload-identity

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill entra-workload-identity

Installs into the current project.

Summary

Guidance for Microsoft Entra workload identities — managed identities, service principals, and workload identity federation. Covers system-assigned vs user-assigned managed identity, federated credentials (GitHub Actions, Azure DevOps, Kubernetes, other OIDC issuers) to eliminate

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Entra Workload Identity
2
3	Workload identities are the non-human identities that apps, services, scripts, and
4	pipelines use to access Microsoft Entra-protected resources. They are the #1 source of
5	cloud breach in recent post-incident reports — usually because of leaked client secrets,
6	over-privileged service principals, or unmanaged certificate expiry.
7
8	This skill covers picking the right identity type, eliminating secrets via federation,
9	hardening service principals, and applying Workload Identities Premium controls.
10
11	## When to use
12	Designing how an Azure resource, GitHub Action, Azure DevOps pipeline, AKS pod, or
13	external workload authenticates to Entra-protected APIs (Azure Resource Manager,
14	Microsoft Graph, Key Vault, Storage, etc.).
15
16	Do not use this skill for human identity (`entra-id`), multi-cloud entitlement
17	analysis (`entra-permissions-management`), or AI agent identity governance specifically
18	(`agent-identity-governance`).
19
20	## Pick the right identity
21
22	\| Workload \| Best identity \|
23	\|---\|---\|
24	\| Azure-hosted resource (App Service, Function, VM, AKS pod, Container Apps) \| Managed identity (system-assigned if 1:1, user-assigned if shared / lifecycle decoupled) \|
25	\| GitHub Actions / GitLab CI / Azure DevOps / Jenkins \| Workload identity federation to a user-assigned MI or app registration \|
26	\| Workload outside Azure with an OIDC issuer (Kubernetes, AWS, GCP) \| Workload identity federation \|
27	\| Legacy on-prem service with no OIDC \| App registration with certificate (never secret) \|
28	\| Anything authenticating to Microsoft Graph only \| App registration + federation/cert \|
29
30	> Rule of thumb: if a client secret is in your design doc, you missed a federation
31	> opportunity. Start by trying federation; fall back to certificates; never client
32	> secrets for new builds.
33
34	## Approach
35
36	1. Inventory existing service principals and credentials. Use Microsoft Graph
37	(`servicePrincipals`, `applications`) to list every app reg, its key/secret
38	credentials, expiry dates, and assigned roles. Most tenants find expired secrets,
39	ten-year-old test apps, and unowned admin-consented apps.
40
41	2. Eliminate secrets where federation works:
42	- GitHub Actions → Azure: configure a federated credential on a user-assigned MI
43	(or app reg) with subject `repo:org/repo:environment:prod`. No secret in GitHub.
44	- AKS workload identity: enable on cluster, annotate service account, project the
45	token; pod authenticates as the user-assigned MI it's bound to.
46	- Azure DevOps: use the Workload Identity federation service connection.
47	- External OIDC issuer (GCP, AWS, Okta): add federated credential with the
48	issuer URL and subject claim.
49
50	3. Where you must keep a credential, use a certificate rotated by Key Vault, not a
51	client secret. Set short expiries (≤180 days) and automate rotation.
52
53	4. Apply least-privilege RBAC. Default to scoped role assignments at the resource
54	or RG level — never Subscription Owner unless justified. Avoid Microsoft Graph
55	`.All` permissions (e.g., `Files.ReadWrite.All`) when scoped or per-app-collection
56	permissions exist (Sites.Selected, Mail.Send specific mailboxes via app access
57	policy).
58
59	5. Workload Identities Premium (separate SKU). Unlocks:
60	- Conditional Access for workloads — block service principal sign-ins from
61	unexpected IP ranges, require named locations, restrict by client app.
62	- Workload identity risk detection — leaked credentials, anomalous sign-in,
63	suspicious admin activity.
64	- Access reviews for workload identities — periodic owner review of SP roles.
65	Apply to externally-facing or high-privilege workload identities; doesn't need to
66	be every SP in the tenant.
67
68	6. *

People who liked this also viewed

6 picks

Type

entra-workload-identity

161stars34forks

View on GitHub

How to install entra-workload-identity?

vinayaklatthe/microsoft-security-skills/entra-workload-identity

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill entra-workload-identity

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Entra Workload Identity
2
3	Workload identities are the non-human identities that apps, services, scripts, and
4	pipelines use to access Microsoft Entra-protected resources. They are the #1 source of
5	cloud breach in recent post-incident reports — usually because of leaked client secrets,
6	over-privileged service principals, or unmanaged certificate expiry.
7
8	This skill covers picking the right identity type, eliminating secrets via federation,
9	hardening service principals, and applying Workload Identities Premium controls.
10
11	## When to use
12	Designing how an Azure resource, GitHub Action, Azure DevOps pipeline, AKS pod, or
13	external workload authenticates to Entra-protected APIs (Azure Resource Manager,
14	Microsoft Graph, Key Vault, Storage, etc.).
15
16	Do not use this skill for human identity (`entra-id`), multi-cloud entitlement
17	analysis (`entra-permissions-management`), or AI agent identity governance specifically
18	(`agent-identity-governance`).
19
20	## Pick the right identity
21
22	\| Workload \| Best identity \|
23	\|---\|---\|
24	\| Azure-hosted resource (App Service, Function, VM, AKS pod, Container Apps) \| Managed identity (system-assigned if 1:1, user-assigned if shared / lifecycle decoupled) \|
25	\| GitHub Actions / GitLab CI / Azure DevOps / Jenkins \| Workload identity federation to a user-assigned MI or app registration \|
26	\| Workload outside Azure with an OIDC issuer (Kubernetes, AWS, GCP) \| Workload identity federation \|
27	\| Legacy on-prem service with no OIDC \| App registration with certificate (never secret) \|
28	\| Anything authenticating to Microsoft Graph only \| App registration + federation/cert \|
29
30	> Rule of thumb: if a client secret is in your design doc, you missed a federation
31	> opportunity. Start by trying federation; fall back to certificates; never client
32	> secrets for new builds.
33
34	## Approach
35
36	1. Inventory existing service principals and credentials. Use Microsoft Graph
37	(`servicePrincipals`, `applications`) to list every app reg, its key/secret
38	credentials, expiry dates, and assigned roles. Most tenants find expired secrets,
39	ten-year-old test apps, and unowned admin-consented apps.
40
41	2. Eliminate secrets where federation works:
42	- GitHub Actions → Azure: configure a federated credential on a user-assigned MI
43	(or app reg) with subject `repo:org/repo:environment:prod`. No secret in GitHub.
44	- AKS workload identity: enable on cluster, annotate service account, project the
45	token; pod authenticates as the user-assigned MI it's bound to.
46	- Azure DevOps: use the Workload Identity federation service connection.
47	- External OIDC issuer (GCP, AWS, Okta): add federated credential with the
48	issuer URL and subject claim.
49
50	3. Where you must keep a credential, use a certificate rotated by Key Vault, not a
51	client secret. Set short expiries (≤180 days) and automate rotation.
52
53	4. Apply least-privilege RBAC. Default to scoped role assignments at the resource
54	or RG level — never Subscription Owner unless justified. Avoid Microsoft Graph
55	`.All` permissions (e.g., `Files.ReadWrite.All`) when scoped or per-app-collection
56	permissions exist (Sites.Selected, Mail.Send specific mailboxes via app access
57	policy).
58
59	5. Workload Identities Premium (separate SKU). Unlocks:
60	- Conditional Access for workloads — block service principal sign-ins from
61	unexpected IP ranges, require named locations, restrict by client app.
62	- Workload identity risk detection — leaked credentials, anomalous sign-in,
63	suspicious admin activity.
64	- Access reviews for workload identities — periodic owner review of SP roles.
65	Apply to externally-facing or high-privilege workload identities; doesn't need to
66	be every SP in the tenant.
67
68	6. *

People who liked this also viewed

6 picks

Type