Kubernetes 中 API 安全加固
使用 Kubernetes 部署容器化应用程序时,必须考虑应用程序所依赖的基础设施。在 Kubernetes 中保护应用程序或 API 时,请确保考虑云原生安全的 4C:云、集群、容器、代码。
遵循其中每一点的最佳实践可确保应用程序在安全环境中运行。这样的环境具有监控和避免各级意外行为的控件和组件,包括 Kubernetes 生态系统及其管理。
本文主要关注应用程序安全,讨论了入口控制器在 Kubernetes 中的作用(作为实现保护 API 最佳实践的一部分)。
提供单一入口点
默认情况下,pod 的端口不会暴露在 Kubernetes 集群之外。pod 可以通过服务进行分组,这些服务可以配置为公开 internet 上的端口。然而,服务资源是一个简单的组件。即使与负载均衡器结合使用,该设置也缺乏灵活性和适应性。另一方面,入口控制器提供了企业用例所需的许多功能,如基于名称的服务虚拟主机、路径映射、代理、响应缓存,最重要的是,还提供了身份验证或 TLS 终止等安全功能。
入口控制器为集群的单个入口点入口实现规则。作为该实现的一部分,入口控制器通常提供一系列安全功能。例如,NGINX 入口控制器支持 SSL 重定向、HTTP 严格传输安全(HSTS)或 HTTP 头过滤。根据入口控制器的选择,它甚至可以提供 API 网关的功能,如速率限制、聚合、监控或开发人员门户。一些入口控制器,如 Kong 入口控制器或 Tyk Operator,通过与 API 网关紧密集成,利用 Kubernetes 中的 API 网关功能。此外,三大云提供商提供云原生 Kubernetes 入口控制器,即 AWS 负载均衡器控制器、Azure 中的应用网关入口控制器和 GKE 入口控制器。
在 Kubernetes 中公开 API 时,使用入口控制器作为守门来保护集群中的所有服务。根据需求和以下最佳实践选择功能。
限制访问
作为单一入口点,入口控制器是实施身份验证和授权等安全策略的理想场所。这是一个常见的要求,入口控制器通常通过 OAuth 2.0 和 OpenID Connect 等开放标准提供身份验证支持。选择开放标准而不是专有解决方案是一种很好的做法,因为它支持互操作性和可移植性。当使用 OAuth 2.0 或 OpenID Connect 时,入口控制器可以在外围验证令牌。它还可以基于令牌中的数据(如颁发者、范围和受众参数)执行粗粒度访问控制,从而卸载 API。
在微服务架构中,一个服务可以调用另一个服务来满足请求。实际上,在返回响应之前可能会有一个完整的调用链。但是,并非链中的所有服务都需要相同的权限。因此,请确保令牌具有足够的权限。考虑令牌共享机制,以避免令牌过载,从而包含下游服务调用中可能需要或不需要的所有可能权限(作用域和声明)。
例如,让 OAuth 2.0 或 OpenID Connect 服务器发出包含另一个嵌入令牌的令牌,该令牌可用于下游服务调用。然而,这意味着令牌服务器必须事先知道要生成和嵌入哪些令牌。要做到这一点,它必须事先知道将调用哪些其他服务。在复杂的设置中,此要求可能很难维护。另一种更灵活的方法是令牌交换,即可以将现有令牌交换为新令牌。该协议类似于虚拟令牌方法,但它没有改变格式,而是改变了部分内容。
无论采用何种方法,转发定制令牌都是实现最小特权原则的一部分。最小特权原则减少了总体攻击面,因为利用特权和访问不应授予的服务和数据变得更具挑战性。
在成熟的设置中,入口控制器或 API 网关用于协调不同的微服务,它还将负责执行令牌交换。
不要相信任何人
最好的做法是不停在外围,而是实现零信任架构。确保集群中的所有服务请求都经过身份验证。服务网格在基础设施级别提供了这种方法。此外,OAuth 2.0 和 OpenID Connect 提供了应用程序级安全性工具。设计用于 API 中细粒度授权的访问令牌。
JSON Web 令牌(JWT)是访问令牌的流行格式。它们非常有用,因为它们支持零信任架构和自包含令牌。然而,如果未加密,此类令牌可能包含恶意参与者可以轻松解析的敏感数据。因此,JWT 只能在集群内使用。这被称为 Phantom Token 方法。
选择一个可扩展的入口控制器,以允许自定义和实现规则,例如 Phantom Token 方法或令牌交换所隐含的规则。它应该支持脚本功能或插件。后者更容易,因为你可以简单地添加和配置插件,而无需编写代码。特别是,你可以依靠安全专家的工作来获得与安全相关的插件。例如,使用为 NGINX 或 Kong 提供的插件来添加对 Phantom Token 方法的支持。但即使是脚本和配置也可以共享并用于分发零信任架构的安全最佳实践。
最佳实践一览
简而言之,在 Kubernetes 中保护 API 时,请考虑以下几点:
——使用入口控制器(或 API 网关)保护 Kubernetes 中 API 的所有服务。
——在外围执行粗粒度授权,并将细粒度决策留给 API。
——仔细设计令牌,并在需要时进行交换,以满足最小特权原则。
——依靠标准协议并使用可扩展性特性来实现零信任架构。
版权声明: 本文为 InfoQ 作者【CTO技术共享】的原创文章。
原文链接:【http://xie.infoq.cn/article/07b66fb5ca59fe16ac3a9fb29】。未经作者许可,禁止转载。
评论