微服务前方有雷，服务网格帮你趟过通信安全这个坑！
翻译：狄卫华 （博客地址 : https://blog.do1618.com）
作者：Christian Posta
原文：How a Service Mesh Can Help With Microservices Security
地址：http://blog.christianposta.com/how-a-service-mesh-can-help-with-microservices-security/
导读：
我看到很多客户转向微服务（他们是否应该是另外一个帖子的主题(注1)），他们试图通过这种方式解决一些组织化的规模问题。但是，转向微服务架构的细节往往会为旧问题带来一些新问题。
我与之交谈的大多数客户采用一种策略：架构上既有内部部署，也有公有云部署。将应用程序分解为更小的服务并拥有多个部署站点/平台会带来一些更大的挑战。在我看来，像 Istio 这样的服务网格实现旨在解决这些挑战中的一些问题。对于 Istio 和 Service Mesh ，我确实有很多话要说(注2)，所以请随时关注@christianposta(注3) 参与并跟踪最新状态。
在微服务化的过程中你将面临的一个挑战是：安全
我知道，作为开发人员，你可能已经对安全非常憎恨——微服务使其更加糟糕。当我们将应用程序分解为更小的服务时，我们会增加被攻击的范围。虽然这有很多安全方面的问题（应用程序漏洞，平台漏洞，数据保护，传输/网络等），但在本文中我将主要集中在微服务如何相互通信以及其出现的一些问题上。
传统上，我们认为网络边界足以保护我们；我们的应用程序在传输安全方面的问题不必考虑太多，因为我们处于 ”受保护的内部网络“。停下来思考一下，你是否使用 SSL/TLS 保护你的内部应用程序？
我们以前通过单体程序本地调用的所有通信都将暴露在开放的网络中。首先我们要做的就是加密所有的内部流量。如果你在实施微服务上没有使用 TLS 进行传输加密，那么你正在将面临着令人讨厌的安全问题。
部分成熟的客户已经实现了所有微服务通信加密，这并没有带来显著成本提升。搭建公钥基础设施、签发密钥和证书、安装、轮换等都是非常大的考验。尝试配置正确的信任库/密钥库（Java）、合适的SSL算法、确保拥有正确的证书链等都是让人感到头痛的事情。我个人试图让其能够正常工作浪费了很多天。然后当其都能正常工作以后，你就不会再想去折腾它。
我也看到了开发人员使用了 SSL/TLS，然后将其代码部署到 IST/UAT 等测试环境中，但是最终发现相关的安全配置在底层环境中不能够正常工作；由于着急将产品部署到生产环境中，他们会执行诸如禁用 TLS 验证的操作。
像 Istio 这样的服务网格相当简化了这一点。借助 Istio，应用程序的所有实例都有自己的 Sidecar 容器。该 Sidecar 充当所有流入和流出网络通信的服务代理。
在使用服务代理可以获得的诸多好处(注4)，与此文讨论相关的好处是能够透明地进行 TLS 加密。这意味着位于与应用程序请求路径中的代理承担了加密流量的责任。你的应用程序可以完全不用关心证书，信任库，密钥库等问题。 Istio 自动将证书和密钥关联到服务，代理使用它们来加密流量（提供双向TLS），并且 Istio 定期轮换密钥/证书，以减少泄露的风险。
举例来说，当 Istio 运行在 Kubernetes 上时(注5)，无论你何时部署应用程序，只需要指定一个应用程序运行的服务帐户，之后，Istio 负责处理其余部分。Istio 将为你的服务帐户创建证书/密钥对，使用根 CA密钥 对证书签名，并在将证书/密钥作为 Kubernets 中的密码。密码将被挂载到你的应用程序和 Istio 服务代理运行的 Pod 中，代理将使用证书/密钥来建立双向 TLS。
微服务的另一个安全问题是责任混淆问题(注6)。在这种情况下，终端用户已经授权服务代表它做某件事。在这种情况下，服务可能被授权执行此操作，但特定用户可能不会。我们应该以某种方式将用户身份绑定，并基于身份来评估授权。方法之一就是使用像 JWT (注7) 的令牌。
相关的有以下几点：
首先，如果你传递明文的 JWT 令牌（不使用TLS/mTLS），那么你会遇到比较大的麻烦。令牌默认不进行加密（仅签名），他们很容易地被收集并重放（replay）到服务中。再次，这是 Istio mTLS 可以提供帮助的地方。但即使启用了 mTLS，令牌也可能以被其他的方式泄露（我看到令牌被硬编码到源代码中!）。如果你的所有服务都将 JWT 传递给其他所有服务，那么您将再次面临重放攻击问题。
其次，如果你试图在所有微服务器上进行 JWT 验证，则会遇到与弹性库相同的问题(注8)。每个服务都有自己的库和自己的 JWT 验证实现。尽管像 JBoss Keycloak(注9) 这样的项目提供了出色的多语言支持，但它对库维护人员以及依赖这些库的应用程序开发人员来说都是一种负担。确保它们全部实施正确，一致并统一是一个充满了问题的壮举。
值得庆幸的是，Istio 可以在这两个方面提供帮助。
首先，无论应用程序框架/语言如何，Istio 都可以为你自动进行 JWT 验证。你可以定义一个`EndUserAuthenticationPolicySpec`，它配置了将用于验证的身份/凭证提供者(注10)：
--- apiVersion: config.istio.io/v1alpha2 kind: EndUserAuthenticationPolicySpec metadata: name: cars-api-auth-policy namespace: tutorial spec: jwts: - issuer: http://keycloak:8080/auth/realms/istio jwks_uri: http://keycloak.tutorial:8080/auth/realms/istio/protocol/openid-connect/certs audiences: - cars-web
然后你可以将它绑定到特定的服务：
注意：这个例子来自我的同事 Kamesh Sampath(注11)。在这个配置中，我们已经建立了 `Keycloak` 成为 JWT 令牌的身份管理者和发行者（遵循OpenID Connect）。有关更多信息，请参阅此博客(注12)。当请求进入服务时，如果它没有 JWT 持票人令牌，它将被拒绝。这个配置将安装 EnvoyJWT 过滤器(注13)，该过滤器负责验证 JWT 的签名：
最后，JWT 令牌是如何地传播？
Istio 默认只会将 JWT 令牌传播一次，使用 JWT 令牌的主体，并将其传递到应用程序通过单独的 header 字段。 JWT 主体将通过 header 头部中的 `sec-istio-auth-userinfo` 携带信息。基于终端用户的身份和服务的身份，应用程序有责任重新提交新的令牌。通过这种方式，我们可以将令牌的范围限定为单次使用，而不是将 JWT 到处传播。对此的实施仍在发展中，我强烈建议遵循这里 (注14) 和这里（注15）。
现在就是这样。随着 Istio 内部安全性的加强，我会进一步跟进。关注我@christianposta (注16) 获取微服务，服务网格，Istio 等最新信息。
注:
1:http://blog.christianposta.com/microservices/when-not-to-do-microservices/
3:https://twitter.com/christianposta
4:https://istio.io/docs/concepts/what-is-istio/overview.html
5:https://istio.io/docs/setup/kubernetes/quick-start.html
6:https://en.wikipedia.org/wiki/Confused_deputy_problem
7:https://jwt.io/
8:http://blog.christianposta.com/microservices/the-hardest-part-of-microservices-calling-your-services/
10:https://istio.io/docs/reference/config/istio.mixer.v1.config.client.html#EndUserAuthenticationPolicySpec
11:https://twitter.com/kamesh_sampath
12:http://blog.keycloak.org/2018/02/keycloak-and-istio.html
13:https://github.com/istio/proxy/blob/master/src/envoy/http/jwt_auth/README.md
14:https://docs.google.com/document/d/1_ccf9pUyN9G0UQqPP-ngr2Do5HcU5zzQZNj6NH1i3gs/edit#heading=h.kt4x5aalmyhf
15:https://docs.google.com/document/d/1rU0OgZ0vGNXVlm_WjA-dnfQdS3BsyqmqXnu254pFnZg/edit#heading=h.kt4x5aalmyhf
16:https://twitter.com/christianposta
- 发表于:
- 原文链接：http://kuaibao.qq.com/s/20180417G1COO500?refer=cp_1026
- 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
