Skip to content

NIFI-7203 Support for TLS in Zookeeper Server#4202

Closed
natural wants to merge 1 commit intoapache:masterfrom
natural:nifi-7203
Closed

NIFI-7203 Support for TLS in Zookeeper Server#4202
natural wants to merge 1 commit intoapache:masterfrom
natural:nifi-7203

Conversation

@natural
Copy link
Contributor

@natural natural commented Apr 10, 2020

Support for TLS in Embedded and Distributed Zookeeper Servers

Enables TLS functionality for embedded and/or distributed ZK ; addresses improvements outlined in NIFI-7203.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

  • Is there a JIRA ticket associated with this PR? Is it referenced
    in the commit message?

  • Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

  • Has your PR been rebased against the latest commit within the target branch (typically master)?

  • Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

  • Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
  • Have you written or updated unit tests to verify your changes?
  • Have you verified that the full build is successful on both JDK 8 and JDK 11?
  • If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
  • If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
  • If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
  • If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

  • Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

@jfrazee
Copy link
Member

jfrazee commented Apr 13, 2020

@natural Having also recently implemented this (#4207) I have a couple of comments:

  • Secure and insecure aren't mutually exclusive so if you also have clientPort in zookeeper.properties the behavior will be unexpected in that it'll ignore it and use secureClientPort instead.
  • I wouldn't recommend setting ssl.hostnameVerification=false as an example.
  • We should add some tests.

@jfrazee
Copy link
Member

jfrazee commented Apr 13, 2020

@natural Otherwise the implementation appears to be correct.

final InetSocketAddress secPort = config.getSecureClientPortAddress();
connectionFactory = ServerCnxnFactory.createFactory();
connectionFactory.configure(config.getClientPortAddress(), config.getMaxClientCnxns());
if (secPort != null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the insecure client port and secure client port aren't mutually exclusive you should add the checks for each port independently and setup two connection factories with their own startup and shutdown.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're right, your implementation should be merged, not this one.

I was trying to avoid multiple connections due to the security implications but I think we can just as easily handle that elsewhere.

final InetSocketAddress secPort = quorumPeerConfig.getSecureClientPortAddress();
connectionFactory = ServerCnxnFactory.createFactory();
connectionFactory.configure(quorumPeerConfig.getClientPortAddress(), quorumPeerConfig.getMaxClientCnxns());
if (secPort != null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also same.

@jfrazee
Copy link
Member

jfrazee commented Apr 13, 2020

@natural Would you be able to snag the tests from #4207 and make the change to the logic and zookeeper.properties and then we'll just turn the other PR into the client path?

# secureClientPort=2281
# serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory

# Most TLS configurations will set these values as well:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call on including the example properties. We should include a note about not using the reconfig-style server.N entries if both clientPort and secureClientPort are being used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed.

# ssl.keyStore.password=change this value to the actual value in your installation
# ssl.trustStore.location=/example/path/to/trust-store.jks
# ssl.trustStore.password=change this value to the actual value in your installation
# ssl.hostnameVerification=false
Copy link
Member

@jfrazee jfrazee Apr 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's remove ssl.hostnameVerification=false, or note that you would only do it for testing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add a note to that effect.

@natural
Copy link
Contributor Author

natural commented Apr 13, 2020

@natural Would you be able to snag the tests from #4207 and make the change to the logic and zookeeper.properties and then we'll just turn the other PR into the client path?

@jfrazee thank you for the feedback!

I think #4207 should get merged as-is, this PR closed, and the few remaining property file changes put into a new commit/branch/PR.

@natural natural closed this Apr 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants