【问题标题】:Enable SAML authentication for Dashboards of private AWS OpenSearch cluster running in VPC为在 VPC 中运行的私有 AWS OpenSearch 集群的仪表板启用 SAML 身份验证
【发布时间】:2021-12-22 02:49:58
【问题描述】:

我想为 Kibana 配置单点登录,使用 Azure Active Directory 作为身份提供者和 OpenSearch 提供的嵌入式 SAML 身份验证方法。

但是,OpenSearch 集群在私有子网中运行,不能公开使用。 这似乎是不可能的,因为集群的端点解析私有ip:

$ dig +short vpc-<cluster-id>.<region>.es.amazonaws.com
10.0.52.81
10.0.52.13
10.0.52.41

在试验过程中,我注意到 VPC 中的私有集群也有带有“search-”前缀的可用 dns 并解析公共 ips:

$ dig +short search-<cluster-id>.<region>.es.amazonaws.com
54.a.b.227
13.c.d.158
13.e.f.17

documentation 并未明确表示当集群位于私有子网中时,SAML 身份验证方法不可用。

有人遇到过这样的挑战吗?

【问题讨论】:

    标签: amazon-web-services saml amazon-elasticsearch opensearch-dashboards


    【解决方案1】:

    SAML 不需要身份提供者和服务提供者之间的直接通信,这是将其用于 SSO 的一大好处。这意味着即使您的 ElasticSearch/OpenSearch 应用程序托管在私有 VPC 中,只要您的浏览器可以与 ElasticSearch 集群和 IdentityProvider 通信,您仍然可以使用 SAML。本质上,您的浏览器充当身份提供者和服务提供者之间的中间人。

    Okta 在这里很好地描述了它的工作原理:https://developer.okta.com/docs/concepts/saml/#planning-for-saml

    这样做的结果是,您的身份提供者和服务提供者之间不需要相互连接,因此在私有子网中使用 SAML 而不是在公共子网中使用 SAML 没有特殊考虑。

    【讨论】:

    • 我对 Okta 不熟悉,我们使用 Azure Enterprise Application 需要设置回复 URL(断言消费者服务 URL)。 OpenSearch 集群需要接收来自身份提供者的 SAML 断言。这是有道理的,也写在documentation 中:Regardless of which authentication type you use, the goal is to log in through your identity provider and receive a SAML assertion that contains your username (required) and any backend roles (optional, but recommended)
    • Okta 和 AzureAD 都使用 SAML 标准,并且浏览器的 SAML“舞蹈”充当应用程序和身份提供者之间的中间人。我使用 Okta 的图表是因为它很方便,但这里是来自 Azure 的相同文档:docs.microsoft.com/en-us/azure/active-directory/fundamentals/…。将“断言消费者服务 URL”提供给浏览器,作为它在收到经过身份验证的有效负载后应重定向到的位置。
    • 非常感谢@patrik,我误解了 SAML 标准的工作原理。我设法使用我的 Azure AD 帐户对其进行配置并访问 Kibana/Dashboards(在 VPC 中)。
    猜你喜欢
    • 2022-10-05
    • 2020-03-12
    • 2021-11-30
    • 2022-01-07
    • 2021-12-21
    • 1970-01-01
    • 1970-01-01
    • 2016-07-11
    • 1970-01-01
    相关资源
    最近更新 更多