【翻译】什么是 "政策即守则"？

身份很容易。毕竟，每个人都有一个。认证？可能就更不复杂了。任何使用智能手机的人每天都要认证几十次才能使用它，这甚至还没有涉及银行、工作或社交媒体所需的远程服务。也许正是这种明显的简单性吸引了我在大约五六年前进入身份系统的世界。

在这之前的几年里，我主要从事产品或服务的开发工作，在那里，我们开发人员的一个共同主题是被告知需要做什么的一些模糊描述，然后花上几天或几周的时间尽力去做这件事。只有当我们完成时，我们才会发现我们所做的并不是真正的要求，我们需要花大量的时间来重构我们所建立的东西，以支持这些改变或额外的要求。在冲刺结束时，我们会有礼貌地抱怨，如果我们幸运的话，事情会改善一段时间，然后在几周后恢复原状。

不过你可以放松一下，这篇博客并不是要讨论敏捷、Scrum或其他一些方法论如何解决这个挑战。相反，这篇文章的重点是我们如何以开放政策代理（OPA）的形式达成一个开源的解决方案，满足我们以代码形式处理政策的所有目标。但首先，一些背景。

有一天，我的团队被赋予了新的职责。我们已经工作了一段时间的现代API将被移交给一个新的团队，而我们被分配了一个非同小可的任务，即建立一个急需的新身份平台--它将取代目前正在尝试这样做的少数几个传统平台。一些要求包括有一个单一的用户ID概念和一个平台来处理跨越几十个不同的产品和系统的单点登录（SSO）认证。

这对我们来说意味着所有的变化，其中一个更有趣的变化是引入了标准工作。我们可能都在某种程度上与他们合作过，但直到那一刻，我们才真正与他们紧密合作。以前我们处理的是模糊的要求和松散的规格，现在我们面对的是所有这些文件，它们会准确地说明什么是对的，什么是错的。矛盾的是，这一切的严格性是一种解放。

在几个月的时间里，我们都沉浸在规范和标准文件中，学习如何使用OAuth2获取访问令牌，OpenID Connect 如何为我们的应用提供急需的身份层，以及SCIM如何在不同的身份后端存储中简化和标准化身份。从我们所学到的知识中，我们能够建立一个身份系统，在未来的许多年里为公司服务。

第一次发布的日子最终到来了，奇迹般地，一切似乎都在运转。人们将通过前端登录，身份系统将在后端发出令牌，然后这些令牌将在我们的产品和服务中传输，以识别请求背后的用户或服务。虽然我们在接下来的几年里肯定有积压的改进工作，但所有这些标准中描述的基本功能是存在的。

授权的价值

那么，现在怎么办？有了一个运行良好的认证系统，以及明确定义了如何在服务和系统间传输所产生的身份数据的标准，我们将何去何从？

虽然我们在项目期间成功地避免了这个问题，但房间里的大象显然是授权问题。有了所有这些标准来帮助我们回答你是谁 （即认证），似乎没有什么类似的东西来告诉我们你能做什么（即授权）。我们在这个领域能找到的一点东西都很古老，感觉像是从单体时代涌现出来的东西，与我们一直在构建的分布式、基于微服务的云原生应用相去甚远。

如果说在我们合作的身份系统中，有一个概念是我们最看重的，那就是授权。委托本质上是一种优雅的说法："不是我的问题！"当面临真正的挑战时，谁会不喜欢这样说呢？对于认证，这基本上意味着服务可以将认证的责任完全委托给身份系统。在授权方面是否存在类似的情况？

虽然委托认证和委托授权之间有一些明显的区别，但这些区别似乎都不是不可逾越的。一个关键的区别是，虽然认证的结果是一个可以跨系统使用的身份，但授权政策往往对所涉及的服务更具有地方性。被授予访问系统X的权限理所当然地会被系统Y所拒绝。

政策就是代码？不，谢谢!

这种地方性的要求导致开发者把他们服务的授权策略尽可能地靠近服务，还有什么能比服务本身的代码更接近呢？

然而，这种耦合是有代价的。嵌入在应用程序代码中的政策不容易被共享，甚至不容易被讨论，跨团队和产品。即使是对组织中所有不同的编程语言和框架有足够了解的开发者，也无法从无关的业务逻辑中指出特定政策的代码，即使有人能做到，所涉及的努力程度也意味着它从未真正发生。"作为代码的政策"--或者说，"代码中的政策"--在这个意义上，正是我们试图避免的！

然而，将授权逻辑或组织政策编码化，肯定比将其保存在PDF文件、Word文档或Jira票据中要好。但是，如果政策代码与应用程序代码和无关的业务逻辑混合在一起，这很可能意味着我们需要同时拥有 "原始 "政策文件和代码中相同政策的实现。让它们保持同步是很容易出错的，而且随着时间的推移，它们必然会渐行渐远。

任何程序员都可能见过代码中的注释，这些注释并不反映代码实际在做什么。虽然在这种情况下，这些类型的不准确可能是灾难性的，当应用于组织的政策时，甚至当政策是为了反映国家或国际法律所执行的要求时，更是如此。

我们真正想要的是--也是我们后来发现的 "政策即代码 "的真正含义--政策代码确实是代码，但这些代码可以很容易地与应用程序代码和业务逻辑分开并解耦。我们只是不知道该去哪里找。

委托授权？

将策略代码与我们的应用程序耦合在一起会产生一个更糟糕的后果：在部署后对策略的任何改变

都需要更新应用程序代码，然后再重新部署。虽然这对单体应用来说可能是可行的，但在基于微服务的架构中，这显然是个问题。如果有成百上千的服务，在这些服务中共享一些组织性的政策，同时允许各个服务在上面添加自己的政策，那该怎么办？

