双向TLS认证

概述

Istio Auth的目标是提高微服务及其通信的安全性,而不需要修改服务代码。它负责:

  • 为每个服务提供强大的身份,代表其角色,以实现跨集群和云的互通性

  • 加密服务间通信和终端用户到服务的通信

  • 提供密钥管理系统来自动执行密钥和证书的生成、分发、轮换和撤销

架构

下图展示Istio Auth架构,其中包括三个主要组件:身份、密钥管理和通信安全。它描述了Istio Auth如何用于加密服务间通信,在以服务帐户“foo”运行的服务A,和以服务帐户“bar”运行的服务B之间。

如图所示,Istio Auth利用secret volume mount,从Istio CA向Kubernetes容器传递keys/certs。对于在VM/裸机上运行的服务,我们引入了节点代理,它是在每个VM/裸机上运行的进程。它在本地生成私钥和CSR(证书签名请求),将CSR发送给Istio CA进行签名,并将生成的证书与私钥一起交给Envoy。

组件

身份

在Kubernetes上运行时,Istio Auth使用Kubernetes service account 来识别谁在运行服务:

  • Istio中的service account格式为spiffe://<domain>/ns/<namespace>/sa/<serviceaccount>

    • domain目前是cluster.local. 我们将很快支持域的定制化。
    • namespace 是Kubernetes service account的namespace.
    • serviceaccount是Kubernetes service account name
  • service account是工作负载运行的身份(或角色),表示该工作负载的权限。对于需要强大安全性的系统,工作负载的特权量不应由随机字符串(如服务名称,标签等)或部署的二进制文件来标识。

    • 例如,假设我们有一个从多租户数据库中提取数据的工作负载。如果Alice运行这个工作负载,她将能够提取的数据,和Bob运行这个工作负载时不同。
  • service account通过提供灵活性来识别机器,用户,工作负载或一组工作负载(不同的工作负载可以以同一service account运行)来实现强大的安全策略。

  • 工作负载运行的service account将不会在工作负载的生命周期内更改。

  • 可以通过域名约束确保service account的唯一性

通讯安全

服务到服务通信通过客户端Envoy和服务器端Envoy进行隧道传送。端到端通信通过以下方式加密:

  • 服务与Envoy之间的本地TCP连接

  • 代理之间的双向TLS连接

  • 安全命名:在握手过程中,客户端Envoy检查服务器端证书提供的服务帐号是否允许运行目标服务

密钥管理

Istio v0.2支持服务运行于Kubernetes pod和VM/裸机。对于每个场景,我们使用不同的秘钥配置机制。

在于运行在Kubernetes pod上的服务,每个集群的Istio CA(证书颁发机构)自动化执行密钥和证书管理流程。它主要执行四个关键操作:

  • 为每个service account生成一个 SPIFFE 密钥和证书对

  • 根据service account将密钥和证书对分发给每个pod

  • 定期轮换密钥和证书

  • 必要时撤销特定的密钥和证书对

对于运行在VM/裸机上的服务,上述四个操作通过Istio CA用节点代理一起执行。

工作流

Istio Auth工作流由两个阶段组成,部署和运行时。对于部署阶段,我们分别讨论这两个场景(例如,在Kubernetes中和VM/裸机),因为他们不一样。一旦秘钥和证书部署好,对于两个场景运行时阶段是相同的。在这节中我们简要介绍工作流。

部署阶段(Kubernetes场景)

  1. Istio CA观察Kubernetes API Server,为每个现有和新的service account创建一个 SPIFFE 密钥和证书对,并将其发送到API服务器。

  2. 当创建pod时,API Server会根据service account使用Kubernetes secrets 来挂载密钥和证书对。

  3. Pilot 使用适当的密钥和证书以及安全命名信息生成配置,该信息定义了什么服务帐户可以运行某个服务,并将其传递给Envoy。

部署阶段(VM/裸机场景)

  1. Istio CA创建gRPC服务来处理CSR请求。

  2. 节点代理创建私钥和CSR, 发送CSR到Istio CA用于签名。

  3. Istio CA验证CSR中携带的证书,并签名CSR以生成证书。

  4. 节点代理将从CA接收到的证书和私钥发送给Envoy。

  5. 为了轮换,上述CSR流程定期重复。

运行时阶段

  1. 来自客户端服务的出站流量被重新路由到它本地的Envoy。

  2. 客户端Envoy与服务器端Envoy开始相互TLS握手。在握手期间,它还进行安全的命名检查,以验证服务器证书中显示的服务帐户是否可以运行服务器服务。

  3. mTLS连接建立后,流量将转发到服务器端Envoy,然后通过本地TCP连接转发到服务器服务。

最佳实践

在本节中,我们提供了一些部署指南,然后讨论了一个现实世界的场景。

部署指南

  • 如果有多个服务运维人员(也称为SRE)在集群中部署不同的服务(通常在中型或大型集群中),我们建议为每个SRE团队创建一个单独的namespace,以隔离其访问。例如,您可以为team1创建一个"team1-ns"命名空间,为team2创建"team2-ns"命名空间,这样两个团队就无法访问对方的服务。

  • 如果Istio CA受到威胁,则可能会暴露集群中被它管理的所有密钥和证书。我们强烈建议在专门的命名空间(例如istio-ca-ns)上运行Istio CA,只有集群管理员才能访问它。

示例

我们考虑一个三层应用程序,其中有三个服务:照片前端,照片后端和数据存储。照片前端和照片后端服务由照片SRE团队管理,而数据存储服务由数据存储SRE团队管理。照片前端可以访问照片后端,照片后端可以访问数据存储。但是,照片前端无法访问数据存储。

在这种情况下,集群管理员创建3个命名空间:istio-ca-ns,photo-ns和datastore-ns。管理员可以访问所有命名空间,每个团队只能访问自己的命名空间。照片SRE团队创建了2个服务帐户,以分别在命名空间photo-ns中运行照片前端和照片后端。数据存储SRE团队创建1个服务帐户以在命名空间datastore-ns中运行数据存储服务。此外,我们需要在 Istio Mixer 中强制执行服务访问控制,以使照片前端无法访问数据存储。

在此设置中,Istio CA能够为所有命名空间提供密钥和证书管理,并隔离彼此的微服务部署。

未来的工作

  • 集群间服务到服务认证

  • 强大的认证机制:ABAC, RBAC等

  • 每服务认证启用的支持

  • 安全Istio组件(Mixer, Pilot等)

  • 使用JWT/OAuth2/OpenID_Connect 的终端用户到服务的认证

  • 支持GCP service account

  • 非http流量(MySql,Redis等)支持

  • Unix域套接字,用于服务和Envoy之间的本地通信

  • 中间代理支持

  • 可插拔密钥管理组件