最近正在读《Solving the Bottom Turtle》这本书，这篇是对局部内容的总结和思考，因为内容较多，会分几篇来发。
这本书的副标题是：
a SPIFFE Way to Establish Trust in Your Infrastructure via Universal Identity.
通过通用身份以 SPIFFE 的形式在基础设施中建设信赖。
大家记住其中的有几个关键词：通用身份、SPIFFE 的形式、基础设施、建设信赖。
背景
零信赖是一种异样炽热的平安模型，在之前翻译的文章中《零信赖对 Kubernetes 意味着什么》，对什么是零信赖、为什么要施行零信赖，做了初步的介绍。
过来几十年风行的边界平安模型，曾经不在适宜现在分布式的微服务架构、简单多样的零碎环境以及不可避免的人为失误。从零信赖的准则来看，通过平安边界防护的人、零碎和网络流量是不可信的，因为“你可能不是你”，身份不可信。
可能有人会问不是有用户名明码、证书么？这些都可能存在泄露，尤其是工夫越长泄露的概率越高（在平安畛域，只有 0 和 100，所有做不到 100% 的平安，都将其视作 0。这也是笔者对零信赖的肤浅了解）。
零信赖模型的外围是重塑身份的调配和验证形式，身份是构建零信赖模型的基石。
身份
事实世界的身份
在说零碎身份之前，先说下事实中的身份。大家都有身份证（Identity Card），生存中用到身份证的场景也越来越多，很多的服务都会查验身份证。为什么身份证就能验证持有人的身份，首先身份证是由政府机构颁发的，在颁发前会查验过申请的人信息（证实你就是你），这个充沛可信的；身份证自身做了防伪解决，有特定的查验伎俩很难被伪造。这里有几个定义：
- 主体：人
- 身份：惟一 ID。实际上身份证号这个惟一 ID 就是集体的身份，而姓名只是代称。
- 身份证明文件：身份证，身份证号、姓名、性别、照片、有效期等等（申请时还会录入生物辨认信息）。
- 颁发机构：政府机构。
再者身份证仅限在国内应用，只有在国内被信赖，这个区域就是另一个定义“信赖域”。
出国就要应用另一种证件护照，护照是依照国际标准制作和颁发的，能够被其余国家承受，也就是能够信赖域间互信。这些互信的信赖域，就组成了信赖联盟。
这里一共提到了如下的定义：
- 主体
- 身份
- 身份证明文件
- 颁发机构
- 信赖域
- 信赖联盟
数字世界的身份
数字世界的身份也有与事实世界相似的定义。
数字身份证明是数字世界的主体的身份证明文件，常见的有：X.509 证书、签名的 JWT 和 Kerberos 令牌等。数字身份证明能够应用明码技术进行验证。计算零碎能够应用数字身份证明通过验证，就像人应用身份证和护照一样。
为实现这些有一个十分风行的技术 Public Key Infrastructure (PKI)，其定义了一系列的为创立、治理、散发、应用、存储、撤销数字证书和治理公钥加密所须要的角色、策略、硬件、软件和流程。
接下来简略介绍下 X.509，有教训的同学能够间接跳过。
X.509 概述
1988 年 X.509 作为 PKI 的规范首次公布，X.509 假如有一套严格的层次化的证书颁发机构（CA，Certificate Authority）。申请者要提供证书签名申请（CSR，Certificate Signing Request。申请者通过本人的私钥签名创立的，外面蕴含了申请者的身份信息，进行用于验真的公钥、申请证书的名称、以及 CA 可能要求的其余身份信息等）。而后 CA 对该 CSR 进行签名转换成合格的证书发回申请方。
CA 将受信赖的根证书（蕴含了公钥）发给所有成员，成员应用根证书中的公钥对其余成员的证书（数字身份证明）进行查验。
证书的生命周期
后面讲了证书的颁发流程，每个证书在创立的时候都会设置无效截止日期，如果过期证书就有效了。
证书在过期之前，如果申请方出了问题，证书变成不可信会被 CA 撤消。就像用户名明码一样，无效日期越长出问题的几率就越大。因而一个无效的方法就是 在老本可控的状况下，尽可能缩短证书的有效期。 而后通过更新操作，发放新的证书。
数字身份的应用
- 认证：服务通过 X.509 证书或者 JWT 向其余服务提供身份信息。
- 保密性和完整性：保密性是指攻击者无奈获取音讯的内容；完整性指音讯传输的过程中无奈被更改。TLS 是宽泛应用的协定，用来通过证书在不可信的网络连接上提供认证、保密性和音讯完整性。TLS 的个性之一是能够作为双向的 TLS 认证（mutual TLS authentication）。
- 受权：认证实现之后，应用认证过的数字身份判断是否能够拜访服务。
- 可观测性：惟一的身份能够帮忙晋升组织外部基础设施的可观测性。
- 计量：比方微服务架构中常见的限流，能够通过惟一身份标识来治理申请的限额。
说完根底的身份，接下来就是 SPIFFE 和 SPIRE 了。
SPIFFE
Secure Production Identity Framework for Everyone 的缩写 SPIFFE，是一个软件身份标识的开源规范（CNCF 下），为了以组织和平台无关的形式实现身份标识的互操作性，SPIFFE 定义了以全自动形式获取和验证加密身份所需的接口和文档。为构建分布式系统的通用身份的管制立体提供了规范的撑持。这个管制立体就是咱们文章结尾提到的“基础设施”。作为基础设施，须要是语言、技术栈无关的，并能够做到全自动。
SPIFFE（实用于所有人的平安生产身份框架）以特制 X.509 证书的模式为古代生产环境中的每个工作负载提供平安身份。SPIFFE 打消了对应用程序级身份验证和简单网络级 ACL 配置的需要。
施行 SPIFFE 有着重要的前提，假如零信赖网络安全模型中：
- 网络通信是不可信的，可能被攻破
- 运行 SPIFFE 实现的组件的硬件及其运维人员是牢靠的
概念
SPIFFE 框架蕴含了如下几局部：
- SPIFFE ID：
- SVID（SPIFFE Verifiable Identity Document）
- Workload API
- Trust Bundle
- SPIFFE 联盟
SPIFFE ID
SPIFFE ID 应用 URI（对立资源标志符）格局的字符串，软件服务的惟一身份标识。由多个局部组成：
- 前缀
spiffe:// - 信赖域的名字，比方
example.com，还能够通过多级域名来示意环境、集群等信息stagging.example.com、k8s-cluster.example.com - 工作负载的名字或者身份标识，比方
/payment/mysql、/payment/web-fe、`/9eebccd2-12bf-40a6-b262-65fe0487d4
比方 spiffe://example.com/bizops/hr/taxrun/withholding
SVID
SVID 是能够对外提供服务身份标识加密的、可验证的证明文件。SVID 由机构签发，蕴含了繁多 SPIFFE ID，以及服务属于信赖域。
目前 SVID 的格局有两种：X.509 和 JWT。
X.509 SVID
SPIFFE ID 位于扩大字段 SAN（Subject Alternative Name）中。作为 SVID，SAN 中只能有一个值（其余场景中，SAN 中能够有多个值）。
倡议尽可能应用 X.509 SVID 而不是 JWT-SVID，因为安全性更高，尤其是与 TLS 联合应用。
JWT-SVID
JWT-SVID 将 SPIFFE ID 编码在 规范的 JWT) 中。在应用层，JWT-SVID 被用作 bearer 令牌向对端提供身份标识。
与 X.509 SVID 不同，JWT-SVID 存在 重放攻打 的危险，令牌会被未经受权的一方获取并冒用。
SPIFFE 定义了三种机制来防止这种危险：
- JWT-SVID 必须通过平安通道传输
aud申明必须与令牌针对方的严格字符串匹配- 所有的 JWT-SVID 必须蕴含有效期
Workload API
Workload API 是一个本地的、非联网的 API，最重要的是，这个 API 无需认证。工作负载无需调用 API 时无需提供任何信息，就像在操作系统中执行 whoami 操作系统会返回用户名一样，但 workload API 会返回更多的信息。工作负载能够拜访其获取以后的身份证明文件、信赖包及其他相干信息。
SPIFFE 的实现能够通过创造性的计划（比方操作系统提供的个性）来对调用方（工作负载）进行识别。
Workload API 作为 gRPC 服务器裸露提供服务，并应用双向流，服务器端的更新能够推送给工作负载。
Trust Bundle
SPIFFE 信赖包，是蕴含了信赖域公钥的文件。每种类型的 SVID 在信赖包都有其特有的形式，比方 X.509 SVID 中 CA 证书中蕴含了公钥。
信赖包中不会蕴含除公钥以外的其余敏感内容，能够被随便流传。
SPIFFE 联盟
SPIFFE 联盟有点相似后面讲的护照能够在其余国家来辨认身份。
SPIFFE 联盟是一种能够共享 SPIFFE 信赖包的简略机制。通常咱们心愿容许不同信赖域中的服务能够平安地进行网络通信。通信的单方查看对方提供提供的信赖包，来决定是否进行通信。这是基于单方能够相互裸露或者共享信赖包，这种机制被称为包端点（bundle endpoint）。
包端点是个简略的、由 TLS 爱护的 HTTP 服务。SPIFFE 的实现通过裸露该端点，使得包的内容能够被获取到。
SPIRE
SPIRE 是 SPIFFE 运行时环境（SPIFFE Runtime Environment）的首字母，是一个生产就绪、开源的（同在 CNCF 下）SPIFFE 实现。SPIRE 实现了 SPIFFE 五个定义。
SPIRE 蕴含了两个次要组件：服务端和代理。服务端负责验证代理和生成 SVID，而代理负责提供 workload API，并与服务端进行通信。
这两个组件的设计都反对插件，能够很容易地扩大反对不同的配置和平台。
SPIRE 架构
服务端
SPIRE 服务端治理和颁发 SPIFFE 信赖域中的所有身份标识，应用数据库（SQLite）来保留代理和工作负载的信息。
服务端通过应用注册条目来获知其治理的工作负载，注册条目是为节点和工作负载调配 SPIFFE ID 的灵便规定。
服务端提供了 API 和 CLI 两种拜访形式。
服务端为工作负载签发 SVID 时，能够应用其生成的自签发证书（默认），也能够通过上游证书颁发机构插件来配置应用上游证书颁发机构，来实现证书的签发。
代理
代理只有一个十分重要的性能：提供 workload API。为了提供这个 API，还要反对工作负载身份标识的确定、调用并将本身平安地接入 SPIRE 服务端。
SPIRE 代理会从 SPIRE 服务端接管 本地信赖域 以及 会间接调用它（SIRE 代理）的工作负载 的信息。
当在指定信赖域减少新的工作负载时，会在 SPIRE 服务端创立和更新记录，该工作负载的信息会主动地流传到正确的代理。
插件架构
后面提到服务端和代理都反对插件，通过插件来扩大适应新的 节点证实者 、工作 负载证实者，以及上游机构。
SIVD 治理
节点证实过程中会为 SPIRE 代理申请到身份标识，代理应用该标识来实现 SPIRE 服务端的认证。通过认证时候，从服务端获取被受权治理的所有工作负载的 SVID（保留在内存中）。
证实
证实是应用可用信息作为证据确认工作负载身份的过程。在 SPIRE 中有两种证实形式：节点证实和工作负载证实。
节点证实是断言形容节点属性（比方 AWS 主动扩大组的成员）；工作负载证实是断言形容工作负载的属性（比方应用的 Kubernetes Service Account，或者二进制文件的门路）。
这些属性在 SPIRE 中通通称为选择器（selector）。SPIRE 提供了大量的开箱即用的选择器，比方反对逻辑、Kubernetes、AWS、GCP、AZure 等等的节点选择器；反对 Docker、Kubernetes、Unix 等的工作负载选择器。
SPIRE 的插件架构设计，也反对更多选择器的扩大。
节点证实
节点证实产生在代理第一次启动时，代理与服务端通信进行信息替换。代理将通过插件采集的信息上报到服务端，服务器端应用对等的插件进行信息的确认。节点证实胜利后，节点会拿到身份证明，并应用身份证明与服务端进行后续的通信。
工作负载证实
工作负载证实产生在工作负载与 SPIRE 代理的 workload API 建设连贯时。证实的过程齐全由 SPIRE 代理实现，代理利用操作系统个性来确认是哪个过程创立的连贯。
比方在 Linux 下通过零碎调用来获取调用 socket 的对端过程 ID、用户标识和全局惟一标识。不同操作系统的内核元数据不同，拿到工作负载的 ID 之后，代理将 ID 提供给各个插件，从选择器中获取调用者的信息。
每个插件都会对调用者进行查看。比方一个插件从零碎内核中获信息，生成取用户、组等选择器；一个插件则会与 Kubernetes 交互，生成命名空间、service account 等选择器；另一个与 Docker daemon 进行交互，生成 Docker 镜像 ID、标签和容器环境变量的选择器。
注册条目
SPIRE 通过注册条目获知工作负载的各种信息，比方工作负载是否应该或容许呈现在环境中、应该运行的地位、SPIFFE ID 和其余信息。这些信息是通过 SPIRE API 创立和治理的。
每个注册条目蕴含了 3 个外围属性：
- Parent ID：通知 SPIRE 工作负载运行在哪里，进一步感知哪些代理有权获取其 SVID。
- SPIFFE ID：工作负载能够应用的 SPIFFE ID
- 能够用来辨识工作负载的信息：也就是选择器从证实中获取到的
注册条目能够形容一组节点或者一个工作负载，通常后者通过 Parent ID 来援用后者。
节点条目
形容一个节点或者一组节点的注册条目应用节点证实生成的选择器来调配 SPIFFE ID，在注册工作负载时能够援用该 ID。
一个节点能够被多个节点条目标选择器证实，因而能够存在于多个组中。
SPIRE 服务端一次能够加载多个节点证实器，而代理一次只能加载一个。
注册条目标 Pareent ID 指向的是 SPIRE 服务端的 SPIFFE ID。
工作负载条目
工作负载条目标 Parent ID 是节点（一个或者一组）的 SPIFFE ID。 示意其能够运行在哪个或哪组节点上。该节点上的 SPIRE 代理收到该工作负载的条目，蕴含了在颁发 SIVD 之前必须要证实的选择器。
与节点证实过程不同，SPIRE 代理一次能够加载多个工作负载证实器插件。
SPIFFE/SPIRE 利用概念威逼模型
平安边界
平安边界艰深地讲，就是从不平安的一方到平安的一方，并且都有其各自的证实形式。
SPIFFE/SPIRE 中定义了 3 个平安边界：工作负载与代理之间、代理与服务端之间、不同信赖域的服务端之间。
工作负载和其余信赖域中的服务端是齐全不可信的，网络通信也是齐全不可信的。
工作负载与代理的平安边界
代理不会信赖工作负载的任何输出，代理对工作负载的查看都是通过内部查看实现的。换句话说，所有值能够被工作负载批改的选择器，也是不平安的。
代理与服务端的平安边界
代理比工作负载平安一些，然而安全性不如服务端。SPIRE 的一个明确设计指标是它应该在节点被攻破后存活。
代理负责依据工作负载的行为来创立和治理标识，然而也有必要限度代理的能力在其职责范畴内（起码权限准则）。
代理在获取标识前，必须能有证实其对注册条目标所有权。
在节点尚未证实本人取得标识之前，与服务端的通信应用单向 TLS；取得身份标识和无效的 SVID 之后，应用双向的 TLS。
服务端之间的边界
SPIRE 服务端仅被信赖在其间接治理的信赖域内生成 SVID。
各组件被攻破的影响
如果代理被攻破，会影响其治理的工作负载。如果工作负载跟代理是 1:1 部署时（参考 Kubernetes Pod 中的多 sidecar），只会影响一个工作负载。然而代理治理多个工作负载时，影响范畴变大（参考 Kubernetes 中的 Daemonset，每个节点运行一个正本）。
SPIRE 服务端是整个零碎中最为敏感的组件，如果被攻破会影响到整个信赖域，强烈建议将其部署到与要治理的工作负载不同的硬件上。
概念威逼模型 vs 传统边界平安模型
这个概念威逼模型，实际上是将传统平安边界模型粒度进行细化，将隔离区放大并进行自治。缩得越小，安全性越高，破防时影响的范畴越小。
总结
本篇次要介绍了零信赖平安模型中身份定义，以及通用身份验证的规范和实现 SPIFFE/SPIRE。
回到结尾书的副标题中的几个关键词：通用身份、SPIFFE 的形式、基础设施、建设信赖。SPIFFE 提供了笼罩了身份、身份证书的类型以及创立、治理和颁发形式的定义，贯彻了零信赖的平安模型，为构建基础设施提供了规范框架。SPIRE 则提供了基础设施的实现，应用服务端 + 代理的分级策略采纳概念威逼模型，尽可能地晋升安全性和升高威逼带来的影响。
规范和实现都有了，实际上落地施行也是一个简单的过程。书中也提供了落地打算的设计方案以及分享落地的教训，后续会持续为大家解读。
关注 ” 云原生指北 ” 微信公众号
（转载本站文章请注明作者和出处盛世浮生，请勿用于任何商业用途）