[
https://issues.apache.org/jira/browse/NIFI-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15664929#comment-15664929
]
Andy LoPresto commented on NIFI-3011:
-------------------------------------
After discussing with [~mattyb149], it appears the way X-Pack (the new client)
performs TLS configuration is less secure than it previously was. The old
client lib accepted Java keystore and truststore paths with their respective
passwords, providing a more secure approach compared to the new client lib
which wants the raw private key in PEM encoded format, the server certificate
in PEM format, and the CA certificate(s) in PEM format. This means that the
server private key (as they refer to it, the *node private key* or
{{xpack.ssl.key}} is no longer password-protected and is just stored on disk,
accessible to anyone with OS-level access.
In fact, the
[documentation|https://www.elastic.co/guide/en/x-pack/current/ssl-tls.html] was
clearly not updated completely, as it still refers to "keystore" and
"password(s)" immediately above.
{quote}
To enable SSL, make the following changes in elasticsearch.yml:
Specify the location of the node’s keystore and the password(s) needed to
access the node’s certificate. For example:
{code}
xpack.ssl.key: /home/es/config/x-pack/node01.key
xpack.ssl.certificate: /home/es/config/x-pack/node01.crt
xpack.ssl.certificate_authorities: [ "/home/es/config/x-pack/ca.crt" ]
{code}
The full path to the node key file. This must be a location within the
Elasticsearch configuration directory.
The full path to the node certificate. This must be a location within the
Elasticsearch configuration directory.
An array of paths to the CA certificates that should be trusted. These paths
must be a location within the Elasticsearch configuration directory.
{quote}
> Support Elasticsearch 5.0 for Put/FetchElasticsearch processors
> ---------------------------------------------------------------
>
> Key: NIFI-3011
> URL: https://issues.apache.org/jira/browse/NIFI-3011
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
> Reporter: Matt Burgess
> Assignee: Matt Burgess
>
> Now that Elastic has released a new major version (5.0) of Elasticsearch, the
> Put/FetchElasticsearch processors would need to be upgraded (or duplicated)
> as the major version of the transport client needs to match the major version
> of the Elasticsearch cluster.
> If upgrade is selected, then Put/FetchES will no longer work with
> Elasticsearch 2.x clusters, so in that case users would want to switch to the
> Http versions of those processors. However this might not be desirable (due
> to performance concerns with the HTTP API vs the transport API), so care must
> be taken when deciding whether to upgrade the existing processors or create
> new ones.
> Creating new versions of these processors (to use the 5.0 transport client)
> will also take some consideration, as it is unlikely the different versions
> can coexist in the same NAR due to classloading issues (multiple versions of
> JARs containing the same class names, e.g.). It may be necessary to create an
> "elasticsearch-5.0" version of the NAR, containing only the new versions of
> these processors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
