Question: Is OpenSearch security really using insecure HTTPS by default?

I have a question about this section of the configuration: OpenID Connect - OpenSearch documentation

Am I reading this correctly that OpenSearch security plugin is using the equivalent of the --insecure flag of curl by default? i.e. it connects to your IdP over HTTPS, but you get no benefit of the SSL layer because all validation is disabled?

This kind of seems like a security vulnerability if true.

@albgus Where exactly does it say in the documentation?

To prevent man-in-the-middle attacks, you should secure the connection between the security plugin and your IdP with TLS.

Makes it sound like it’s not performing validation by default?

@albgus This is not a security vulnerability. If the IdP offers HTTP connection (i.e. Keycloak) then the security plugin allows you to use it. You’re not forced to use that approach.

It is recommended to always secure the connection between the OpenSearch cluster and IdP.

Just to confirm so there is no ambiguity. You are saying that if I just use a https:// endpoint for the IdP it will validate the TLS certificates by default? Without having to maintain my own copy of a CA-trust list for public certificate authorities?

@albgus You need to set enable_ssl to true and the security plugin will validate the certificate of the IdP.

If IdP is using a self-signed certificate or the certificate is signed by Internal CA then you must provide that information either in config.openid_connecti_idp.pemtrustedcas_filepath or config.openid_connecti_idp.pemtrustedcas_content.

I’m not sure how you deployed your environment. However, if you used docker installation then it is built on the Amazon Linux 2 image. The External CAs are located /etc/pki/ca-trust/extracted/openssl/

Just to be clear, maintaining external CAs is not a part of the security plugin.

So the answer to my original question is yes, the security plugin uses the equivalent to --insecure by default, unless you specifically tell it not to?

I am deploying with the container, but using the system CA store as you mentioned doesn’t work, because OpenSearch will refuse to read any file outside if it’s “home” directory due to some Java security policy…

I understand that the OpenSearch project doesn’t want to maintain their own CA trust, but neither do I… and I don’t think it’s reasonable to ask people who do not run their internal CA to do this either. Why not just use the cacerts store that is shipped with the Java runtime?

@albgus --insecure is used only for HTTPS connection as it makes no sense to use it with HTTP. So, the default is HTTP (enable_ssl: false) and not --insecure.

If you’re looking for the enhancement in the plugin or OpenSearch, I’d suggest creating an issue in OpenSearch GitHub.