每种产品或服务都有独特的策略和授权处理方式：谁可以做什么以及什么可以做什么。在云原生世界中，授权和策略比以往任何时候都更加复杂。随着云原生生态系统的发展，DevOps 和 DevSecOps 团队越来越需要在开发和部署周期的早期识别和解决安全和合规性问题。企业需要在几分钟（而不是几个月）内发布软件。为了实现这一目标，过去以 PDF 或电子邮件形式编写的那些安全和合规性策略需要由机器检查和执行。这样，每隔几分钟软件发布时，它都遵守所有必要的策略。
当我们与 Teemu Koponen、Torin Sandall 共同创立 开放策略代理项目 (OPA) 时，这个问题一直是我们首要考虑的问题，旨在为云原生生态系统的关键安全和策略挑战提供实用的解决方案。随着 OPA 成功集成的列表不断增长（这要归功于开源社区的积极参与），现在是时候重新介绍 OPA，并了解它如何在各种环境中解决业务和策略痛点。
什么是 OPA？
OPA 是一个通用策略引擎，它使策略成为云原生生态系统中的一等公民，使其与服务器、网络和存储处于同等地位。它的用途范围从授权和准入控制到数据过滤。社区将 OPA 用于所有主要云提供商以及本地部署的 Kubernetes 准入控制，以及 HTTP API 授权、远程访问策略和数据过滤。由于 OPA 的 RESTful API 使用基于 HTTP 的 JSON，因此 OPA 可以与任何编程语言集成，使其在各种服务中都非常灵活。
OPA 为策略提供了自己的生命周期和工具集，因此策略可以与其应用的底层系统分开管理。OPA 于 2016 年启动，提供本地强制执行，以实现更高的可用性、更好的性能、更大的灵活性以及比硬编码服务逻辑或临时特定领域语言更强的表达能力。凭借针对新用户和经验丰富的从业者的专用工具，以及与第三方系统的众多集成，OPA 使管理员能够在整个软件堆栈中实现统一、灵活和精细的策略控制。OPA 还围绕 Kubernetes 准入控制、HTTP API 授权、授权管理、远程访问和数据过滤提供策略护栏。2018 年，我们将 OPA 捐赠给了 云原生计算基金会，一个供应商中立的家园，此后它已从沙箱阶段毕业到孵化阶段。
OPA 在现实世界中能做什么？
简而言之，OPA 为云原生环境提供统一的、上下文感知的策略控制。OPA 策略是上下文感知的，这意味着管理员可以根据现实世界中发生的事情做出策略决策，例如
- 当前是否发生中断？
- 是否发布了新的漏洞？
- 现在谁在值班？
它的策略足够灵活，可以适应任意上下文和任意。OPA 已在一些世界上最大的云原生部署中得到生产验证——从管理着数万亿美元资产的全球金融公司到技术巨头和家喻户晓的名字——但也已在新兴的初创公司和区域医疗保健组织中使用。
除了我们自己的直接经验之外，还得益于开源社区的创新，OPA 继续成熟并解决各种不断发展的客户授权和策略问题，例如 Kubernetes 准入控制、微服务授权以及面向最终用户和面向员工的应用程序的授权管理。我们对眼前展开的创新用例的深度和广度感到兴奋。为了更好地阐明 OPA 正在解决的一些实际问题，我们研究了用户社区中 OPA 的关键业务部署，以提供以下示例。
提供基于角色的访问控制 (RBAC) 无法提供的法规遵从性。
这个教训来自一家管理着数万亿美元资产的全球银行。他们的问题：由于第三方经纪人拥有过多访问权限而发生的违规行为。银行与公众的关系承受着巨大的压力，并且还被处以近 1 亿美元的罚款。
这样的违规行为是如何发生的？简而言之，由于试图将数十年的基于角色的访问控制 (RBAC) 映射到每个庞大的单体应用程序的复杂性。由于数千个内部和外部应用程序中存在数百万个角色，因此银行的情况（与大多数大型成熟公司的情况一样）变得无法管理或排除故障。最初作为最佳实践 (RBAC) 的东西不再能够扩展。基于业务逻辑的静态角色无法进行测试。它们无法内联部署。它们无法像今天的现代代码那样进行验证。简而言之，RBAC 无法单独管理云规模的访问。
OPA 促进了一个解决方案：通过本地的基于上下文的授权来重新设计和简化应用程序访问，该授权是自动化的、经过测试的、经过审计的并且可扩展的。这种方法既有技术优势，也有业务优势。主要的技术优势是授权策略（确定给定用户可以做什么的规则）是作为持续集成和持续交付 (CI/CD) 的一部分构建、测试和部署的。每个决策都直接与微服务和应用程序相关联，以进行审计和验证，并且所有访问都基于当前上下文，而不是角色。
无需创建数千个角色来涵盖允许的每种排列组合，一个简单的策略就可以确定用户是否应该具有访问权限，并且可以非常精细地确定。由于上下文驱动访问决策，因此这种简化的策略大大简化了操作。由于每次需要新策略时都会重新创建整个策略集，从而消除了嵌套问题和遗留角色蔓延，因此不需要版本控制和回溯测试。本地策略还消除了存储库中冲突的规则/角色的存在。
主要的业务优势是，通过职责分离（由安全团队而不是开发人员编写策略）以及提供对跨应用程序的访问策略的清晰、可测试的可见性，合规性变得更容易。此过程加快了开发速度，因为 AppDev 团队无需直接将 Authz 或策略编码到应用程序中，并且不再需要更新、维护和提供中央 RBAC 存储库。
默认情况下提供法规遵从性和安全性。
另一家拥有近 20,000 名员工的大型银行也面临着使用电子表格管理策略的站不住脚的局面。这种情况听起来可能很滑稽，但它比您想象的要常见得多。访问通常通过尽力而为和部落知识来“管理”。团队将访问策略记录在 PDF、Wiki 或电子表格中。然后，他们依靠善意的开发人员来阅读、理解和记住访问规则和指南。该银行有业务理由从单体应用程序转向 Kubernetes (K8s)——主要是提高差异化和上市时间——但其遗留的合规性解决方案与 K8s 不兼容。
银行知道，虽然它是一家金融机构，但它实际上是一家软件组织。员工们没有依赖人类记忆和尽力而为，而是开始以 GitOps 思维模式（拉取请求、评论和同行评审以达成共识和承诺）来考虑策略。OPA 成为策略背后允许（或不允许）的单一事实来源，实施了真正的策略即代码解决方案，由于自动化，工作量完全从等式中消除。
银行创建的 K8s 平台默认情况下是合规的，因为它每次都完全执行公司法规策略。借助 OPA，银行可以通过敏捷流程构建、部署和版本化其法规策略，确保所有用户、团队和服务始终遵守策略。现在基础设施是合规的，因为合规性实际上已构建到基础设施中。
简化和加强机构知识。
一家大型电信公司遇到了一个教育问题，这个问题正在消耗时间和金钱。其痛点：它创建并维护了自己的准入控制 (AC) 服务；拥有缓慢、昂贵、人力资源密集型的支持模式，无法随着其开发人员群体的增长而扩展；并且它拥有像锤子一样的强制执行模式，效率低下，减慢了上市时间。
部署 OPA 是为了取代自定义 AC，从而节省资源。OPA 提供的护栏允许管理层发现和部署他们从世界事件（和问题）中制定的关键策略，他们希望消除这些策略以向前发展。
管理层现在已经习惯于使用策略即代码，并且能够专注于开发人员最常遇到的特定策略。这家公司的主要好处是节省了人员工时，因为不必一遍又一遍地与相同的开发人员谈论相同的问题，并且能够自动教育和执行策略。从这些努力中获得的见解使公司能够有针对性地对需要帮助的团队进行教育（而不是强制执行），主动关注为苦苦挣扎的团队提供帮助。
了解有关 OPA 的更多信息
要了解如何使用 OPA 来帮助您进行授权和策略，或者了解如何贡献，请查看 Github 上的开放策略代理，或查看 OPA 主页上关于不同用例的教程。
评论已关闭。