mcpField
E
entra-workload-identity

entra-workload-identity

github.com/vinayaklatthe安全17845 次安装19 周前更新
代码仓库

关于 entra-workload-identity

面向设计和管理访问 Microsoft Entra 资源的非人类身份的安全技能，指导身份类型选择、通过联合认证减少密钥、最小权限配置及生命周期管理。

主要功能

  1. 01选择托管身份或联合认证
  2. 02盘点服务主体与凭据
  3. 03用联合认证或证书替代客户端密钥
  4. 04按最小权限范围配置访问
  5. 05审查工作负载身份访问和登录

适用场景

  1. 01为 GitHub Actions 配置无密钥 Azure 访问
  2. 02将 AKS 工作负载迁移到工作负载身份
  3. 03审计即将过期的凭据和宽泛 Graph 权限
  4. 04监控异常的服务主体登录

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill entra-workload-identity

安装后在 Claude Code 中输入/entra-workload-identity确认已加载。

详细介绍

Microsoft Entra 工作负载身份

工作负载身份是应用、服务、脚本和流水线用于访问受 Microsoft Entra 保护资源的非人类身份。在近期的事后分析报告中，它们是云安全漏洞的首要来源，通常是因为客户端机密泄露、服务主体权限过高或证书过期无人管理。

此技能介绍如何选择合适的身份类型、通过联合身份验证消除机密、强化服务主体，以及应用 Workload Identities Premium 控制措施。

适用场景

设计 Azure 资源、GitHub Action、Azure DevOps 流水线、AKS Pod 或外部工作负载如何向受 Entra 保护的 API（Azure Resource Manager、Microsoft Graph、Key Vault、Storage 等）进行身份验证。

请勿将此技能用于人类身份（entra-id）、多云权限分析（entra-permissions-management），或专门针对 AI Agent 的身份治理（agent-identity-governance）。

选择合适的身份

工作负载最佳身份
Azure 托管资源（App Service、Function、VM、AKS Pod、Container Apps）托管身份（一对一时使用系统分配；共享或生命周期解耦时使用用户分配）
GitHub Actions / GitLab CI / Azure DevOps / Jenkins联合工作负载身份到用户分配的 MI 或应用注册
Azure 外部且具有 OIDC 颁发者的工作负载（Kubernetes、AWS、GCP）联合工作负载身份
不支持 OIDC 的传统本地服务使用证书的应用注册（绝不使用机密）
仅向 Microsoft Graph 进行身份验证的任何工作负载应用注册 + 联合身份验证/证书

**经验法则：**如果设计文档中出现了客户端机密，说明你错过了使用联合身份验证的机会。先尝试联合身份验证；无法使用时再退回到证书；新建工作负载绝不使用客户端机密。

方案

  1. 盘点现有服务主体和凭据。 使用 Microsoft Graph （servicePrincipals、applications）列出每个应用注册、其密钥/机密 凭据、到期日期和已分配的角色。大多数租户都会发现已过期的机密、 使用了十年的测试应用，以及无人负责但已获管理员同意的应用。

  2. 在支持联合身份验证的情况下，移除机密：

    • GitHub Actions → Azure：在用户分配的 MI （或应用注册）上配置联合凭据，主体为 repo:org/repo:environment:prod。GitHub 中无需存放机密。
    • AKS 工作负载身份：在集群上启用，为服务账户添加注释，并投影 令牌；Pod 会以绑定到它的用户分配 MI 身份进行身份验证。
    • Azure DevOps：使用 Workload Identity federation 服务连接。
    • 外部 OIDC 颁发者（GCP、AWS、Okta）：添加带有颁发者 URL 和主体声明的联合凭据。

  3. 必须保留凭据时，使用由 Key Vault 轮换的证书，而非客户端机密。设置较短的有效期（≤180 天），并自动执行轮换。

  4. 应用最小权限 RBAC。 默认在资源或 RG 级别分配范围受限的角色——除非有充分理由，否则绝不授予 Subscription Owner。避免使用 Microsoft Graph .All 权限（例如 Files.ReadWrite.All），优先使用范围受限的权限或按应用集合划分的权限（Sites.Selected、通过应用访问策略向特定邮箱授予 Mail.Send）。

  5. Workload Identities Premium（独立 SKU）。可启用：

    • 针对工作负载的条件访问 — 阻止来自意外 IP 范围的服务主体登录，要求使用命名位置，并按客户端应用进行限制。
    • 工作负载身份风险检测 — 检测凭据泄露、异常登录和可疑的管理员活动。
    • 工作负载身份访问审查 — 定期由所有者审查 SP 角色。 为面向外部或高权限的工作负载身份启用此功能；无需覆盖租户中的每个 SP。

  6. 生命周期： 每个应用注册都必须有所有者（不能是已离职的人员，也不能是空列表）。每季度审查无人负责和未使用的应用；先禁用，再删除。

  7. 监控。 将 ServicePrincipalSignInLogs 流式传输到 Sentinel。针对以下情况发出警报：

    • 登录来自超出预期基线的国家/地区或 IP。
    • 添加了新凭据（尤其是添加者与所有者身份不同的情况）。
    • 在工作时间以外，为高权限角色签发令牌。

