开放式策略代理(OPA)可以帮助企业简化分布式应用程序、Kubernetes、微服务等授权策略创建和实施。

随着越来越多的组织采用云计算技术，他们可能会发现云原生堆栈的动态性和规模要求更加复杂的安全性和合规性。例如，随着像Kubernetes这样的容器编排平台越来越受关注，开发团队和开发人员对策略领域(如准入控制)以及更传统的领域(如计算、存储和网络)负有新的责任。与此同时，每个应用程序、微服务或服务网格都需要自己的一组授权策略，开发人员需要为这些策略负责。

出于这些原因，很多组织开始寻找一种更简单、更省时的方法来在云中创建、实施和管理策略。作为一个开源的、不受领域限制的策略引擎，开放策略代理(OPA)于4年前创建，正在成为云原生策略的实际标准。事实上，Netflix、Pinterest和Goldman Sachs等公司已经将OPA投入生产，用于Kubernetes准入控制和微服务API授权等用例。OPA还支持许多人们已经知道和喜欢的云原生工具，其中包括Atlassian套件和Chef Automate。

OPA为云计算原生组织提供了一种统一的策略语言，因此授权决策可以用一种通用的方式表示，跨应用程序、API、基础设施等，而不必将定制的策略分别硬编码到这些不同的语言和工具中。此外，由于OPA是专门为授权而构建的，它提供了越来越多的性能优化集合，因此策略作者可以将大部分时间花在编写正确、可维护的策略上，并将性能留给OPA。

OPA授权策略在整个堆栈中有许多用例，从在容器编排周围设置护栏，到控制SSH访问或提供基于场景的服务网格授权。有三个流行的用例为许多OPA用户提供了一个良好的启动平台：应用程序授权、Kubernetes许可控制和微服务。

申请授权的OPA

授权策略无处不在，因为几乎每个应用程序都需要它。但是，开发人员通常自己开发代码，这不仅耗时，而且会导致难以维护的工具和策略拼凑而成。虽然授权对每个应用程序都很重要，但花在创建策略上的时间意味着更少的时间关注面向用户的功能。

OPA使用专用的声明性策略语言来简化授权策略的开发。例如，企业可以直接创建和执行策略，例如，“如果是承包商，则无法阅读PII”或“Jane可以访问此帐户”。但这只是一个开始。由于OPA具有场景意识，因此还可以制定考虑任何事物的政策，例如，在交易日的最后一小时请求进行股票交易，这将产生上百万美元的交易，只能在给定名称空间中的特定服务上执行。

当然，许多组织已经有定制的授权。但是，如果组织希望在云中分解应用程序并扩展微服务，同时又保持开发人员的效率，那么就需要分布式授权系统。

用于Kubernetes接纳控制的OPA

许多用户还使用OPA为Kubernetes创建防护栏。Kubernetes本身已成为主流和关键任务，组织正在寻找定义和实施安全护栏以帮助减轻安全和合规风险的方法。管理人员可以使用OPA制定清晰的策略，以便开发人员可以加快管道生产，并迅速将新服务推向市场，而不必担心运营、安全或合规风险。

OPA可用于创建策略，以拒绝使用相同主机名的入口，或要求所有容器映像来自可信注册表，或确保所有存储始终使用加密位进行标记，或确保暴露在互联网上的每个应用程序使用经批准的域名。

由于OPA直接与Kubernetes API服务器集成，因此它可以拒绝跨计算、网络、存储等策略禁止的任何资源。对于开发人员特别有利的是，组织可以在开发周期的早期公开这些策略，例如在持续集成(CI)/持续交付(CD)管道中，以便开发人员可以及早获得反馈，并在运行时修复问题。此外，组织甚至可以带外验证其策略，以确保它们达到预期的效果，并且不会在无意中引起麻烦。

微服务的OPA

最后，OPA在帮助组织控制其微服务和服务网格架构方面变得非常流行。借助OPA，组织可以直接为微服务创建和实施授权策略(通常是作为辅助工具)，在服务网格内构建服务策略，或者从安全的角度创建限制服务网格架构中横向移动的策略。

为云原生架构构建统一策略

通常，使用OPA的总体目标是创建一种跨云原生堆栈创建策略的统一方法，因此，组织不必通过广告、部落知识、维基百科、PDF或大量不匹配的工具来持续管理策略。

除了简化开发和加快交付速度之外，这对于安全性也是一个重大新闻，因为OPA减少了组织需要检查的工具数量，例如组织是否怀疑自己曾尝试未经授权的访问。同样，从操作和合规性角度来看，OPA使得在异构环境中提取和分析信息变得更加容易，从而帮助组织快速发现问题并更快地解决。

开发人员正在寻找一种更简单、更有效的方法来为他们的云原生环境创建和管理基于策略的控件。对许多人来说，这种解决方案就是OPA。如果组织发现自己在多个地方、多种语言或跨多个团队接触授权策略，OPA可以帮助其消除冗余并加快交付速度。