Keycloak 和 Istio
2018年2月26日 Sébastien Blanc 发布
这篇简短的博文旨在分享 Keycloak 与 Istio 结合使用的首次尝试。
什么是 Istio？
Istio 是一个平台，它提供了一种通用方式来管理您的服务网格。您可能想知道什么是服务网格，嗯，它是一个基础设施层，专门用于连接、保护和使您的不同服务可靠。
最终，Istio 将取代我们所有的断路器、智能负载均衡或指标库，以及两个服务之间安全通信的方式。这当然是 Keycloak 感兴趣的部分。
如您所知，Keycloak 为其保护的每个应用程序或服务使用适配器。这些适配器确保在需要时执行重定向、检索公钥、验证 JWT 签名等……
根据所使用的应用程序或技术的类型，有很多不同的适配器：有 Java EE 适配器、JavaScript 适配器，甚至还有一个 NodeJS 适配器。
适配器的终结？
遵循 Istio 的理念，最终将不再需要这些适配器，因为 Istio 基础设施将负责适配器正在执行的任务（签名验证等...）。目前我们还没有达到这个阶段，但在这篇文章中，我们将了解 Istio 已经可以做些什么，以及它在多大程度上可以取代适配器的角色。
Envoy Sidecar
我们不会深入探讨 Istio 的工作原理，但围绕 Istio 架构有一个主要概念需要理解：Envoy Sidecar。Envoy 是一个高性能代理，与每个部署的服务一起部署，这就是我们称之为“sidecar”的原因。
Envoy 捕获其“伙伴”服务的所有传入和传出流量，它可以应用一些基本操作，还可以收集数据并将其发送到称为 Istio 中的“mixer”的中央决策点。Envoy 本身的配置通过“pilot”这个 Istio 组件进行。
Envoy 过滤器
为了更容易地向 Envoy Proxy 添加新功能，引入了可以堆叠的过滤器概念。同样，这些过滤器可以由 Pilot 配置，并且它们可以为 Mixer 收集信息
JWT-Auth 过滤器
Istio 团队一直在开发一个我们感兴趣的过滤器：jwt-auth 过滤器。顾名思义，此过滤器能够对 Envoy Proxy 将从 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 App Pod (Cars Web)：此 pod 包含 Web 应用程序，该应用程序将通过 Keycloak 登录执行身份验证，以获取 JWT 令牌
- 然后我们有 Istio 相关组件
- Pilot 用于配置 Envoy 代理
- Mixer 用于处理 Envoy 返回的属性
- API 服务 (Cars API)：此 pod 将有两个容器
- API 服务本身，在本例中是一个简单的 Spring Boot 应用程序
- Envoy Side-Car 容器
演示存储库提供了 Istio 脚本，用于将 Envoy Sidecar 与 Spring Boot Api Service 一起部署。
这是 Cars API Pod 部署后的外观
现在，需要配置 Envoy Sidecar
- 我们指明需要配置的内容、策略的种类，并隐式地配置正确的过滤器（在本例中为 jwt-auth 过滤器）。
- 它需要知道在哪里检索 Keycloak 的公钥，以便验证 JWT 签名。
- 颁发者：谁生成了令牌？在这种情况下，它也是 Keycloak 服务器。
现在，Envoy Sidecar 将检查每个发送到 API 服务的传入请求，以查看标头中包含的 JWT 令牌是否有效。如果有效，则请求将被授权，否则将返回错误消息。
演示的完整说明（包括使用 Istio 设置 Minishift）可以在此处找到，再次感谢出色的 Kamesh 为此演示所做的工作。