我一直在研究SPIFEE(每个人的安全生产身份框架)[1],在这里,我正在按照我现在的理解起草流程,以使任何试图理解流程的人受益。
- 身份注册表 – SPIRE服务器具有自己的身份注册表,该注册表保留两个粗粒度属性,这些属性决定如何将SPIFFE ID发布给工作负载。 它保留了下表中的详细信息。
特殊ID | 节点选择器 | Craft.io选择器 |
spiffe://abc.com/bill | aws:ec2:1234 | k8s:命名空间:1234 |
spiffe://xyz.com/account | 令牌:7236427472 | UNIX:UID:1002 |
提供了单独的注册API来管理身份注册表中的这些条目。
- 节点选择器 –定义可以在其上运行工作负载的计算机(物理或虚拟)。 根据运行工作负载的基础结构提供程序(AWS,GCP,裸机)确定要使用的选择器的确切类型。 例如。 AWS EC2实例ID,物理机的序列号。 节点证明者根据基础结构提供者采取行动以兑现那里的选择器。
- 工作负载选择器 –这定义了在识别节点之后如何识别代表工作负载的流程。 这可以用进程本身的属性(例如Linux UID)或间接属性(例如kubernetes名称空间)来描述。 节点代理负责验证计算机上的特定进程是否符合其工作负载选择器的条件。 工作负载证明者基于流程属性来执行流程选择器。
- SPIRE节点代理 –位于节点上的进程,用于验证节点上运行的工作负载的来源,并根据选择器通过Workload API为这些工作负载提供证书。
![特殊规格](https://i-blog.csdnimg.cn/blog_migrate/39dc6f86f53ec152878d75b891d45598.png)
- 管理员或第三方应用程序调用注册API,以使用所需的SPIFFE ID和相关的选择器填充身份注册表。
- 节点代理使用预先建立的加密密钥对或基于基础结构提供程序通过SPIRE服务器进行身份验证。 例如,对于AWS EC2,节点代理将提交由AWS发布的节点的实例标识文档(IID)。
- SPIRE服务器中的节点证明者根据使用的机制来验证提供的标识文档。 如果使用AWS IID,则相关证明者将使用AWS设置对其进行验证。 验证成功后,SPIRE服务器会发送回一组SPIFFE ID,这些ID可以连同其进程选择器策略一起发布给节点。
- 当工作负载开始在节点中运行时,它首先致电节点代理,询问“我是谁?”。
- 基于上一步中接收到的进程选择器节点代理,并使用工作量证明者,代理决定要赋予工作量的SPIFFE ID。 它基于此生成密钥对,并将CSR(证书签名请求)发送到SPIRE服务器。
- SPIRE服务器使用工作负载的签名SVID以及信任包响应节点代理,指示该工作负载可以信任其他哪些负载。
- 收到来自SPIRE服务器的响应后,节点代理将接收到的SVID移交给信任,将生成的私钥捆绑到工作负载中。 此私钥永远不会离开其工作负载所属的节点。
如果您发现任何问题,请随时提出任何更正建议。
[1] – https://spiffe.io [2] – https://docs.google.com/document/d/1RZnBfj8I5xs8Yi_BPEKBRp0K3UnIJYTDg_31rfTt4j8/edit#
翻译自: https://www.javacodegeeks.com/2019/01/spiffe-nutshell.html