8000 ZOOKEEPER-3160: Custom User SSLContext by arankin-irl · Pull Request #728 · apache/zookeeper · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

ZOOKEEPER-3160: Custom User SSLContext #728

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 12 commits into from
Closed

ZOOKEEPER-3160: Custom User SSLContext #728

wants to merge 12 commits into from

Conversation

arankin-irl
Copy link
Contributor

This is a master branch version of: #654

The previous PR was for branch 3.5, and couldn't be merged as that branch is closed for new features.

The Zookeeper libraries currently allow you to set up your SSL Context via system properties such as "zookeeper.ssl.keyStore.location" in the X509Util. This covers most simple use cases, where users have software keystores on their harddrive.

There are, however, a few additional scenarios that this doesn't cover. Two possible ones would be:

  1. The user has a hardware keystore, loaded in using PKCS11 or something similar.
  2. The user has no access to the software keystore, but can retrieve an already-constructed SSLContext from their container.

For this, I would propose that the X509Util be extended to allow a user to set a property "zookeeper.ssl.client.context" to provide a class which supplies a custom SSL context. This gives a lot more flexibility to the ZK client, and allows the user to construct the SSLContext in whatever way they please (which also future proofs the implementation somewhat).

I added a few simple tests to this class around setting the SSLContext, and setting an invalid one. I'm not testing the actual functionality of the SSLContext, etc.

@arankin-irl arankin-irl closed this Dec 3, 2018
@arankin-irl arankin-irl reopened this Dec 3, 2018
@arankin-irl arankin-irl closed this Dec 3, 2018
@arankin-irl arankin-irl reopened this Dec 3, 2018
@arankin-irl arankin-irl closed this Dec 3, 2018
@arankin-irl arankin-irl reopened this Dec 3, 2018
@arankin-irl
Copy link
Contributor Author

@nkalmar - just drawing your attention to this after our discussion on #654

@nkalmar
Copy link
Contributor
nkalmar commented Dec 11, 2018

Thanks @arankin-irl , I will review it (I'm guessing it's the same as for 3.5, so it will be quick), but I am not a committer, I won't be able to merge your PR :(

8000
Copy link
Contributor
@nkalmar nkalmar left a comment

Choose a reason for hiding this comment

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

LGTM, already reviewed for 3.5 previously. Thanks!

Copy link
Contributor
@anmolnar anmolnar left a comment

Choose a reason for hiding this comment

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

Nice catch @arankin-irl !

One tiny suggestion: instead of wrapping the original behaviour in an if-else branch, I'd rather create a new class which implements your interface ZKClientSSLContext and call it for example DefaultClientSSLContext.

In the createSSLContext method you can try to instantiate the class from the new property value and if it's not provided, use the "default" class.

If the property value is provided, but cannot be instantiated for some reason, throw an error, don't fallback to the default impl. (which you already do correctly)

@anmolnar
Copy link
Contributor

@ivmaykov You might be interested to review this patch too.

@arankin-irl
Copy link
Contributor Author

One tiny suggestion: instead of wrapping the original behaviour in an if-else branch, I'd rather create a new class which implements your interface ZKClientSSLContext and call it for example DefaultClientSSLContext.

@anmolnar - I did have a look at doing something similar to that, but the X509Util methods and variables feature heavily in the creation of the SSLContext. Moving these to a DefaultClientSSLContext looks like it'd be a fair rewrite of the class.

Then again, I'm not really a fan of the current if/else situation - however, maybe an acceptable solution would be to move the else branch to a new method, like createSSLContextFromConfig()?

@anmolnar
Copy link
Contributor

@arankin-irl Got it, makes sense. I like the new method idea.

@arankin-irl
Copy link
Contributor Author

@anmolnar - I've updated the PR with the extracted method.

Copy link
Contributor
@anmolnar anmolnar left a comment

Choose a reason for hiding this comment

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

+1 Thanks @arankin-irl !

@anmolnar
Copy link
Contributor
anmolnar commented Jan 3, 2019

@arankin-irl Please rebase on top of current master.
@ivmaykov @hanm Would you please take a quick a look at this patch? I'd like to get your support to confidently merge it.

Merging in latest master.
# Conflicts:
#	zookeeper-server/src/main/java/org/apache/zookeeper/common/X509Util.java
@arankin-irl
Copy link
Contributor Author

@anmolnar - should be up to date now.

@ivmaykov
Copy link
Contributor

I can review this early next week, please wait for that before merging :)