防护措施

  • 新设计中不得使用客户端机密。 联合身份验证 > 证书 > 机密。
  • 系统分配的 MI 与资源生命周期绑定。 删除资源后，身份（及其角色分配）也会消失——通常是好事，有时会让人意外。
  • 跨资源共享用户分配的 MI 虽然方便，但会破坏爆炸半径隔离。只有在生命周期和信任边界确实一致时才共享。
  • 联合凭据必须指定具体范围。 主体 repo:org/repo:* 会接受每个分支和 PR——包括攻击者的分叉仓库。应固定到环境或受保护的分支。
  • 没有明确理由，不得使用 .All Graph 权限。 使用 Sites.Selected、邮件应用访问策略或应用专用 RBAC 范围限制。
  • 不要为每个环境创建一个应用注册。 每个工作负载使用一个应用，配置多个联合凭据（每个环境一个）——让角色清单保持整洁。
  • 所有者 = 一个人 + 一个组。 只有单一所有者的应用会在人员离职后变成孤儿应用。
  • 工作负载的 CA 是单独的高级策略类型。 如果依赖它来满足合规要求，请确保已启用。

常见反模式

  • “GitHub Action 将 AZURE_CREDENTIALS 存储为 JSON 机密”——存在机密泄露风险。 改用 OIDC 联合身份验证。
  • “整个 DevOps 平台共用一个大型服务主体，且在每个订阅中都拥有 Owner 角色”——一旦遭到入侵，整个租户都会沦陷。应为每条管道配置独立身份，并限定其权限范围。
  • “客户端机密到 2099 年才过期”——长期有效的持有者机密会让任何轮换计划形同虚设。应将有效期限制为 180 天，并实现自动化。
  • “AKS Pod 使用节点池 MSI 访问应用数据”——该节点上的每个 Pod 都使用相同的身份。应为每个服务账户使用 AKS 工作负载身份。
  • “联合凭据的主体 = repo:org/repo:”**——这会接受任何分支，包括 PR。应固定为 environment:prod。
  • “为了运行报告脚本，向服务主体授予了全局管理员权限”——只读的 Graph 权限并限定范围就足够了。
  • “应用注册的所有者列表为空”——无人审核或轮换。孤立应用会成为审计发现项。

示例提示词

  • 将 GitHub Actions Azure 部署中的客户端机密替换为工作负载身份联合身份验证。
  • 将 12 个 AKS 工作负载从 kiam/pod-identity 迁移到 AKS 工作负载身份。
  • 盘点所有将在 30 天内过期的应用注册机密，并确定证书轮换的优先级。
  • 为 payroll 集成服务主体应用条件访问策略，将 IP 限制为合作伙伴 CIDR。
  • 为 Azure DevOps 设计联合凭据，使用环境范围的主体声明区分 prod 和 dev。
  • 审计具有 Microsoft Graph .All 权限的服务主体，并提出范围更窄的替代方案。
  • 使用 Workload Identities Premium，为高权限工作负载身份推出季度访问评审。
  • 在 Sentinel 中搜寻异常的服务主体登录——KQL 检测。

Microsoft Learn

评论

支持 Markdown