用云身份进行交换:托管计算的工作负载验证 笔记

用云身份进行交换:托管计算的工作负载验证

组织通常维护两套并行的身份系统:一套来自云提供商(如 AWS),另一套用于内部服务。本文详细介绍了运行在 Amazon EMR 上的 Apache Spark 工作负载如何弥合这一差距,使其能够从初始的云身份获得一等公民的内部身份。Netflix 使用名为 Metatron 的私有公钥基础设施(PKI)实现服务间通过双向 TLS 的认证,该过程需要 attest(证明)流程来验证工作负载的身份。此外,Netflix 还采用“数据项目”(Data Project)概念,该概念拥有数据并具备独立身份,从而确保访问控制和审计的一致性。核心挑战在于将基于云的 AWS 执行角色转换为托管计算环境中 Spark 作业所需的内部身份。该解决方案在数据项目身份与专用 IAM 角色之间建立直接的一对一映射,由数据项目服务作为该映射的权威方。此映射对于将云提供商的术语体系中的权限语句转换为组织的内部术语体系至关重要。为解决管理大量 IAM 角色的可扩展性问题,这些角色被确定性地在少量专用的 AWS 账户池中分片(sharded)。该方案涉及五个组件:控制平面(负责启动作业并签署元数据)、数据项目服务(管理身份到角色的映射)、身份服务(验证证明并颁发证书)、Spark 插件(钩入进程引导阶段)以及 AWS STS(充当公证人)。流程始于控制平面签署包含工作负载详情的元数据负载。随后,Spark 驱动端插件利用 AWS 凭证从 AWS STS 生成预签名 URL,以证明持有云身份。接着,身份服务核实这两项独立的声明:由 AWS 通过预签名 URL 识别的角色,以及来自控制平面的已签署元数据。若两者一致,则向工作负载颁发证书。这种相互验证至关重要,因为单靠任一声明均不足够:云提供商的声明不可伪造但描述不充分,而控制平面的声明描述充分但可能存在重放风险。该系统通过让驱动端进行一次证明并安全分发凭证,解决了执行器(executors)的扇出(fan-out)问题。证书具有短生命周期,并通过驱动端 JVM 内可重复的证明流程进行续期。信任模型确保没有任何单一参与者能够独立颁发身份,且工作负载本身也无需为其合法性背书。
CdXz5zHNQW_E3OfGUk31B.png