svid


weight: 49 title: SVID 身份颁发过程 date: ‘2022-05-21T00:00:00+08:00’ type: book summary: 本文介绍了为工作负载颁发 X.509 SVID 身份的详细步骤。

本文介绍 SPIRE 如何向工作负载颁发身份的详细步骤,叙述了从代理在节点上启动到同一节点上的工作负载收到 X.509 SVID 形式的有效身份的全过程。请注意,JWT 格式的 SVID 的处理方式是不同的。为了简单演示的目的,工作负载在 AWS EC2 上运行。

  1. SPIRE 服务器启动。
  2. 除非用户配置了 UpstreamAuthority 插件,否则服务器会生成自签名证书(使用自己的私钥签名的证书);服务器将使用此证书为该服务器信任域中的所有工作负载签署 SVID。
  3. 如果是第一次启动,服务器会自动生成一个信任包(trust bundle),其内容存储在你指定的 sql 数据存储中 —— 在服务器插件:DataStore sql 的 “内置插件” 部分中描述。
  4. 服务器打开其注册 API,以允许你注册工作负载。
  5. 工作负载节点上的 SPIRE 代理启动。
  6. 代理执行节点证明,向服务器证明它正在运行的节点的身份。例如,在 AWS EC2 实例上运行时,它通常会通过向服务器提供 AWS 实例身份文档来执行节点证明。
  7. 代理通过 TLS 连接向服务器提供此身份证明,该 TLS 连接通过代理配置的引导程序包进行身份验证。

注意

此引导程序包是默认配置,应在生产中替换为客户提供的凭据。
  1. 服务器调用 AWS API 来验证证明。
  2. AWS 承认该文件是有效的。
  3. 服务器执行节点解析,以验证有关代理节点的其他属性并相应地更新其注册条目。例如,如果节点已使用 Microsoft Azure 托管服务标识 (MSI) 进行了证明。解析器从代理 SPIFFE ID 中提取租户 ID 和主体 ID,并使用各种 Azure 服务获取信息以构建一组额外的选择器。
  4. 服务器向代理发出一个 SVID,代表代理本身的身份。
  5. 代理联系服务器(使用其 SVID 作为其 TLS 客户端证书)以获取它被授权的注册条目。
  6. 服务器使用代理的 SVID 对代理进行身份验证。代理依次完成 mTLS 握手并使用引导程序包对服务器进行身份验证。
  7. 然后,服务器从其数据存储中获取所有授权的注册条目并将它们发送给代理。
  8. 然后,代理将工作负载 CSR 发送到服务器,服务器对其进行签名并作为工作负载 SVID 返回给客户端。客户端将它们放入缓存中。
  9. 现在引导完成,代理开始监听 Workload API 套接字。
  10. 工作负载调用工作负载 API 来请求 SVID。
  11. 代理通过调用其工作负载证明器来启动工作负载证明过程,并向他们提供工作负载进程的进程 ID。
  12. 证明器使用内核和用户空间调用来发现有关工作负载的其他信息。
  13. 证明器以工作负载选择器的形式将发现的信息返回给代理。
  14. 代理通过将发现的工作负载选择器与注册条目进行比较来确定工作负载的身份,并返回正确的 SVID(已在其缓存中)。

授权注册条目

服务器只向代理发送授权的注册条目。服务器执行以下操作来获取这些授权条目:

  1. 查询数据库以查找将代理的 SPIFFE ID 列为其 “父 SPIFFE ID” 的任何注册条目。
  2. 在数据库中查询特定代理与哪些附加属性相关联(“节点选择器”)。
  3. 查询数据库以获取在任何这些节点选择器上声明选择的至少一个注册条目。
  4. 递归地查询数据库中的任何注册条目,这些条目声明了迄今为止获得的任何条目作为它们的 “父 SPIFFE ID”(下降到所有子节点)。

另请参阅将工作负载映射到多个节点

服务器将生成授权的注册条目集发送给代理。

上一页