云原生身份与访问管理 (IAM)

概述

在云原生架构下，随着系统变得日益分布式、动态化和自动化，身份已成为新的安全边界。传统的基于网络边界（Perimeter-based）的身份验证与授权方法，难以应对短生命周期的工作负载、频繁的服务间通信以及零信任的安全要求。身份与访问管理 (IAM) 不再是一个可选的安全组件，而是构建安全、可靠、可扩展云原生系统的基石。对于SRE团队而言，一个健壮的IAM体系是保障服务间信任、实现细粒度访问控制、自动化运维操作以及最小化爆炸半径的关键前提。

核心概念

从边界安全到零信任安全

传统的网络安全模型依赖于清晰的内外边界（如防火墙），假设内部网络是可信的。然而，在动态的云原生环境中，工作负载（容器、Pod、虚拟机）的IP地址和位置不断变化，网络边界的界限变得模糊。零信任 (Zero Trust) 架构摒弃了“信任内部网络”的假设，其核心原则是“从不信任，始终验证”。它要求对每一次访问请求都进行严格的身份验证和授权，无论请求来自内部还是外部。

工作负载身份：SPIFFE

SPIFFE (Secure Production Identity Framework For Everyone) 是云原生环境下实现工作负载身份的标准框架。它为每个工作负载提供一个全局唯一、可验证的身份标识（SPIFFE ID），通常以URI格式呈现（如 spiffe://trust-domain/team-a/service-b）。SPIFFE通过签发短期的、自动轮换的SVID (SPIFFE Verifiable Identity Document，通常是X.509证书或JWT令牌) 来证明其身份，从而安全地实现服务间的相互认证 (mTLS)。

授权架构：PEP/PDP

现代的授权决策通常遵循策略执行点/策略决策点 (PEP/PDP) 架构模式，以实现关注点分离和策略的集中管理。

策略决策点 (PDP)：作为中央大脑，负责评估访问请求并基于策略做出“允许”或“拒绝”的决策。
策略执行点 (PEP)：作为守门人，部署在受保护资源的入口处（如API网关、Sidecar代理），它拦截请求，将其转发给PDP查询决策，并根据返回结果执行策略（放行或阻断）。
策略信息点 (PIP)：PDP通常需要从PIP获取请求的上下文属性（如用户角色、资源标签）来辅助决策。

实践

验证工作负载身份

在Kubernetes环境中，可以利用SPIFFE生态系统（如Istio或Linkerd）自动为Pod分配和管理工作负载身份。

安装并配置服务网格：部署启用SPIFFE功能的Istio或Linkerd作为数据平面。
声明服务身份：在Kubernetes Service 或自定义资源中，通过注解或标签定义工作负载的SPIFFE ID。例如，为 reviews 服务设置 spiffe://cluster.local/ns/bookinfo/sa/reviews。
自动证书签发：服务网格的控制平面（如Istiod）会自动为匹配的Pod签发短期SVID，并通过Envoy Sidecar代理以mTLS方式使用，无需应用代码修改。

实施细粒度授权控制

结合PDP可以实现基于属性的访问控制 (ABAC) 或基于角色的访问控制 (RBAC)。

定义策略：使用通用策略语言（如Open Policy Agent的Rego）编写授权规则。例如：“仅允许来自 spiffe://cluster.local/ns/default/sa/frontend 的请求读取 products 数据库”。
部署PDP：将OPA作为PDP部署为Sidecar或集中式服务。
集成PEP：配置Envoy等代理将特定路径的访问请求作为上下文发送给OPA进行评估，并执行其返回的允许/拒绝决策。

SRE 要点

与可靠性、可观测性、事件响应的关联

可靠性：正确的IAM设置能防止未授权的运维操作（如误删除Pod、错误配置变更），避免人为导致的故障。通过身份审计日志，可以回溯是谁在何时执行了导致故障的操作。
可观测性：将SPIFFE ID、用户身份等上下文信息注入到日志、指标和分布式追踪中，可以极大地提升问题排查的效率。你可以快速关联一个错误的请求来源是哪个具体的服务实例或用户。
事件响应：在安全事件响应中，精确的身份信息至关重要。IAM日志和策略能够帮助SRE团队快速定位被入侵的横向移动路径，撤销泄露的凭证，并基于身份而非临时IP来阻断攻击。

最佳实践与常见反模式

最佳实践：
- 默认拒绝：所有策略应默认拒绝访问，然后明确授予必要的权限。
- 最小权限原则：为工作负载和用户仅授予完成其任务所需的最小权限集。
- 短期凭证：广泛使用短期、自动轮换的凭证（如SPIFFE SVID、临时API密钥），减少泄露风险。
- 集中式策略管理：使用PDP集中管理策略，而非在应用代码中硬编码权限逻辑。
常见反模式：
- 将网络位置等同于身份：不应仅因请求来自“内部”网络就信任它。
- 静态、长期有效的凭证：管理困难且泄露后风险巨大。
- 过度宽泛的权限：为方便授予 * 或 admin 权限，违背最小权限原则。