-
Notifications
You must be signed in to change notification settings - Fork 855
Conversation
This commit introduces SSL/TLS support for the elastic search transport layer. It assumes certificates are generated externally, and only handles uploading and configuring the server accordingly.
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
This builds on the work of @AevaOnline from #597 and @kcm from #479 |
@jmlrt this is ready to look at, are you able to kick off a jenkins build? I had to do my testing with the new trial task to test security under version 7.1.0. TODO: documentation |
jenkins test this please |
@jmlrt I've moved the cert files along with the template files and updated the integration tests:
|
jenkins test this please |
Nice catch for the templates 👍 |
devops failure looks to be a transient debian-8 issue |
Yes that's not related to your changes so not a blocker. Local tests are OK for me. I would prefer removing the I will also ask for a second opinion from elastic people, especially for the idea of generating tls configuration in |
jenkins test this please |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thank you so much for all of the work you have done here. Including adding testing and updating the docs it really is amazing.
My comment around making the auto generated certificate configuration optional isn't blocking. While there are edge cases that could prevent users from using these auto generated values, right now they can't do it at all :P So the ability to disable it can always come in a future PR.
templates/elasticsearch.yml.j2
Outdated
@@ -33,6 +33,39 @@ action.auto_create_index: {{ es_action_auto_create_index }} | |||
|
|||
{% if es_enable_xpack and es_api_basic_auth_username is defined and es_api_basic_auth_password is defined %} | |||
xpack.security.enabled: true | |||
|
|||
{% if es_enable_transport_ssl | bool %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think its ok to leave these autogenerated values in as long as there is a way to opt out of it by adding some kind of es_enable_auto_ssl_configuration: false
. Right now if someone wanted to add multiple certificate_authorities
(which is an array/list) they wouldn't be able to override it in es_config
because those values are being provided first and assume that you only have one CA. There are probably a bunch of other edge cases that could prevent a user from enabling security if they were forced to have these exact values set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⛴
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thank you for adding in that extra option to disable the auto generated config 👍
jenkins test this please |
One failing test not related to PR code (timeout during ES package install). Let's merge this PR! @pemontto but also @AevaOnline (#597), @itsmed & @kcm (#479), @strootman (#302), @xocasdashdash (#635), @Justbkuz (#442), @cdahlqvist (#331), thanks you all for your amazing work to make this Ansible role supporting with TLS 👍 👍 👍 |
This PR adds the ability to configure password protected key and certificate, or keystore and truststore transport and HTTP encryption.
If both are defined it will preference keystores and truststore based on the preference in the Elasticsearch documentation. It doesn't yet support having different keys for HTTP and trasport, though that won't be hard to add.
Currently a WIP because it's not documented and I have yet to define tests to cover various use cases. I'm having trouble getting converge running, it seems to pick up some strange paths when "preparing roles".
The role attempts to add or remove passwords to/from the keystore only when the cert/truststore copy operation is changed. This might be a non-issue but it could lead to an edge case where if alternate key/keystores have been uploaded already, swapping between them won't update the password to unlock them in the keystore.