Skip to content

NIFI-7401 Add ZooKeeper client TLS to CuratorLeaderElectionManager#4250

Closed
jfrazee wants to merge 6 commits intoapache:mainfrom
jfrazee:NIFI-7401
Closed

NIFI-7401 Add ZooKeeper client TLS to CuratorLeaderElectionManager#4250
jfrazee wants to merge 6 commits intoapache:mainfrom
jfrazee:NIFI-7401

Conversation

@jfrazee
Copy link
Member

@jfrazee jfrazee commented May 1, 2020

Description of PR

This adds built-in support for ZooKeeper client TLS to the CuratorLeaderElectionManager so clusters can use TLS-enabled ZooKeepers. This is part of NIFI-7203 and is required for the TLS-enabled embedded ZooKeeper work in #4216.

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 GitHub Actions CI for build issues and submit an update to your PR as soon as possible.

@YolandaMDavis
Copy link
Contributor

@jfrazee was doing some research around this issue and found this PR. Does it need to be targeted to main or was this perhaps merged to main in the context of another PR?

@jfrazee
Copy link
Member Author

jfrazee commented Sep 2, 2020

@YolandaMDavis No it wasn't merged I have time to rebase and retest today actually.

I previously had a PR that included support for the embedded server too, but that got split apart because of some additional work and expanded scope.

@jfrazee jfrazee changed the base branch from master to main September 4, 2020 05:38
@jfrazee
Copy link
Member Author

jfrazee commented Sep 8, 2020

@YolandaMDavis I rebased/retargeted this and ran through the manual testing.

@thenatog
Copy link
Contributor

Reviewing this one, testing it out now. Also checking out #4216, not sure what the differences are there.

@jfrazee
Copy link
Member Author

jfrazee commented Sep 16, 2020

#4216 was intended to handle the embedded ZK path and is about forcing TLS for both the embedded server and the client whenever the embedded server is used.

@thenatog
Copy link
Contributor

Tested the cluster leader election over TLS, looks good. I see there's nothing in this PR for state management over TLS. Is there any PRs open that you know of which cover TLS + state management or is that something I should create a ticket for and work on?

@jfrazee
Copy link
Member Author

jfrazee commented Sep 18, 2020

@thenatog No, I don't think anyone has worked on the state management/I don't have any code for that in progress either, so yeah, I think it'd make sense for you to do if you want.

@thenatog
Copy link
Contributor

thenatog commented Sep 18, 2020

Right now for this PR I'm thinking we need some consolidation across the TLS + Zookeeper work. It seems like the embedded zookeeper + external zookeeper configuration isn't handled in the most cohesive way, which is fair because they've been developed separately, but it may result in unexpected behavior for users.

I'd like to get my PR for state management up before we merge this one so that all external-zookeeper interactions are secured, instead of only the cluster election. We may need to break out the SecureClientZooKeeperFactory class into a separate class and put it somewhere so it can be used by both election and state management.

It also looks like there needs to be more work on the embedded side to fix a few issues Joey raised in his review - I can look at adding some commits there next week.

@jfrazee
Copy link
Member Author

jfrazee commented Sep 18, 2020

@thenatog I think for SecureClientZooKeeperFactory to be usable in the state provider, it'd need a small refactor to use Curator, which actually looks more straightforward than I thought.

Copy link
Contributor

@exceptionfactory exceptionfactory left a comment

Choose a reason for hiding this comment

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

Aside from some suggestions on implementation adjustments, it would be great to get this merged as a step to securing this fundamental aspect of cluster communication.


// Netty is required for the secure client config.
final String cnxnSocket = zkConfig.getConnectionSocket();
if (!NETTY_CLIENT_CNXN_SOCKET.equals(cnxnSocket)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

If the secure client requires the ClientCnxnSocketNetty, it seems more straightforward to set the correct value in zkSecureClientConfig and ignore the ZooKeeperClientConfig.getConnectionSocket() altogether, instead of confirming that it matches the only correct value in this scenario.


// This should never happen but won't get checked elsewhere.
final boolean clientSecure = zkConfig.getClientSecure();
if (!clientSecure) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar to the previous comment, why not just set ZKClientConfig.SECURE_CLIENT to true regardless of ZooKeeperClientConfig, particularly since the value is already being checked before instantiating the class?

Copy link
Member Author

Choose a reason for hiding this comment

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

@exceptionfactory This is the one change I didn't make based on your suggestions (thanks for them BTW). While, yes, the secure factory knows what it needs, I don't/didn't want to ignore or change the config the user provides since their intent is either different or confused. I want them to know they're using it wrong.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the explanation, that makes sense, glad to help move things forward.

@thenatog
Copy link
Contributor

+1 from me, keen to get this merged so I can fix up my PR so we can get it all merged it.

@thenatog thenatog closed this Oct 20, 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.

4 participants