使用服务网格增强安全性：Christian Posta探索Istio的功能

Istio帮助使“服务网格”概念变得更加具体和可访问，随着Istio 1.0的最新发布，我们可以预期人们对它的兴趣会激增。Jasmine Jaksic在InfoQ之前的一篇文章中很好地介绍了Istio和服务网格，因此我想借此机会介绍Istio的一个特定领域，它将为云服务和应用程序的开发人员和运营商带来巨大的价值:安全性

Istio用例

Istio试图解决在云平台上运行应用程序时遇到的一些特别困难的挑战。具体来说，Istio解决了有关应用程序联网、可靠性和可观察性的问题。过去，我们尝试使用专门构建的应用程序库来解决一些挑战，比如断路、客户端负载平衡、度量集合等等。在不同的语言、框架、运行时等环境中执行这些操作，会造成许多组织无法承受的操作负担。

此外，在每种语言中找到的实现之间很难保持一致性，更不用说在需要更改或发现错误时同步升级它们了。围绕可靠性、可观察性和策略执行的许多挑战都是非常横向的关注点，而不是业务差异。尽管它们不是直接的差异，但是忽视它们会导致巨大的业务影响，因此我们需要解决它们。

Istio旨在解决这些问题。

网络安全的重要性

应用程序团队关心的另一个水平问题是安全性，这个问题很难解决。在某些情况下，安全是事后才考虑的事情，我们试图在最后一刻把它硬塞进我们的应用程序。为什么?因为做好安全工作是很困难的。例如，像“加密应用程序流量”这样的基础性工作应该是普通而直接的，对吧?为我们的服务配置TLS/HTTPS应该是直接的，对吧?在过去的项目中，我们甚至可能已经这样做了。然而，根据我的经验，要把它做好并不像听起来那么容易。我们有正确的证书吗?客户是否接受CA的签名?我们是否启用了正确的密码套件?我是否正确地将其导入到我的信任库/密钥库中?在我的TLS/HTTPS配置中启用“——non - secure”标志不是很容易吗?

错误配置这种类型的东西是非常危险的。Istio提供了一些帮助。Istio在每个应用程序实例旁边部署sidecar代理(基于特使代理)，用于处理应用程序的所有网络流量。当应用程序尝试与http://foo.com进行通信时，它通过sidecar代理(通过环回网络接口)进行通信，Istio将把通信重定向到另一个服务的sidecar代理，后者将通信代理代理到实际的上游http://foo.com。通过在请求路径中拥有这些代理，我们可以做一些事情，比如自动加密传输，而应用程序不需要知道任何东西。通过这种方式，我们可以在不依赖于每个应用程序开发团队的情况下获得一致的应用流量加密。

为您的服务体系结构设置和维护TLS和相互TLS的实现的一个问题是证书管理。控制平面中的Istio的Citadel组件负责将证书和密钥获取到应用程序实例上。Citadel可以生成每个工作负载所需的证书和密钥来标识自己，并定期轮换证书，以便任何损坏的证书都有较短的寿命。使用这些证书，支持istio的集群具有自动的相互TLS。您还可以根据需要插入自己的CA提供者根证书。

使用Istio，网格中的服务之间的通信在默认情况下是安全的和加密的。您不再需要摆弄证书和CA证书链来让TLS工作。操作员不再希望和祈祷每个开发人员正确地实现和配置他们的TLS/HTTPS设置。它通过一些Istio配置自动完成。

Using Istio to enable mTLS

Istio遵循与Kubernetes相同的配置路径。实际上，在Kubernetes上，Istio配置了Kubernetes定制资源定义(CRD)对象。配置Istio安全策略的两个主要对象是策略和DestinationRule对象。策略对象用于配置服务(或服务组)的安全设置。例如，要配置Kubernetes客户名称空间中运行的所有服务，我们可以使用以下策略对象:

apiVersion: “authentication.istio.io/v1alpha1”
kind: “Policy”
metadata:
  name: “default”
  namespace: “customer”
spec:
  peers:

当我们使用这个配置时，在customer命名空间中运行的服务将期望任何传入的流量使用mtl。但是要使用mTLS，我们还需要告诉客户在调用服务时使用mTLS。为此，我们将使用Istio DestinationRule。Istio中的DestinationRule通常用于配置客户机如何与服务通信。使用目的地规则，我们可以指定诸如断路、负载平衡和TLS之类的东西。要启用mTLS，我们可以使用如下配置:

apiVersion: “networking.istio.io/v1alpha3”
kind: “DestinationRule”
metadata:
  name: “default”
  namespace: “foo”
spec:
  host: “*.customer.svc.cluster.local”
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

这个DestinationRule将要求客户端在调用客户名称空间中的服务时使用mTLS。我们还将tls模式配置为ISTIO_MUTUAL，这意味着我们期望Istio管理证书和密钥，并将它们挂载到服务中(在Kubernetes中使用Kubernetes的秘密)，以便服务代理可以使用它们来建立tls。如果我们想对客户机证书拥有自己的控制权，我们可以使用一种交互模式，并提供磁盘上客户机可以找到其证书和私钥的位置。

使用Istio验证原点标识(使用JWT)

当我们使用如上所述的mTLS时，我们不仅可以加密连接，更重要的是知道谁在调用谁。Istio为每个人(SPIFFE)规范使用安全生产标识框架。身份被编码到用于mtl的证书中。这样，服务A就知道当服务B与它交谈时，实际上它就是服务B。例如，如果不允许服务A与服务B对话，我们可以使用sidecars来强制执行，这些sidecars与每个应用程序一起运行，使用用于建立mtl的标识。

但是当服务A代表用户X请求服务B时会发生什么呢?如果服务A被允许调用服务B来做一些事情(检查账户余额)，但是用户X不能，我们如何验证和执行呢?在服务体系结构中，服务通信终端用户或原始标识(登录用户)的典型方式是传递标识令牌，比如JSON Web令牌。这些标记用于表示经过身份验证的用户和用户拥有的声明。

Istio可以帮助进行“起源”或“最终用户”JWT身份令牌验证。这是每个应用程序语言/框架组合过去不得不依赖库来处理验证和解包JWT令牌的另一个领域。例如，对于流行的Keycloak Identity和SSO项目，每种流行的语言都有相应的语言插件来处理这一职责。如果我们使用Istio，那么我们可以免费获得这种功能。例如，要将Istio配置为同时使用mTLS和验证请求中的JWT令牌(如果请求不存在、无效或过期，则失败)，我们可以配置策略对象。记住，策略对象指定了我们想从服务中得到的行为:

apiVersion: “authentication.istio.io/v1alpha1”
kind: “Policy”
metadata:
  name: “customer-jwt-policy”
spec:
  targets:
  - name: customer
  peers:
  - mtls:
  origins:
  - jwt:
      issuer: http://keycloak:8080/auth/realms/istio
      jwksUri: http://keycloak:8080/auth/realms/istio/protocol/openid-connect/certs
  principalBinding: USE_ORIGIN

使用这种配置，如果客户端尝试连接到客户服务，除非JWT身份验证成功，否则他们的请求将无法连接到服务。Istio实现的另一个好处是该请求也受到了mTLS的保护。这有助于保护JWT令牌不会被泄漏，并用于某些重放攻击。

未来:Zero-Trust网络

我们已经介绍了在构建云本地应用程序时，Istio可以改善您的安全姿态的几种方法。通过服务之间的交互以及源/最终用户之间的强大身份，我们可以编写一些非常强大的访问控制规则，以了解系统的行为方式。这个基金会为建立“零信任”网络铺平了道路。在零信任网络中，我们根据身份以及上下文和环境分配信任，而不仅仅是“调用者碰巧在同一个内部网络上”。当我们开始转向完全连接和混合的云部署模型时，我们需要重新考虑如何最好地将安全性构建到我们的体系结构中。Istio可以解决当今体系结构中的挑战，并在未来为您提供更多的选择。

Istio提供了一些非常强大的功能，服务团队必须以某种方式解决这些问题。它提供了很好的api和配置对象来在应用程序服务之外完成这一任务。它以一种高度分散的方式实现，旨在对失败具有高度的弹性。如果您希望采用服务网络，并将安全性考虑在您的列表中名列前茅，那么请参阅Istio。