-
Notifications
You must be signed in to change notification settings - Fork 7.3k
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
Conversation
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 :( |
There was a problem hiding this 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!
There was a problem hiding this 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)
@ivmaykov You might be interested to review this patch too. |
@anmolnar - I did have a look at doing something similar to that, but the Then again, I'm not really a fan of the current if/else situation - however, maybe an acceptable solution would be to move the |
@arankin-irl Got it, makes sense. I like the new method idea. |
@anmolnar - I've updated the PR with the extracted method. |
There was a problem hiding this 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 !
@arankin-irl Please rebase on top of current master. |
Merging in latest master.
# Conflicts: # zookeeper-server/src/main/java/org/apache/zookeeper/common/X509Util.java
@anmolnar - should be up to date now. |
I can review this early next week, please wait for that before merging :) |
There was a problem hiding this 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.
zookeeper-server/src/main/java/org/apache/zookeeper/common/X509Util.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/main/java/org/apache/zookeeper/common/ZKClientSSLContext.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/main/java/org/apache/zookeeper/common/X509Util.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/test/java/org/apache/zookeeper/common/X509UtilTest.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/test/java/org/apache/zookeeper/common/X509UtilTest.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/test/java/org/apache/zookeeper/common/ZKTestClientSSLContext.java
Outdated
Show resolved
Hide resolved
@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. |
There was a problem hiding this 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.
zookeeper-server/src/main/java/org/apache/zookeeper/common/X509Util.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/main/java/org/apache/zookeeper/common/ZKConfig.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/test/java/org/apache/zookeeper/common/X509UtilTest.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/test/java/org/apache/zookeeper/common/X509UtilTest.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/main/java/org/apache/zookeeper/common/X509Util.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/test/java/org/apache/zookeeper/common/X509UtilTest.java
Outdated
Show resolved
Hide resolved
+1 (non-binding), but please address nits from my last review pass. Great work :) |
There was a problem hiding this 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
zookeeper-server/src/main/java/org/apache/zookeeper/common/X509Util.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/test/java/org/apache/zookeeper/common/X509UtilTest.java
Outdated
Show resolved
Hide resolved
zookeeper-server/src/test/java/org/apache/zookeeper/common/X509UtilTest.java
Outdated
Show resolved
Hide resolved
@arankin-irl Please let me know once you've finished polishing your patch. |
@arankin-irl you will need to rebase now that #681 landed. Let me know if you run into hard-to-resolve merge conflicts. |
Merging Latest Master
# Conflicts: # zookeeper-server/src/main/java/org/apache/zookeeper/common/X509Util.java
Committed to master branch. |
@arankin-irl You should be assigned to the Jira. |
My Jira username is Kenco. |
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
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:
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.