为了让人们的工作和生活更轻松，需要了解构建云原生权限带来的独特挑战，并了解构建云原生权限的五个最佳实践，这些实践可以为开发人员减少很多麻烦。
应用程序和访问权限已更改
开发人员在过去使用带有授权或访问控制的单一框架(如Django或Spring)来构建授权，但当创建云原生应用程序时，这些不再适用。
这有几个原因：
- 首先，应用程序本身不再是单一的——它们基于微服务并且正在变得高度分散。当开发人员需要合并部署在边缘，并且通常也需要访问控制的设备或实例时，这一点也值得引起注意。
- 其次，云原生应用程序往往需要集成第三方服务(例如计费、身份验证、数据库、分析等)，并且除了开发人员自己的应用程序的微服务之外，还需要能够控制对它们的访问。
- 第三，更加动态和分布式的应用程序需要使用一堆不同的授权模型(例如RBAC、ReBAC、ABAC)，这些模型基于多个数据源和越来越复杂的规则。最后，安全、隐私和合规性需求也在上升(面对日益复杂的网络威胁)并且变得非常复杂。开发人员发现自己不仅要管理谁应该访问数据，还要管理数据在不同服务之间的传播方式。
授权的现实
所有这些新需求都要求在考虑授权时采用不同的思维方式：
- 授权不再是事后事项，必须提前计划。
- 授权是一项持续的努力，而不是一次性解决的问题。它必须与产品一起不断发展。
- 授权是客户体验的关键，因为它会影响用户连接和邀请他人使用产品的方式。如果体验不好，他们不会喜欢。
- 授权连接到更大的身份和访问管理空间。
构建云原生权限的五个最佳实践
为了处理所有这些更改，有一些最佳实践可以帮助开发人员构建云原生权限，并有时间实际开发功能，而不是在处理权限方面不堪重负。
1. 解耦策略和代码
构建云原生权限的最重要实践之一是策略和代码的解耦。将授权层的代码与应用程序代码本身混合在一起可能会产生很大的问题。更重要的是，它造成了在不同微服务之间复制代码时难以升级、添加功能和整体监控代码的情况。每一项更改都需要重构大量代码，这些代码只会随着这些微服务的发展而彼此偏离得更远。
这可以通过(在理想情况下)创建一个单独的授权微服务将策略与代码解耦来避免这种情况，其他服务将使用该微服务来满足它们的授权需求。例如，开放策略管理或Spice DB等开源策略/权限引擎允许开发人员在单独的服务中管理授权。
2. 事件驱动
开发人员希望正在构建的应用程序是动态的。应用程序通常包括用户邀请、角色分配或使用第三方数据源等功能——所有这些都应该实时管理。如果没有这种能力，做出授权决策的能力将显著降低。
这要求开发人员将授权层设计为事件驱动的。他们希望创建一个现实，每次发生影响授权的事件时，它都会立即通过系统传递，以确保授权层了解它，并与应用程序和任何相关的第三方数据服务保持同步。
在理想情况下，为了实现这一点，开发人员将授权数据与应用程序数据分离(因为并非所有与应用程序相关的数据都与授权相关，反之亦然)，在授权层中创建一个精益模型，然后通过实时事件使其与应用程序和其他源保持同步。
例如，开放策略管理层是一个开源项目，可以使开放策略管理成为事件驱动的。这使开发人员可以响应策略和数据更改，向其代理推送实时更新，并使开放策略达到实时应用程序所需的速度。
3. 利益相关者的后台集成
授权层是产品本身的一部分，在以产品为中心的企业中，有各种利益相关者需要能够连接到访问控制体验。与开发人员一起，这些包括DevOps、产品经理、安全、合规、销售、营销等。在构建授权层时，希望通过后台系统为这些不同的利益相关者提供控制和接口。这要求从一开始就考虑不同利益相关者从访问控制界面到产品的需求。应该让每个人都满意。
4. 客户接口
与考虑利益相关者要求的方式类似，开发人员还需要考虑最终用户/客户。授权不仅与管理产品有关，而且与产品的最终用户有关。例如，如果用户需要访问他们自己的审计日志(几乎每个B2B应用程序用户都需要)，他们应该能够轻松地看到在产品中所做的事情。提前认识到这一需求需要构建授权层，使其能够锁定满足最终用户需求的不同接口。
5. GitOps
因此创建了一个单独的微服务来管理权限，并且能够以事件驱动的方式向它提供更新。现在如何管理这些更改、应用版本、应用各种制衡，并确保微服务的代码和数据符合需求和要求?其答案是GitOps。
使用GitOps可以让开发人员为每个版本更改创建一个拉取请求。然后，当开发人员更新产品及其访问控制功能时，他们可以使用新代码推动提交，让这些代码通过必要的测试和检查，并将它们应用到授权层。
云原生权限的未来发展
随着复杂性的增加以及客户和安全需求的不断涌现，以一种为未来做好准备且不需要大量重构或重写的方式构建产品的访问控制至关重要。为授权创建单独的微服务，将其设计为事件驱动，为各种利益相关者和客户提供控制和接口，并使用GitOps使开发人员能够创建尽可能面向未来的产品，并防止他们不得不多次重建授权层，而无论需求如何。
