[
https://issues.apache.org/jira/browse/NIFI-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17083557#comment-17083557
]
Andy LoPresto edited comment on NIFI-7203 at 4/14/20, 7:31 PM:
---------------------------------------------------------------
Hi [~jfrazee],
I think there's been a lot of good work put into this (sometimes in parallel).
I had an offline discussion with [~mcgilman] and [~tmelhase] today and we tried
to cover the scenarios and find the best path forward. I've included those
notes below. One area in particular we discussed is the standard behavior of
ZooKeeper to allow simultaneous connections on an HTTP port and HTTPS port. I
can understand when a standalone ZK instance has heterogenous clients
connecting that some may support HTTPS and some may not. However, we felt that
in the scenario of the _embedded ZK_ which runs as part of the NiFi cluster if
an external ZK instance is not available, this would only be expected to
support NiFi behavior, and it would more closely align to the principle of
least surprise that if both ports were provided, only the HTTPS port would be
listened. Our reasoning is that NiFi will only connect over TLS, and an admin
configuring this is likely not a ZK expert (as otherwise they would have a
standalone ZK cluster), so they are likely copy/pasting
{{zookeeper.properties}} values they found in one of the blogs explaining how
to configure a NiFi cluster. Therefore, by explicitly setting an HTTPS port
(not required for a baseline NiFi cluster to operate), they are expressing
their desire to secure their communications, and if we also allowed an HTTP
port to be exposed, this would violate their expectations. We propose detecting
this conflicting config and warning loudly in the logs, not listening on HTTP,
and continuing with cluster startup rather than allowing simultaneous
connection types or failing to start the cluster. Interested to hear your
perspective and if you've encountered any scenarios where an informed admin
_did_ expect both connection listeners simultaneously.
I will also put a (briefer) comment on PR 4207 addressing that. Thanks.
{quote}
# Configuring the ZK client to connect to TLS secured ZK instance
## External instance
### Through JVM arguments
### Through nifi.properties properties
## Embedded instance
### Through JVM arguments
### Through nifi.properties properties
# Configuring the embedded ZK server to use TLS
## Through JVM arguments (discourage to tertiary -- add to docs)
## Through zookeeper.properties properties (primary)
## Through nifi.properties properties (secondary)
# Should simultaneous HTTP and HTTPS connections be allowed?
## External ZK instance
### If ZK client is configured for TLS, only TLS connections should be allowed
(avoids silent leak of data over HTTP)
### If ZK client is configured for non-TLS (default), plaintext connections
## Embedded ZK instance
### NiFi restricts embedded ZK to only allow TLS connections if TLS configs are
provided, avoiding the surprise to the user _even_ if both options are
supported simultaneously given the provided server configuration
#### {{secureClientPort}}
#### {{clientPort}} (this property is exposed by default in our
zookeeper.properties template)
### Add comments in zookeeper.properties template explaining the ports are
mutually exclusive for embedded NiFi ZK
### Add docs in Admin Guide explaining changes from normal ZK operation
### Clarify that an external ZK is preferred but embedded ZK is provided as
accelerator only (similar to TLS TK)
# do custom validation in NiFi code and restrict the server to one or the other
for incoming connections
## expected to honor the zookeeper.properties properties
## multiple connection listeners may be valid for external ZK but not embedded
ZK for NiFi cluster/state
### detect conflicting config & refuse cluster startup
### detect conflicting config & warn loudly but continue with TLS only
[selected path forward]
### detect conflicting config & allow both
# do no validation and potentially allow multiple incoming connections
JettyServer (TLS validation) -> nifi-web-api -> FlowController -> ZKServer
* only need to check NiFiProperties.isHTTPSConfigured()
7356 - if NiFi has TLS settings, automatically apply to embedded ZK server IFF
ZK has no TLS settings
{quote}
was (Author: alopresto):
Hi [~jfrazee],
I think there's been a lot of good work put into this (sometimes in parallel).
I had an offline discussion with [~mcgilman] and [~tmelhase] today and we tried
to cover the scenarios and find the best path forward. I've included those
notes below. One area in particular we discussed is the standard behavior of
ZooKeeper to allow simultaneous connections on an HTTP port and HTTPS port. I
can understand when a standalone ZK instance has heterogenous clients
connecting that some may support HTTPS and some may not. However, we felt that
in the scenario of the _embedded ZK_ which runs as part of the NiFi cluster if
an external ZK instance is not available, this would only be expected to
support NiFi behavior, and it would more closely align to the principle of
least surprise that if both ports were provided, only the HTTPS port would be
listened. Our reasoning is that NiFi will only connect over TLS, and an admin
configuring this is likely not a ZK expert (as otherwise they would have a
standalone ZK cluster), so they are likely copy/pasting
{{zookeeper.properties}} values they found in one of the blogs explaining how
to configure a NiFi cluster. Therefore, by explicitly setting an HTTPS port
(not required for a baseline NiFi cluster to operate), they are expressing
their desire to secure their communications, and if we also allowed an HTTP
port to be exposed, this would violate their expectations. We propose detecting
this conflicting config and warning loudly in the logs, not listening on HTTP,
and continuing with cluster startup rather than allowing simultaneous
connection types or failing to start the cluster. Interested to hear your
perspective and if you've encountered any scenarios where an informed admin
_did_ expect both connection listeners simultaneously.
I will also put a (briefer) comment on PR 4207 addressing that. Thanks.
{quote}
1. Configuring the ZK client to connect to TLS secured ZK instance
a. External instance
i. Through JVM arguments
ii. Through nifi.properties properties
b. Embedded instance
i. Through JVM arguments
ii. Through nifi.properties properties
2. Configuring the embedded ZK server to use TLS
a. Through JVM arguments (discourage to tertiary -- add to docs)
b. Through zookeeper.properties properties (primary)
c. Through nifi.properties properties (secondary)
3. Should simultaneous HTTP and HTTPS connections be allowed?
a. External ZK instance
i. If ZK client is configured for TLS, only TLS connections
should be allowed (avoids silent leak of data over HTTP)
ii. If ZK client is configured for non-TLS (default), plaintext
connections
b. Embedded ZK instance
i. NiFi restricts embedded ZK to only allow TLS connections if
TLS configs are provided, avoiding the surprise to the user _even_ if both
options are supported simultaneously given the provided server configuration
1. secureClientPort
2. clientPort (this property is exposed by default in
our zookeeper.properties template)
ii. Add comments in zookeeper.properties template explaining
the ports are mutually exclusive for embedded NiFi ZK
iii. Add docs in Admin Guide explaining changes from normal ZK
operation
1. Clarify that an external ZK is preferred but
embedded ZK is provided as accelerator only (similar to TLS TK)
a. do custom validation in NiFi code and restrict the server to one or the
other for incoming connections
i. expected to honor the zookeeper.properties properties
ii. multiple connection listeners may be valid for external ZK but not
embedded ZK for NiFi cluster/state
1. detect conflicting config & refuse cluster startup
2. detect conflicting config & warn loudly but continue with TLS
only [selected path forward]
3. detect conflicting config & allow both
b. do no validation and potentially allow multiple incoming connections
JettyServer (TLS validation) -> nifi-web-api -> FlowController -> ZKServer
* only need to check NiFiProperties.isHTTPSConfigured()
7356 - if NiFi has TLS settings, automatically apply to embedded ZK server IFF
ZK has no TLS settings
{quote}
> Add support for TLS configuration properties to embedded ZooKeeper
> ------------------------------------------------------------------
>
> Key: NIFI-7203
> URL: https://issues.apache.org/jira/browse/NIFI-7203
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Security
> Reporter: Joey Frazee
> Assignee: Joey Frazee
> Priority: Major
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Currently the embedded ZooKeeper cannot be configured to use secure client
> access or quorum TLS because the
> [ZooKeeperStateServer|https://github.com/apache/nifi/blob/5f4ce8f431d1cb90451102efb516140d87610c52/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/state/server/ZooKeeperStateServer.java#L41]
> only sets a subset of properties, ignoring valid properties whether set in
> zookeeper.properties or elsewhere.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
