GitHub-zlabjp/envoy-spire-opa-service-mesh: 使用Envoy作为数据平面以及SPIRE和OPA作为控制平面在Kubernetese上构建Service Mesh的演示案例源码

19-12-26 banq
              

该演示使用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发出请求时的流程。

  1. Envoy在启动时从SPIRE Agent获取mTLS所需的凭据,例如TLS客户端证书
  2. ec-web Pod中的应用程序向自己的Envoy发出请求,向ec-backend发出请求
  3. 收到请求的Envoy向ec-backend的Envoy请求
  4. 使用从SPIRE Agent获得的凭据在ec-web和ec-backend Envoy之间通过mTLS进行相互身份验证
  5. 身份验证成功后,ec-backend Envoy会向其OPA请求允许的请求。
  6. OPA通过查询预设策略和接收到的请求来执行授权处理
  7. 如果授权成功,则ec-backend Envoy会将请求代理到其自己的App
  8. 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.