在微服务架构中，开发人员处于一个棘手的位置，不仅要保护单个外部 API 网关，还要通过安全授权步骤保护每个单独的微服务 API。事实上，零信任架构的核心原则是每个请求都必须经过身份验证和授权。
对于开发人员和安全团队来说，为每个微服务调用实施授权的想法似乎令人生畏。幸运的是，有许多最佳实践可以帮助您顺利上路——并在跨团队的可扩展流程上实现标准化：可在Istio和Kuma服务网格中与OPA一起部署。
1、将授权逻辑和策略与底层微服务解耦
在授权方面，团队可以采取的最有力的措施是将授权逻辑和政策与应用程序本身解耦，
也就是说，不要将授权逻辑硬编码到微服务中。
这使得团队可以在不改变应用程序编码的情况下，轻松改变政策的授权编码。
将你的授权标准化在像Open Policy Agent（OPA）这样的工具上，它允许你在不同的服务和团队中一致地创建和执行策略。由于OPA非常灵活，这也为你提供了广泛的选择，你可以选择如何实际构建授权执行，以及在应用程序中存储策略库。
2、使用Sidecar强制执行以保证安全、性能和可用性
在过去，大多数授权决定都发生在网关处--如果开发者愿意，他们仍然可以在那里为微服务强制执行授权。然而，为了安全、性能和可用性，通常最好也为每个微服务API执行授权步骤。如前所述，在零信任架构中，每个请求在被允许之前都必须经过认证和授权。
将每个授权请求发送到一个集中式服务是完全可能的。然而，这可能会大大增加延迟--例如，一个用户请求可能会穿越许多服务，如果每个请求都需要额外的网络跳转来到达集中式授权引擎，这可能会妨碍用户体验。
如果你使用的是OPA这样的工具，幸运的是，你也可以把本地授权引擎和策略库作为每个微服务的边车运行。
3、强制执行JSON网络令牌（JWT）验证
为了与在零信任模式下验证每个用户和每个服务间请求的需要保持一致，在这些实体之间建立安全信任也是一种最佳做法。进入JSON网络令牌（JWTs）。这些访问令牌提供了一种验证调用者身份的统一方式--因为它们是 "签名的"，由你的架构中受信任的身份服务器（如OAuth2或OpenID Connect）签发，你知道你可以信任与之相关的用户ID（它们必须与与令牌相关的公钥相匹配）。
作为奖励，JWTs是 "自足的 "实体。它们记录了你建立用户访问元素（如角色和权限）所需的所有数据（和元数据）--不需要对集中式服务进行外部调用来执行查询。
和前面的提示一样，你也可以用OPA完成这个步骤（验证JWTs）。简单地说，你可以在微服务API层面创建并强制执行需要验证令牌的策略--例如，所有对服务A或服务B的请求必须包含一个有效的JWT。此外，你还可以包括基于上下文的授权要求--例如，用户必须是开发人员，目前正在通话中，并且处于某个地理位置--这些都是提出请求所需要的。通过这种简单的方式，你可以开始在你的微服务集群中更有效地执行零信任。
4、使用RBAC和ABAC来控制终端用户的行为
以类似的方式，使用基于角色的访问控制（RBAC）来控制终端用户根据他们的工作职能被授权在集群中做什么，也是一种最佳实践。RBAC不仅仅是一个最佳实践，它是应用层面授权的基础。RBAC比仅仅获取一个用户名并评估其拥有的权限更广泛，它允许你将权限分组为角色--开发人员、营销人员、人员操作或任何其他角色。然后，你可以为该角色分配权限，这是很容易分配或撤销的。这是一种比以每个用户为基础分配权限更简单、更合理和可扩展的方式。
在这里，你可以使用OPA这样的工具轻松地执行RBAC。