Copy link
Contributor
@ivmaykov ivmaykov left a comment

Choose a reason for hiding this comment

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

Mostly looks good to me, have some style suggestions.

@arankin-irl
Copy link
Contributor Author

@ivmaykov - Updated the PR to resolve the comments. I stuck with the nested classes in the tests since package-private classes couldn't be instantiated with reflection.

Copy link
Contributor
@ivmaykov ivmaykov left a comment

Choose a reason for hiding this comment

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

A few more nits.

@ivmaykov
Copy link
Contributor

+1 (non-binding), but please address nits from my last review pass. Great work :)

@arankin-irl
Copy link
Contributor Author

@ivmaykov @anmolnar - Addressed the comments and updated the PR.

Copy link
Contributor
@ivmaykov ivmaykov left a comment

Choose a reason for hiding this comment

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

+1 (non-binding) with some minor nits

@anmolnar
Copy link
Contributor

@arankin-irl Please let me know once you've finished polishing your patch.

@arankin-irl
Copy link
Contributor Author

@ivmaykov @anmolnar - PR updated with the requested changes.

@ivmaykov
Copy link
Contributor

@arankin-irl you will need to rebase now that #681 landed. Let me know if you run into hard-to-resolve merge conflicts.

# Conflicts:
#	zookeeper-server/src/main/java/org/apache/zookeeper/common/X509Util.java
@arankin-irl
Copy link
Contributor Author

@ivmaykov @anmolnar - PR has been updated to resolve merge conflicts. I've removed the Null SSLContext test, as the SSLContextOptions now checks if the SSLContext is null (and there's a test around that already).

@asfgit asfgit closed this in 045833b Jan 25, 2019
@anmolnar
Copy link
Contributor

Committed to master branch.
Thanks @arankin-irl !

@anmolnar
Copy link
Contributor

@arankin-irl You should be assigned to the Jira.
Would you please share your Jira username and I can add it to the contributors list and assign Jira to you?

@arankin-irl
Copy link
Contributor Author

@arankin-irl You should be assigned to the Jira.
Would you please share your Jira username and I can add it to the contributors list and assign Jira to you?

My Jira username is Kenco.

RokLenarcic pushed a commit to RokLenarcic/zookeeper that referenced this pull request Sep 3, 2022
This is a master branch version of: apache#654

The previous PR was for branch 3.5, and couldn't be merged as that branch is closed for new features.

The Zookeeper libraries currently allow you to set up your SSL Context via system properties such as "zookeeper.ssl.keyStore.location" in the X509Util. This covers most simple use cases, where users have software keystores on their harddrive.

There are, however, a few additional scenarios that this doesn't cover. Two possible ones would be:

1. The user has a hardware keystore, loaded in using PKCS11 or something similar.
2. The user has no access to the software keystore, but can retrieve an already-constructed SSLContext from their container.

For this, I would propose that the X509Util be extended to allow a user to set a property "zookeeper.ssl.client.context" to provide a class which supplies a custom SSL context. This gives a lot more flexibility to the ZK client, and allows the user to construct the SSLContext in whatever way they please (which also future proofs the implementation somewhat).

I added a few simple tests to this class around setting the SSLContext, and setting an invalid one. I'm not testing the actual functionality of the SSLContext, etc.

Author: Alex Rankin <davelister@gmail.com>
Author: Alex Rankin <alex.rankin@mastercard.com>

Reviewers: andor@apache.org

Closes apache#728 from arankin-irl/ZOOKEEPER-3160 and squashes the following commits:

a20c62f [Alex Rankin] Merge branch 'master' into ZOOKEEPER-3160
5a9b8fc [Alex Rankin] Merge pull request #7 from apache/master
3c3dfdd [Alex Rankin] Re-ordering imports.
69e0b6c [Alex Rankin] Updating custom SSLContext supplier with review comments
874529b [Alex Rankin] Using supplier interface instead of custom interface, and renaming property
ec27260 [Alex Rankin] Merge branch 'master' into ZOOKEEPER-3160
75a010e [Alex Rankin] Merge pull request #6 from apache/master
838f61c [Alex Rankin] Merge branch 'master' into ZOOKEEPER-3160
f85d7e5 [Alex Rankin] Merge pull request #5 from apache/master
31d8dd5 [Alex Rankin] Extracting SSLContext creation from config to new method.
400839a [Alex Rankin] Adding ability to specify custom SSLContext for client
7ae7485 [Alex Rankin] Merge pull request #4 from apache/master
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
0