在任何足够复杂的系统中，最大的挑战之一将是管理变化。涉及的服务和系统越多，或者人员和团队越多，变革的成本就越高。委托认证模式通过说 "变化由身份系统内部管理 "来逃避这个问题，而微服务模式则把这个责任委托给管理服务的各个团队。

分布式授权似乎在这两种模式之间划出了一条矛盾的界线，我们会发现自己想要集中一些责任，同时又允许服务具有独立性，而这正是开发者对微服务模式的期望。这当然不是一件容易的事！

通往OPA的漫长道路

我们越是试图想象现代授权解决方案的样子，它就越是遥远。最终，我们放弃了这个想法。把解决授权问题的责任下放给开发团队，意味着即使这个解决方案从更高层次的角度来看并不是很好，也不会直接影响我们与身份系统的合作，因为这被认为是一个有点孤立的领域。我们已经有效地设法采用了 "不是我们的问题！"的方法，我们希望我们的架构是这样的。

直到几年后在巴塞罗那举行的KubeCon会议，我才想起这一点。那里的一些演讲围绕着在Kubernetes API周围建立强大的护栏，让Kubernetes接纳控制器在决定是否允许集群中的状态变化时咨询外部政策引擎。这个策略引擎的名字是Open Policy Agent（OPA），它显然是Kubernetes世界中一个相当流行的开源项目。

现在我有一半的时间是在一个以Kubernetes为重点的平台团队工作，这似乎很有趣。会议结束后，我开始了一个小的概念验证，以探索Kubernetes的这个策略引擎的能力，结果发现它不仅做到了这一点，而且它似乎为我几年前挣扎过的授权问题提供了一个几乎完美的解决方案。

政策即代码？是的，请！

OPA通过发明一种自己的政策语言，解决了 "政策即代码的悖论"：Rego。起初，这似乎会增加很多复杂性，并且需要投入大量的时间。然而，最初的投资很快就会得到回报，因为政策--在某种程度上，复杂性--现在可以与不相关的业务逻辑解耦和隔离了。

为单个系统这样做确实很昂贵，但随着每个系统的加入，越来越明显的是，许多政策逻辑确实是通用的。事实上，这种方法不仅可以降低系统的总复杂度，而且还可以让人们在跨越多个团队、部门或地理边界的大型组织中轻松推理政策。

Rego提供了一种声明式的语言，我们能够描述诸如 "如果用户是Y组的成员，或者拥有Z角色，则允许用户X访问 "这样的策略，而不需要深入了解应该如何做。只要Rego所处理的数据的结构可以用JSON或YAML表示，策略编写就是一件合理的事情。此外，内置的功能，如验证和解码JSON网络令牌，使OPA与已经到位的身份系统完美匹配。

委托授权

下一个，也可以说是更大的问题，OPA解决的正是我们一直在纠结的 "委托授权 "情况。OPA在微服务环境中的分布模式意味着，每个服务的实例都有自己的OPA小实例，就在它旁边运行。这些实例可以自由地将本地策略和数据与集群中多个系统共享的共同策略代码结合起来，并通过OPA可能使用的管理API之一进行分发，以允许集中的策略管理，如果这样做有意义的话。

如果我们还没有被说服的话，OPA软件包中的最后一个小细节会让我们更加惊讶。OPA不仅解决了我们一直在挣扎的微服务授权问题，而且，正如在巴塞罗那展示的Kubernetes接纳控制器用例所显示的那样，将政策与执行脱钩的概念可以应用于几乎任何领域。不久之后，我们就开始研究将OPA用于我们的Kubernetes集群，我们的基础设施即代码项目，以及我们的部署管道。

高标准

虽然OPA本身不是一个标准，但它允许策略作者利用任何普遍的机制来处理授权问题（其中一些有相关的标准），如访问控制列表（ACL），以及基于角色或属性的访问控制（RBAC/ABAC）。 你可以完全使用OPA来建立你自己的策略框架。它甚至不一定非得是关于授权的！尽管我以前很喜欢用标准来工作，但我当然知道在这种情况下，这种模式的局限性比它的解放性更大。

加入社区

我们已经看到了我们需要看到的一切。虽然我们还有一些工作要做，但事实证明，OPA正是我们多年前所设想的，但却未能描述的。OPA设法完美地体现了 "政策即代码 "的整个概念，这是我们从未接近过的系统。

如果OPA没有开源，也许其他竞争者会站出来迎接挑战。相反，我们看到，围绕着OPA，一个充满活力的社区正在成长，一个由适应性、集成性和插件组成的繁荣的生态系统，随着时间的推移，越来越大，越来越好。今年是我作为OPA社区活跃成员的第三个年头，我不会离开这里！

那么，你可以从哪里开始呢？我通常的建议是简单地开始。在你建立的现有服务或应用中找出几个非正式的策略，并考虑用Rego和OPA重写它们。在你探索Rego的过程中，请确保打开优秀的OPA文档的标签，并加入OPA Slack，看看社区中的其他人正在研究或可能正在挣扎的内容。要想真正深入了解Rego，并将你的技能提高到一个新的水平，请查看Styra学院。

希望我的故事能够帮助大家了解将策略正式化为代码所解决的问题类型，以及将策略决策与应用程序和服务的业务逻辑解耦的好处。无论是基础设施还是授权，Kubernetes还是构建管道，OPA都提供了一种统一的策略工作方式，其重要性只会随着你的组织和技术堆栈而增加。

你的"政策即代码 "之旅从哪里开始？