ALB + Okta SSO 身份验证背后的 AWS 托管 ElasticSearch（现在称为 OpenSearch） - 不可能吗？

Posted 2023-02-19

【中文标题】ALB + Okta SSO 身份验证背后的 AWS 托管 ElasticSearch（现在称为 OpenSearch） - 不可能吗？

【英文标题】：AWS managed ElasticSearch (now knows as OpenSearch) behind ALB + Okta SSO authentication - not possible?

【发布时间】：2021-11-21 18:44:18

【问题描述】：

假设不可能将 AWS 托管弹性搜索 (opensearch) - Kibana - 放在 ALB 后面，我是否正确？我想配置 ALB，以便在将请求重定向到 Kibana（AWS 托管弹性搜索）之前使用 OKTA SSO oidc 进行身份验证。

有什么选择？我看到有人提到使用 lambda 作为代理 - 将 lambda 放在 ALB 后面，然后让 lambda 将请求重定向到 elasticsearch。我不知道这是怎么做到的——以前有没有人有过类似的经历？有什么推荐的读物吗？

谢谢

【问题讨论】：

推荐的使用 Kibana 进行 SSO 的方法是通过 SAML 而不是 OIDC，AWS 在这里有一个示例架构（忽略它使用 AWS SSO 的事实，这只是一个实现 SAML 的 IdP） ：aws.amazon.com/blogs/security/…

添加到@Patrick 的评论 - OKTA 支持 SAML。最好避免您的问题中提到的那种技术。更好地利用 ES 安全模型，因为它使您能够执行细粒度的访问控制。

@Patrick 如果集群放在 VPC 中会怎样？参考我的问题：***.com/questions/69897449/…

【参考方案1】：

可以配置应用程序负载均衡器以使用 Cognito 服务对用户进行身份验证，并将请求转发到私有子网中可用的任何应用程序。

您需要创建一个包含 2 个操作的侦听器规则：

authenticate-cognito 将用户重定向到您的 SSO 提供商登录页面的操作（必须配置 cognito 用户池）； forward 使用应用程序对您的目标群体采取行动。

查看 terraform aws_lb_listener_rule 定义的示例：

resource "aws_lb_listener_rule" "listener_rule" 
  listener_arn = your_alb_listener_443_arn

  action 
    type = "authenticate-cognito"
    authenticate_cognito 
      user_pool_arn = your_cognito_user_pool.cognito_user_pool.arn
      user_pool_client_id = your_user_pool_client_id
      user_pool_domain = your_cognito_user_pool_domain
    
  
  action 
    type = "forward"
    target_group_arn = your_lb_target_group_arn
  
  condition 
    host_header 
      values = [
        "your_domain" # resolves ALB endpoint
      ]
    
  
  lifecycle 
    create_before_destroy = true
  

正如 Patrick 和 Leo 在 cmets 中提到的，AWS OpenSearch 提供了细粒度的访问控制，并具有嵌入式 SSO 身份验证机制，让您可以使用现有的身份提供商：

SAML authentication AWS Cognito authentication

如果您的集群是公开可用的，它会很好地工作 但是，文档并没有说明在 VPC 和私有子网中配置集群时它是如何工作的。

请参阅此question。

【讨论】：

如引用问题中所述，SAML 在公共子网和私有子网之间没有区别。它在两种情况下都同样有效。