随着您的组织拥抱云，您可能会发现云原生堆栈的动态性和规模需要更加复杂的安全性和合规性。例如，随着像Kubernetes这样的容器编排平台越来越受关注，开发人员和开发人员团队对策略领域（如准入控制）以及更传统的领域（如计算，存储和网络）负有新的责任。同时，每个应用程序，微服务或服务网格都需要一套自己的授权策略，开发人员对此很有帮助。
出于这些原因，我们开始寻找一种更简单，更省时的方法来在云中创建、实施和管理策略。OPA（输入开放策略代理）于4年前创建，它是一个与域无关的开源策略引擎，正在成为云原生策略的事实上的标准。事实上，OPA已经被Netflix，Pinterest和Goldman Sachs等公司用于生产，用于Kubernetes准入控制和微服务API授权等用例。OPA还支持许多您已经知道和喜欢的云原生工具，包括Atlassian套件和Chef Automate。
OPA为云原生组织提供了统一的策略语言，这样，就可以在应用程序、API、基础架构等中以通用的方式表达授权决策，而无需将定制的策略硬编码到每种不同的语言和工具中。此外，由于OPA是为授权而专门设计的，因此它提供了越来越多的性能优化集合，因此策略作者可以将大部分时间用于编写正确，可维护的策略，并将性能留给OPA。
OPA授权策略在堆栈中有很多很多用例-从在容器编排周围放置防护栏到控制SSH访问或提供基于上下文的服务网格授权。但是，有三种流行的用例为许多OPA用户提供了良好的启动平台：应用程序授权，Kubernetes准入控制和微服务。
申请授权的OPA
授权策略无处不在，因为几乎每个应用程序都需要授权策略。但是，开发人员通常会“滚动自己的”代码，这不仅耗时，而且会导致难以维护的工具和策略拼凑而成。尽管授权对于每个应用程序都是至关重要的，但是花在创建策略上的时间意味着更少的时间集中在面向用户的功能上。
OPA使用专用的声明性策略语言来简化授权策略的开发。例如，您可以创建和强制执行简单的策略，例如“如果您是承包商，则不能阅读PII”或“ Jane可以访问此帐户”。但这仅仅是开始。因为OPA具有上下文感知能力，所以您还可以制定考虑地球上任何事物的策略，例如，“在交易日的最后一小时请求进行股票交易，这将导致超过一百万美元的交易，只能在以下时间执行：给定名称空间中的特定服务。”
当然，许多组织已经有定制的授权。但是，如果您希望在云中分解应用程序并扩展微服务，同时又保持开发人员的效率，那么就需要分布式授权系统。对于许多人来说，OPA是缺少的拼图。
用于Kubernetes接纳控制的OPA
许多用户还使用OPA为Kubernetes创建防护栏。Kubernetes本身已经成为主流和关键任务，并且组织正在寻找定义和实施安全护栏以帮助减轻安全和合规风险的方法。管理员可以使用OPA制定清晰的策略，以便开发人员可以加快管道生产并迅速将新服务推向市场，而不必担心运营，安全或合规风险。
OPA可用于创建策略，以拒绝使用相同主机名的入口，或者要求所有容器映像都来自受信任的注册表的策略，或者确保始终用加密位标记所有存储，或者确保每个应用公开互联网上使用批准的域名-仅举几个例子。
由于OPA直接与Kubernetes API服务器集成，因此它可以拒绝跨计算，网络，存储等策略禁止的任何资源。对于开发人员特别有利的是，您可以在开发周期的早期（例如在CI / CD管道中）公开这些策略，以便开发人员可以及早获得反馈并在运行时修复问题。此外，您甚至可以带外验证策略，以确保它们达到预期的效果并且不会无意中引起麻烦。
微服务的OPA
最后，OPA在帮助组织控制其微服务和服务网格体系结构方面变得非常流行。借助OPA，您可以直接为微服务创建和实施授权策略（通常是作为补充工具），在服务网格内构建服务到服务策略，或者从安全角度出发，创建限制服务网格内横向移动的策略。建筑。
为云原生架构构建统一策略
一般而言，使用OPA的总体目标是创建一种统一的方法来跨您的云原生堆栈创建策略-因此，您不必通过广告、部落知识、百科和PDF的临时混合，或一堆错配的工具。
除了简化开发和加快交付速度外，这对于安全性也是一个重大新闻，因为OPA减少了您需要检查的工具数量，例如，您是否怀疑是否尝试了未经授权的访问。同样，从操作和合规性角度来看，OPA使得在异构环境中提取和分析信息变得更加容易-帮助您快速发现问题并更快地解决问题。
开发人员正在寻找一种更简单，更有效的方法来为其云原生环境创建和管理基于策略的控件。对于许多人来说，该解决方案就是OPA。如果您发现自己在多个地方，使用多种语言或在多个团队中接触授权策略，OPA可以像为他们一样帮助您消除冗余并加快交付速度。
