0

Am I correct in assuming that it is NOT possible to put AWS managed elasticsearch (opensearch) - Kibana - behind ALB ? I would like to configure ALB so it authenticates with OKTA SSO oidc before redirecting request to Kibana (AWS managed elasticsearch).

What are the alternatives ? I see some people mentioning using lambda as proxy - putting lambda behind ALB, and then let lambda redirect request to the elasticsearch. I dont know how this could be done - did anyone had similar experiences before ? Any recommended reading regarding that?

Thank you

warkolm
  • 1,933
  • 1
  • 4
  • 12
wuls
  • 41
  • 5
  • 2
    The recommended way to SSO with Kibana is through SAML as opposed to OIDC, which AWS has a example architecture for here (ignore the fact it uses AWS SSO, that'd just one IdP that implements SAML): https://aws.amazon.com/blogs/security/how-to-enable-secure-access-to-kibana-using-aws-single-sign-on/ – Patrick Sep 30 '21 at 01:12
  • Adding to @Patrick's comment - OKTA supports SAML. It is better to avoid the sort of techniques mentioned in your question. Leveraging on the ES security model is better because it enables you to perform fine-grained access control. – Leo Sep 30 '21 at 08:37
  • @Patrick what if the cluster is placed in VPC? Refer to my question: https://stackoverflow.com/questions/69897449/enable-saml-authentication-for-dashboards-of-private-aws-opensearch-cluster-runn?r=SearchResults&s=12|79.8847 – antonbormotov Nov 10 '21 at 17:11

1 Answers1

0

It is possible to configure an application load balancer to authenticate the user using Cognito service and forward requests to any application available in private subnets.

You need to create a listener rule with 2 actions:

  • authenticate-cognito action to redirect user to your SSO provider login page (a cognito user pool must be configured);
  • forward action to your target group with the application.

See an example of terraform aws_lb_listener_rule definition:

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
  }
}

As Patrick and Leo mentioned in comments, AWS OpenSearch provides fine-grained access control and has embedded SSO authentication mechanisms that lets you use your existing identity provider:

It works very well if your cluster is publicly available However, documentation does not bring the light how it works when a cluster provisioned in VPC, in private subnets).

Refer to this question.

antonbormotov
  • 1,821
  • 2
  • 20
  • 32
  • As noted within the referenced question, SAML makes no difference between a public subnet and a private one. It works equally well in both situations. – Patrick Nov 10 '21 at 23:41
  • How are people managing the Target Group for this? As far as I can tell, you'd need to find the IPs for the nodes, add them to the target group, and then have some process that updates them if nodes are replaced or change IPs... – Jason Antman Feb 17 '23 at 14:12
  • @JasonAntman Kibana, staring from v7.0, supports a number of SSO mechanisms, including SAML single sign on, my answer and the topic are not relevant for newer versions of the elastic stack: https://www.elastic.co/guide/en/kibana/current/kibana-authentication.html – antonbormotov Feb 20 '23 at 10:00