在我工作的公司，我们正在考虑是否将开放策略代理 (OPA) 用于细粒度 authZ。
为了将数据加载到 OPA，网站上的External Data下列出了多种方法。对于我们正在处理的场景，我想结合使用JWT 令牌和推送数据（取决于具体的用例）。作为旁注；还考虑最初将 OPA 托管为独立服务而不是 sidecar 容器（即使使用 K8s 和 Istio），因为这似乎更简单（从概念上），并且更容易从更广泛的 IT 中获得支持。根据事情的进展，我们可以稍后迁移到边车方法。
WRT 推送数据方法；
如果数据存储在内存中（使用 Push Data 方法时）；当 OPA 崩溃或重新部署时，我们将如何处理这种情况？
类似于 OPA 的捆绑功能以及与其/healthAPI 的集成以进行准备检查，您可能希望在将数据推送到 OPA 的工具中构建类似的功能。
这个想法是您构建的工具（https://www.openpolicyagent.org/docs/latest/external-data/#option-4-push-data上描述的“复制器” ）可以知道它是否已同步事物使用 OPA，您可能会在此之前将该 OPA 实例声明为“准备就绪”。
假设有多个 OPA 副本；我们如何确保数据传播到所有 OPA 容器？
通常在这些系统中存在一定程度的最终一致性。OPA 采用捆绑包的策略是，每个 OPA 实例都能够报告它是否“准备好”（如上所述），但也许更重要的是，它还具有与决策记录器和出处功能集成的一组功能这样您就可以审核用于任何策略评估的捆绑包版本。这个想法是即使某些 OPA 实例不同步（这在大型分布式系统中必然会发生），您也可以跟踪它。与上面的答案类似，您可能希望为您的“复制器”构建类似的东西。
话虽如此，有一种趋势，如果你可以使用捆绑包，大部分这些东西都可以在很大程度上得到解决。如果您仍处于计划阶段，请务必查看是否需要将数据直接推送到 OPA。