Cloudflare Zero Trust Access

差若天渊1

　　从 Zero Trust Access 到 Kubernetes

　　在过去的几年里，Kudelski Security 的工程团队已经将Cloudflare的基础结构迁移到多云环境中。我们的内部云迁移反映了我们的终端客户的追求，并为我们提供了专业知识和工具，以增强我们对其的服务。此外，这种转型让我们有机会重新构想我们自己的安全方式，并借助 Zero Trust 实现最佳的实践。

　　截至目前，我们在采用 Zero Trust 中遇到的最大困难在于，确保能够通过多种云环境访问我们不同的 Kubernetes（K8s）网络层（API）。在开始时，我们的基础结构团队很难清晰看到不同 K8s 集群的各种 API，并采取稳定、基于身份的控制。另外，当与这些 API 交互时，我们的开发人员经常对他们需要访问哪些集群以及如何访问这些集群一无所知。

　　为了解决这些摩擦，我们设计了一种内部解决方案，利用 Cloudflare 帮助开发人员在如何安全地验证位于公共云和内部环境中的 k8s 集群方面实现自动化。具体来说，对于特定开发人员来说，我们现在可以在给定的云环境中显示他们可以访问的所有 K8s 服务，使用 Cloudflare 的 Zero Trust 规则验证访问请求，并通过 Cloudflare 的身份感知代理 Cloudflare Tunnel 建立起到该集群的连接。

　　最重要的是，这个自动化工具能将 Kudelski Security 作为一个组织增强我们的安全态势，同时改善我们的开发人员体验。我们估计，该工具为新开发人员节省了至少两个小时，节省了本应花费在阅读文档、提交 IT 服务工单以及手动部署和配置访问不同 K8s 集群所需的不同工具上的时间。

　　利用 Cloudflare 的身份感知代理完成 Zero Trust 访问

　　为此，Kudelski Security 的工程团队选择了一种更时尚的方法：通过身份感知代理(IAP)在用户和每个 K8 集群之间创建连接。通过在发出访问请求时验证用户的身份，IAP 可以灵活地部署，并在应用程序前增加额外的安全层。此外，它们通过创建从用户到单个应用程序（而不是整个网络）的连接来支持我们的 Zero Trust。

　　每个集群都有自己的 IAP 和自有的策略集，其会检查身份（通过我们的企业 SSO）和其他情境因素，如开发者笔记本电脑的设备姿势。IAP 并不会取代 K8s 集群身份验证机制，而是在其之上添加了一个新的身份验证机制，并且得益于身份联邦和 SSO，这个过程对我们的最终用户是完全透明的。

　　在我们的设置中，Kudelski Security 正在使用 Cloudflare 的 IAP 作为 Cloudflare Access 的组件 - 一个 ZTNA 解决方案，也是 Cloudflare 的 Zero Trust 平台统一的几个安全服务之一。

　　

　　对于许多基于 web 的应用程序来说，IAP 有助于为通过浏览器请求访问的终端用户创造一种无障碍体验。在到达安全应用之前，用户通过他们的企业 SSO 或标识提供程序进行身份验证，而 IAP 则是在后台工作。

　　这个用户流有异于基于 CLI 的应用程序，因为我们不能像在浏览器中那样重定向 CLI 网络流。在我们的示例中，我们的工程师希望使用他们青睐的基于 CLI 的 K8s 客户端，比如?kubectl或k9s。这意味着我们的 Cloudflare IAP 需要在 CLI 客户端和每个 K8s 集群之间充当 SOCKS5 代理。

　　为了创建此 IAP 连接，Cloudflare 提供了一个轻量级的服务器端后台程序，名为cloudflared，用于连接基础结构和应用程序。该加密连接将在 Cloudflare 的全局网络上运行，并对单次通过检查应用 Zero Trust 策略。

　　然而，如果没有任何自动化，Kudelski Security 的基础结构团队将需要将后台程序分发到终端用户设备上，提供关于如何设置这些加密连接的指导，并采取其他手动、实际配置步骤，并不断对它们进行维护。另外，开发人员仍然缺乏跨不同 K8s 集群的单一可见窗格，这在日常工作中经常需要访问。

　　

　　我们的自动化解决方案：k8s-tunnels！

　　为了解决这些挑战，我们的基础结构工程团队开发了一种名为“K8s-tunnels”的内部工具 - 其嵌入了复杂的配置步骤，让我们开发人员的工作更加轻松。此外，该工具会根据创建的 Zero Trust 策略自动发现特定用户可以访问的所有 K8s 集群。为了实现这一功能，我们嵌入了 Kudelski Security 使用的一些主要公共云提供商的 SDKs。该工具还嵌入了?cloudflared?后台程序，这意味着我们只需向我们的客户分配一个单一的工具。

　　

　　总的来说，启动该工具的开发人员需要完成以下工作流程：（我们假设用户已经拥有有效的证书，否则该工具将在我们的 IDP 上打开浏览器以获取证书）

　　1.用户选择一个或多个集群

　　

　　2. k8s-tunnel 将自动打开与 Cloudflare 的连接，并在开发人员机器上公开一个本地 SOCKS5 代理

　　3. k8s-tunnel 通过本地的 SOCKS5 代理推送必要信息，来修改用户本地 Kubernetes 客户端配置

　　4. k8s-tunnel 将 Kubernetes 客户端环境切换到当前连接

　　

　　5. 用户现在可以使用他/她喜欢的 CLI 客户端来访问 K8s 集群

　　整个过程非常简单直接，我们的工程团队每天都在使用。当然，所有这些魔法般的过程都是通过我们在 k8s-tunnels 中建立的自动发现机制实现的。每当有新工程师加入我们的团队时，我们只需让他们启动自动发现流程并开始。

　　下面就是自动发现过程的实际示例。

　　1.k8s-tunnels 将连接到我们不同的云提供商 API，并列出用户可以访问的 K8s 集群

　　2.k8-tunnels 会在这些集群的用户机上保存一个本地配置文件，因此该过程不会多次运行

　　

　　自动化改进

　　对于本地部署来说，这有点棘手，因为我们没有一种简单的方法来存储 K8s 集群元数据，就像我们使用公共云提供商的资源标签那样。我们决定使用Vault作为键值存储，用于模拟本地公共云资源标签。通过这种方式，我们可以按照与公共云提供商相同的过程实现自动搜索本地集群。

　　也许您在之前的 CLI 截图中看到过，用户可以同时选择多个集群！我们很快意识到，我们的开发人员经常需要同时访问多个环境，以比较在生产环境和分阶段中运行的工作负荷。因此，我们设计了这种工具，他们现在可以简单地在单个 K8s-tunnels 实例中并行地打开多个通道，并在笔记本电脑上切换目的地 K8s 集群，而无需每次在切换集群时打开或关闭通道。