该演示使用Envoy作为数据平面以及SPIRE和OPA作为控制平面在Kubernetese上构建Service Mesh。该演示是zlabjp / spiffejp-demo，其中添加了OPA。
- 使用Kubernetes 1.17.0
- 使用特使 1.12.2，SPIRE 0.9.0和OPA 0.15.1
- Envoy使用SPIRE作为SDS服务器来获取TLS证书
- Envoy使用OPA作为外部授权服务器来检查传入请求是否被授权
Kubernetes集群中正在运行四个服务。
- ec-web（spiffe://example.org/ec-web）
- ec-web 仅接受包含“ ec-web-secret”值的自定义标头“ X-Opa-Secret”的请求
- ec-backend（spiffe://example.org/ec-backend）
- ec-backend可以只从访问ec-web
- news-web（spiffe://example.org/news-web）
- news-web 仅接受包含“ news-web-secret”值的自定义标头“ X-Opa-Secret”的请求
- news-backend（spiffe://example.org/news-backend）
- news-backend可以只从访问news-web
架构：
具体架构如下；
Envoy，SPIRE Agent和OPA被激活为每个pod的边车。为了稍微解释一下该功能，（ec | news）-web是Nginx，并且仅将从查看器收到的请求代理到（ec | news）-backend，而（ec | news）-backend返回一个字符串API。
简要介绍从ec-web向ec-backend发出请求时的流程。
- Envoy在启动时从SPIRE Agent获取mTLS所需的凭据，例如TLS客户端证书
- ec-web Pod中的应用程序向自己的Envoy发出请求，向ec-backend发出请求
- 收到请求的Envoy向ec-backend的Envoy请求
- 使用从SPIRE Agent获得的凭据在ec-web和ec-backend Envoy之间通过mTLS进行相互身份验证
- 身份验证成功后，ec-backend Envoy会向其OPA请求允许的请求。
- OPA通过查询预设策略和接收到的请求来执行授权处理
- 如果授权成功，则ec-backend Envoy会将请求代理到其自己的App
- ec-backend返回对ec-web的响应
上面是一个简单的流程。
Envoy
Envoy是每个Pod之间通信的中心人物，Envoy的重要功能是Secret Discovery Service（SDS），它是xDS API之一。
通过使用SDS，Envoy可以从SDS服务器动态获取TLS证书和mTLS通信所需的密钥。SPIRE代理充当了SDS服务器，并且可以将TLS证书的管理（分发和轮换）委托给SPIRE。
接下来，关于外部授权，可以使用此功能将Envoy的网络过滤功能委托给另一个系统，如果确定不允许该请求，则通信将关闭。 （对于HTTP，返回403）。这次，OPA将充当外部授权服务器。
SPIRE
如Envoy部分所述，SPIRE的作用是管理（分发和轮换）TLS证书。SPIRE颁发的TLS证书包含SPIFFE ID（即工作负载的身份），因此，本次引入的Servicec Mesh使用基于SPIFFE ID的身份验证和授权（通过Envoy中的mTLS和OPA中的SPIFFE ID进行相互身份验证）。基于基础的策略定义）是可能的。
*有关SPIRE的概述，请参阅开头提到的幻灯片。
OPA
如Envoy部分所述，OPA的作用是代表Envoy的网络过滤功能。这次，将进行设置以充当HTTP筛选器的外部授权服务器，并且基于HTTP请求所保存的信息来定义策略。当然，HTTP请求的信息包括TLS证书，因此可以基于SPIFFE ID进行控制。
点击标题见Github.