Keycloak 和 Istio
2018 年 2 月 26 日，作者 Sébastien Blanc
这篇简短的博文是分享将 Keycloak 与 Istio 结合在一起的首次尝试。
什么是 Istio？
Istio 是一个提供管理服务网格的通用方式的平台。您可能想知道什么是服务网格，它是专门用于连接、保护和提高不同服务可靠性的基础架构层。
最终，Istio 将取代我们所有的断路器、智能负载均衡或指标库，还会取代两种服务之间以安全方式通信的方式。当然，这对 Keycloak 来说很有意义。
如您所知，Keycloak 对其保护的每个应用程序或服务使用适配器。这些适配器确保在需要时执行重定向，检索公钥，验证 JWT 签名等。
根据所用应用程序或技术的类型，存在许多不同的适配器：有 Java EE 适配器、JavaScript 适配器，甚至还有一个 NodeJS 适配器。
适配器的终结？
遵循 Istio 的理念，最终将不需要这些适配器，因为 Istio 基础架构将负责适配器执行的任务（签名验证等）。我们现在还没有到这一步，但在本文中，我们将了解 Istio 目前能做什么，以及它在多大程度上可以取代适配器的作用。
Envoy 边车
我们不会深入探讨 Istio 的工作原理，但有一个主要概念需要了解，Istio 正是在这个概念的基础上构建起来的：Envoy 边车。Envoy 是一个高性能代理，与每个部署的服务一起部署，这就是我们称之为“边车”的原因。
Envoy 会捕获其“伴侣”服务的全部传入和传出流量，然后执行一些基本操作，并收集数据并将其发送到一个中央决策点，称为 Istio 中的“混合器”。Envoy 本身的配置是通过 Istio 的另一个组件“驾驶员”完成的。
Envoy 过滤器
为了更轻松地向 Envoy 代理添加新功能，有一个过滤器概念，您可以将其叠加。同样，这些过滤器可以通过驾驶员配置，并且可以收集信息以供混合器使用。
JWT-Auth 过滤器
Istio 团队一直在开发一个对我们很感兴趣的过滤器：jwt-auth 过滤器。顾名思义，此过滤器能够对 Envoy 代理从 HTTP 请求标头中提取的 JWT 令牌进行检查。
有关此过滤器的详细信息，请参见 此处。
Keycloak-Istio 演示
现在您已经了解了全局图景，让我们来看一下 Red Hat 开发者体验团队的 Kamesh Sampath (@kamesh_sampath) 开发的演示，该演示展示了如何将 Keycloak 和 Istio 结合起来。
演示将在 Minishift 实例内运行，Minishift 是一个帮助在本地运行 OpenShift 的工具。Minishift 对 Istio 的支持非常好，因为只需要几个命令就可以在 Minishift 实例内安装 Istio 层。
因此，在我们的 Minishift 实例中，我们将拥有
- 一个 Keycloak Pod：包含 Keycloak 服务器的 pod。
- 一个 Web 应用程序 Pod（Cars Web）：此 pod 包含将通过 Keycloak 登录进行身份验证以获取 JWT 令牌的 Web 应用程序。
- 然后我们有 Istio 相关组件
- 驾驶员，用于配置 Envoy 代理
- 混合器，用于处理 Envoy 返回的属性
- API 服务（Cars API）：此 pod 将有两个容器
- API 服务本身，在本例中是一个简单的 Spring Boot 应用程序
- Envoy 边车容器
演示存储库提供了 Istio 脚本，用于在 Spring Boot API 服务旁边部署 Envoy 边车。
以下是部署后的 Cars API Pod 的外观
现在，需要配置 Envoy 边车
- 我们指定需要配置的内容，策略类型，并隐式配置正确的过滤器（在本例中为 jwt-auth 过滤器）。
- 它需要知道从哪里检索 Keycloak 的公钥以验证 JWT 签名。
- 发行者：谁生成了令牌？在本例中，也是 Keycloak 服务器。
现在，每个对 API 服务的传入请求都将由 Envoy 边车检查，以查看标头中包含的 JWT 令牌是否有效。如果有效，则授权请求；否则，将返回错误消息。
演示的完整说明（包括使用 Istio 设置 Minishift）可以在 此处找到，再次感谢 Kamesh 为此演示做出的出色工作。