Feature Request: Encrypting Communications in Elasticsearch

[ghost]

Describe the feature:

X-Pack security enables you to encrypt traffic to, from, and within your Elasticsearch cluster. Connections are secured using Transport Layer Security (TLS/SSL). Clusters that do not have encryption enabled send all data in plain text including passwords and will not be able to install a license that enables X-Pack security. More info here: https://www.elastic.co/guide/en/elasticsearch/reference/6.1/configuring-tls.html#configuring-tls

Add feature to role to support this configuration.

[cl0udf0x]

I've done some work around this but there are a couple of scenarios. Should all the options be supported?

1) Ansible role generate the node certificates using the certutil command.

• certutil by default generates certs, which have no hostname information. In this case the certifcate can be used for every node in the cluster. When implementing this verfication must be set to "xpack.security.transport.ssl.verification_mode: certificate".

• certutil also supports hostname verification. In this case individual certs would need to be created for each node. When implementing this verfication must be set to "xpack.security.transport.ssl.verification_mode: full".

2) Have Ansible role place 3rd party certs and ca.

• Like point 1) may or may not use hostname verificaton. Also user would need to provide the certs, key and ca.

Requirements
X-Pack
private key and X.509 cert.
Configure each node identify itself using signed cert.
Enable SSL on the transport layer.
Enable SSL on the HTTP layer (optional).

Notes
API calls in tasks currently only use http. Will need to update to support https.
Node SSL is a requirement when installing a licence, which enables X-Pack security

[david-drake]

+1 on this request. I believe Elasticsearch 6.x requires the nodes to be encrypted so this should be added for parameters.

[cl0udf0x]

Seems there is already a request for this: #331.

I think best to close this one?

[SenolOzer1A]

I'm interested in this feature. Is it plan to have it in a future version?

[jmlrt]

#500 was also created for the same feature request and had more activity. FYI we are working on it #479. I'm closing this one as duplicate.