oauth-2.0 - 为 IAM 解决方案连接 Envoy 过滤器（API 网关）、PingFederate（身份验证服务器）和 OPA（策略引擎）的最佳架构方式是什么？

Question

我想在 Kubernetes 上部署它。Auth Server 和 Policy 引擎都独立与 API Gateway 对话是否有意义，或者仅 Auth Server 与 API Gateway 对话而 OPA 仅通过 Auth Server 与 API Gateway 对话是否更准确

Answer 1

在 Curity，我们有一些与此相关的好资源。通常，第一个关键考虑因素是围绕使用数据源的组件：

• 蜜蜂
• 授权服务器

这些总是部署在它们前面的反向代理/网关，因此攻击者必须突破 2 层才能访问数据源 - 这在我们的IAM Primer中有介绍。

此外，网关还可以提供一些有趣的功能：

• 令牌自省和缓存

• 动态路由

就 OPA 而言，这取决于您将如何使用它 - 这里有几个可能的选项：

• 网关调用 OPA 以执行高级检查以授予或拒绝访问权限，如在此 OPA 用例中

• API 调用 OPA 并将其传递给 Claims Principal，然后使用响应来决定如何过滤结果，如我们的Claims Best Practices文章中所述