Elastic cloud entreprise - saml

raphperrin · March 9, 2020, 12:04pm

Hi
I am trying to configure the SAML authentication to secure one of my elastic cloud cluster.
I added the configuration

"user_bundles": [
{
"name": "saml-metadata",
"url": "https://servername/saml-metadata.zip",
"elasticsearch_version": "7.6.0"
}
],

But the configuration never applies, I don't see any errors in the logs.

I've done it with a non cloud entreprise and it did work since I am able to provide the file directly on the system.

any help, please
Raphael

Alex_Piggott · March 9, 2020, 2:34pm

When you say "the configuration never applies", what does that mean exactly? (Eg does the configuration change fail, does it appear but SAML continues to fail in some way, etc?)

What is the format of saml-metadata.zip?

raphperrin · March 10, 2020, 6:03am

Hi, thank you for your answer.
The configuration never gets apply.
The zip file looks like this :

unzip -l saml-metadata.zip
Archive: saml-metadata.zip
Length Date Time Name
--------- ---------- ----- ----
0 03-06-2020 09:22 saml/
4729 03-09-2020 11:08 saml/metadata.xml

Thank you

Alex_Piggott · March 10, 2020, 12:54pm

Hi - I think I still need more details

The configuration never gets apply.

Does the configuration change report as successful or as an error?

The zip file looks like this

What is the ES config, eg the "user settings YAML" in the configuration page (or the contents of user_settings_yaml or user_settings_json if you specified it in the advanced editor)?

(Generally when SAML fails for any reason - assuming it was configured at all - eg the config change didn't fail, it will report an error in the ES logs which appear in the L+M cluster)

raphperrin · March 10, 2020, 1:12pm

Hi, no problem.
To start I am "only" trying to add the zip file with the metadata in the config under "user_bundles". I am able to save it.

Here is what I get in the container logs :

2020-03-10T13:09:16+0000 Booting at Tue Mar 10 13:09:16 UTC 2020
2020-03-10T13:09:16+0000 Enabling QuotaAwareFileSystemProvider
2020-03-10T13:09:17+0000 Installing user plugins.
2020-03-10T13:09:18+0000 Installing user bundles.
2020-03-10T13:09:18+0000 Installing saml-metadata...
2020-03-10T13:09:18+0000 --2020-03-10 13:09:18-- https://samlmetadata-int.domain.ch/saml-metadata.zip
2020-03-10T13:09:18+0000 Resolving samlmetadata-int.domain.ch (samlmetadata-int.domain.ch)... 100.76.0.30
2020-03-10T13:09:18+0000 Connecting to samlmetadata-int.domain.ch (samlmetadata-int.domain.ch)|100.76.0.30|:443... connected.
*** setuser exited with status 1.
*** Killing all processes...
usermod: no changes
*** Running setuser founduser /app/elasticsearch.sh...

And on the l+m cluster :

Thank you

Alex_Piggott · March 10, 2020, 1:54pm

OK so it sounds like you have successfully configured the cluster to download the metadata zip (and it will put metadata.xml into $config/saml/metadata/xml)

Now you should be able to follow the instructions here: https://www.elastic.co/guide/en/cloud-enterprise/current/ece-securing-clusters-SAML.html

and configure the cluster to use the client metadata (etc) to actually enable SAML?

Alex

raphperrin · March 10, 2020, 1:59pm

But the settings are not being applied

Alex_Piggott · March 10, 2020, 9:09pm

That server bootloop (almost) always means one of two things

The user-bundle is not accessible from the allocator host (you could try ssh'ing into the allocator and confirming ... the ES install literally just wgets it and then unzips it, so if you can do that from the command-line that should be fine)
One or more of the user settings is invalid ... in that case the relevant info is always logged

raphperrin · March 11, 2020, 5:54am

From the allocator, the wget works just fine. But from the Docker container, it fails because of the self-signed certificate on the metadata side . Is there any extra parameter to put in the user bundle ?

Alex_Piggott · March 11, 2020, 12:27pm

Ah so the web server that is serving the zip file is encrypted with a self-signed cert?

Ugh - that is a known bug in ECE at the moment (both that it happens, and that we provide no useful info to reveal that it's happening)

I believe the only workarounds are:

Run your own local haproxy instance on each allocator to terminate the self-signed ssl (also needed for minio access if using a minio S3 clone for snapshots)
Use a publicly signed ssl at the server

(I'll go ping the issue discussing this bug and see what's happened with it)

raphperrin · March 11, 2020, 2:28pm

Hi,
Thank you, I change the web server to http and the configuration does apply and it works now.
Thanks again

system · March 25, 2020, 2:28pm

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.