如何使用 OPA(开放策略代理)管理您的 API 策略
欢迎联系 Kong 中国合作伙伴咨询详情 consultant@gingxing.com。
API 对于现代应用程序至关重要,但管理和安全策略可能会很复杂。当需要灵活、可扩展和细粒度的控制谁可以访问特定资源时,传统的访问控制机制可能会不足。
这就是 OPA(开放策略代理)发挥作用的地方。OPA 提供了一个统一的框架,用于一致地定义和执行微服务、API、Kubernetes 集群等的策略。
一致的策略管理对于企业至关重要。以下是一些原因:
安全性:限制对敏感数据或操作的访问。
合规性:确保 API 请求符合内部或外部的监管标准(例如,GDPR)。
一致性:为服务提供授权策略的单一真相来源。
敏捷性:随着需求的演变,使 API 策略能够快速迭代和更新。
在本文中,我们将探讨如何使用 OPA 结合 Kong Gateway 有效管理 API 策略。
API 网关作为控制的中心点
API 网关是安全地与企业服务和数据交互的中心入口点。因此,执行访问控制策略、速率限制和其他安全措施是自然的。API 网关成为访问控制策略的单一真相来源,确保一致性并减少配置错误的风险。它也是构建安全和可扩展 API 基础设施的基本构建块。它还使开发人员免于在每个服务中实现这些策略,使他们能够专注于业务逻辑。
让我们通过一个例子来说明这一点。
想象一组提供不同功能的微服务,例如客户管理、产品目录和订单处理。每个微服务都有自己的访问控制逻辑,这可能导致不一致和重复。现在,安全部门定义只有经过认证的用户才能访问这些服务的数据。而不是在每个服务中分发并实施此策略,你可以将它们集中在一个 API 网关中,如 Kong Gateway。
Kong Gateway 可以为所有传入请求执行此策略,确保只有经过认证的用户才能访问服务。为此,它可以与现有的身份管理解决方案(如 Keycloak)集成。
图 1:API 网关作为中心守门员
将 API 网关实现为中央策略层是一个确保 API 之间一致和安全访问控制的好实践。
政策管理需求
然而,随着服务和 API 数量的增长,管理策略可能会变得具有挑战性。随着时间的推移,策略可能会变得复杂且难以管理,特别是关键的细粒度访问控制策略。这些策略通常需要来自外部源的数据来决定用户是否可以访问服务或相应的数据。特别是当策略在服务之间重用或频繁更新时,挑战变得更加严峻。
覆盖这些增强用例所需的逻辑相当动态。它需要更多的逻辑和来自外部源的数据,而实现可能会使 API 网关膨胀。因此,这样的策略逻辑通常在相应的后端服务中实现。
回到我们的示例场景:想象一下,由于合规和数据隐私原因(如 GDPR),安全部门扩展了限制客户和订单数据访问的策略。将来,只有销售代表应该被允许访问这些数据。此外,写入访问权限应被限制,以便销售代表只能编辑他们负责的客户和订单的数据。所有销售代表都允许查看相应的数据。
图 2:在后端服务中实现的 AuthZ 策略逻辑
在这种情况下,策略变得更加复杂,并且必须在客户管理和订单处理服务中实施,如图 2 所示。不同的团队负责这些服务,因此实施必须进行协调和测试。
清单 1:AuthZ 策略伪代码
这种概述的方法可能导致重复和不一致。此外,服务可能无法遵守公司政策或法规。同样,它们更难以维护和更新。
将像 Open Policy Agent (OPA)这样的独立策略引擎与 Kong 网关集成,可以让您从后端服务中卸载策略决策,确保一致性和细粒度的访问控制。
使用 OPA 进行策略管理
OPA 是一个开源的通用策略引擎。它可以将策略决策与服务逻辑解耦,使得管理维护复杂的决策(如访问控制)变得更加容易。OPA 使用 Rego 语言评估策略,这是一种声明式语言,并提供 REST API 来管理策略和查询策略决策。
OPA 提供了一种灵活而强大的方式来定义可以在服务之间重用的策略。它允许你根据各种属性定义策略,例如用户角色、请求方法、头信息等。这使得创建细粒度的访问控制策略变得容易,并且可以轻松更新和维护。
OPA 与 Kong 网关、微服务或其他需要策略决策的任何服务并行运行。它接收请求,根据你在 Rego 中定义的策略进行评估,并返回允许/拒绝决策。这样做确保了在所有服务中一致地执行策略。此外,你可以轻松地更新和测试策略,而无需重新部署你的服务。而且,你可以独立于服务对策略进行版本控制,从而实现更敏捷的策略管理过程。
OPA 与 Kong API 网关
如前所述,OPA 可以与 Kong 网关集成,为你的 API 提供细粒度的访问控制。但这意味着什么,它是如何工作的,以及有什么好处呢?
当企业实施 OPA 和 Kong 网关的组合方法时,API 管理的好处包括:
细粒度的访问控制
分布式系统和微服务的可扩展性
声明式策略语言(Rego)
应用程序各个层面的一致性(API、Kubernetes、数据库等)
将 OPA 集成到现有架构中是直接的。OPA 提供了用于管理策略和从策略引擎请求策略决策的 REST API。将 OPA 与 Kong 网关集成甚至更简单,因为 Kong 提供了一个 OPA 插件,允许你将授权决策委托给 OPA。Kong 的 OPA 插件充当 Kong 和 OPA 之间的桥梁。对于熟悉 Kong 插件机制的开发者来说,配置是直观的。
关于我们的例子,建立这种方法有助于将复杂的策略逻辑与网关配置分离。如图 3 所示,策略开发人员可以在 Rego 中定义新的策略,如清单 1 中的伪代码所示。一个关键的事实是,策略开发人员不一定是服务开发人员,但可能是安全团队的一部分。这种职责分离允许更敏捷的开发过程,因为策略可以独立于服务进行更新和测试。
图 3:OPA 与 Kong API 网关集成
开发完成后,可以在本地独立于服务之外测试和验证策略。最后,当策略准备就绪时,可以部署到 OPA。
CI/CD 管道可以自动化验证、测试和部署策略到 OPA。采用 GitOps 方法,可以全面版本化策略并完全了解策略的演变。这对于合规和审计目的非常重要。这也是以 GitOps 方式管理策略的一致方法,就像我们对应用程序代码、基础设施和 API 生命周期(APIOps)所做的那样。
在将新策略部署到 OPA 之后,可以配置 Kong 使用 Kong OPA 插件将授权决策委托给 OPA。
结论
在法规和合规要求日益增加的时代,清晰了解你的政策至关重要,以避免重复。此外,建立明确的政策管理责任并定义修改测试和版本政策的过程也很重要。另外,政策的变更应该有详尽的文档记录。清楚了解可用的政策及其使用位置,可以进一步增强安全性和合规性,并帮助避免配置错误。
将 OPA 作为构建块添加到你的 API 管理平台中,对于解决现代高度分布式架构中的这些挑战是必不可少的。它允许你以结构化的方式在中心位置管理所有政策,并允许在不同层面上进行可见性。在 API 网关层面,你可以看到哪些端点受到保护,它们是如何被保护的,以及哪些政策正在执行。在 OPA 层面,你可以看到定义了哪些细粒度的政策,以及它们是如何进行版本控制和实施的。
今天就开始控制你的政策管理。在你的 API 管理平台中实施 OPA,以确保一致的执行,获得完全的可见性,并简化所有服务的合规性。不要让政策配置错误损害你的安全——现在就开始构建一个现代化、有弹性的架构吧。
想了解更多关于 Kong AI Gateway 的信息吗,欢迎联系 Kong 中国合作伙伴 consultant@gingxing.com 沟通。
评论