Solr
  1. Solr
  2. SOLR-8415

Provide command to switch between non/secure mode in ZK

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.5, 6.0
    • Component/s: security, SolrCloud
    • Labels:
      None

      Description

      We have the ability to run both with and without zk acls, but we don't have a great way to switch between the two modes. Most common use case, I imagine, would be upgrading from an old version that did not support this to a new version that does, and wanting to protect all of the existing content in ZK, but it is conceivable that a user might want to remove ACLs as well.

      1. SOLR-8415.branch_5x.patch
        15 kB
        Gregory Chanan
      2. SOLR-8415.branch_5x.patch
        15 kB
        Mike Drob
      3. SOLR-8415.patch
        15 kB
        Gregory Chanan
      4. SOLR-8415.patch
        14 kB
        Mike Drob
      5. SOLR-8415.patch
        15 kB
        Mike Drob
      6. SOLR-8415.patch
        12 kB
        Mike Drob
      7. SOLR-8415.patch
        8 kB
        Mike Drob
      8. SOLR-8415.patch
        3 kB
        Mike Drob

        Activity

        Hide
        Mike Drob added a comment -

        Adding a patch -p0 against trunk.

        Users can specify if they are setting or removing acls by selecting the appropriate ZkAclProvider using VM props.

        This will need a bunch of documentation to make clear.

        Also, still missing tests, but I wanted to get people's feedback on it before I went too far down the rabbit hole.

        Show
        Mike Drob added a comment - Adding a patch -p0 against trunk. Users can specify if they are setting or removing acls by selecting the appropriate ZkAclProvider using VM props. This will need a bunch of documentation to make clear. Also, still missing tests, but I wanted to get people's feedback on it before I went too far down the rabbit hole.
        Hide
        Mike Drob added a comment -

        Attaching a new patch that includes some tests for converting both ways between secure and non secure nodes.

        Docs should go on the wiki somewhere. I'll write them up as soon as somebody gives me a nudge to help find a good home for them.

        Show
        Mike Drob added a comment - Attaching a new patch that includes some tests for converting both ways between secure and non secure nodes. Docs should go on the wiki somewhere. I'll write them up as soon as somebody gives me a nudge to help find a good home for them.
        Hide
        Mark Miller added a comment -

        Docs should go on the wiki somewhere.

        I'd start looking around https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control

        Show
        Mark Miller added a comment - Docs should go on the wiki somewhere. I'd start looking around https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control
        Hide
        Mike Drob added a comment -

        Thanks Mark! That page looks reasonable.

        Proposed text, to go after "Example Usages":

        Swapping ACL Schemes

        Over the lifetime of operating your Solr cluster, you may decide to move from a unsecured ZK to a secured instance. Changing the configured zkACLProvider in solr.xml will ensure that newly created nodes are secure, but will not protect the already existing data. To modify all existing ACLs, you can use ZkCLI -cmd resetacl.

        To change the ACLs this way, you must specify the following VM properties: -DzkACLProvider=... -DzkCredentialsProvider=....

        • The Credential Provider must be one that has admin privileges on the nodes. If starting with an unsecure configuration, this may be omitted.
        • The ACL Provider will be used to compute the new ACLs. When creating an unsecure configuration, this may be omitted.
        • To swap from one secure setup to a new secure setup, such as when changing the password, it ma be necessary to use an unsecure intermediate step.
        Show
        Mike Drob added a comment - Thanks Mark! That page looks reasonable. Proposed text, to go after "Example Usages": Swapping ACL Schemes Over the lifetime of operating your Solr cluster, you may decide to move from a unsecured ZK to a secured instance. Changing the configured zkACLProvider in solr.xml will ensure that newly created nodes are secure, but will not protect the already existing data. To modify all existing ACLs, you can use ZkCLI -cmd resetacl . To change the ACLs this way, you must specify the following VM properties: -DzkACLProvider=... -DzkCredentialsProvider=... . The Credential Provider must be one that has admin privileges on the nodes. If starting with an unsecure configuration, this may be omitted. The ACL Provider will be used to compute the new ACLs. When creating an unsecure configuration, this may be omitted. To swap from one secure setup to a new secure setup, such as when changing the password, it ma be necessary to use an unsecure intermediate step.
        Hide
        Mike Drob added a comment -
        Show
        Mike Drob added a comment - Also, we would add resetacl to https://cwiki.apache.org/confluence/display/solr/Command+Line+Utilities
        Hide
        Gregory Chanan added a comment -

        Some comments on the proposed documentation:

        but will not protect the already existing data

        "data" is ambiguous. ZooKeeper metadata? ZNodes?

        it ma be necessary

        may be necessary

        use an unsecure intermediate step.

        Is this true? Let's say you wanted to switch from secure setup old: (old acls, old credentials) to secure setup new (new acls, new credentials). You can call resetacls with (old acls + new acls, old credentials). Then call reset acls with (new acls, new credentials). That requires an intermediate step, but it isn't unsecure.

        Show
        Gregory Chanan added a comment - Some comments on the proposed documentation: but will not protect the already existing data "data" is ambiguous. ZooKeeper metadata? ZNodes? it ma be necessary may be necessary use an unsecure intermediate step. Is this true? Let's say you wanted to switch from secure setup old: (old acls, old credentials) to secure setup new (new acls, new credentials). You can call resetacls with (old acls + new acls, old credentials). Then call reset acls with (new acls, new credentials). That requires an intermediate step, but it isn't unsecure.
        Hide
        Gregory Chanan added a comment -
        +        } else if (line.getOptionValue(CMD).equals(RESETACL)) {
        +          zkClient.resetACLs("/");
        

        should take a path, like CLEAN

        +    List<String> children = getChildren(znode, null, true);
        

        catch NoNodeException, like CLEAN

        +      getSolrZooKeeper().setACL(znode, getZkACLProvider().getACLsToAdd(znode), -1);
        

        Will this work if the version of the znode is set?

        Why don't you support retryOnConnLoss?

        Would be good to test that the acls get applied recursively

        Show
        Gregory Chanan added a comment - + } else if (line.getOptionValue(CMD).equals(RESETACL)) { + zkClient.resetACLs( "/" ); should take a path, like CLEAN + List< String > children = getChildren(znode, null , true ); catch NoNodeException, like CLEAN + getSolrZooKeeper().setACL(znode, getZkACLProvider().getACLsToAdd(znode), -1); Will this work if the version of the znode is set? Why don't you support retryOnConnLoss? Would be good to test that the acls get applied recursively
        Hide
        Gregory Chanan added a comment -

        Is this true? Let's say you wanted to switch from secure setup old: (old acls, old credentials) to secure setup new (new acls, new credentials). You can call resetacls with (old acls + new acls, old credentials). Then call reset acls with (new acls, new credentials). That requires an intermediate step, but it isn't unsecure.

        maybe change your test to do this (or do both this and the secure/non-secure version, should be simple to do both probably).

        Show
        Gregory Chanan added a comment - Is this true? Let's say you wanted to switch from secure setup old: (old acls, old credentials) to secure setup new (new acls, new credentials). You can call resetacls with (old acls + new acls, old credentials). Then call reset acls with (new acls, new credentials). That requires an intermediate step, but it isn't unsecure. maybe change your test to do this (or do both this and the secure/non-secure version, should be simple to do both probably).
        Hide
        Mike Drob added a comment -

        should take a path, like CLEAN

        Optional path or required path? Could still default to / if no path given, or could make the path required for consistency. Or could accept multiple paths.
        I think operating on / will be the most common use case, so it would make sense to default to it, but I'll defer to you on this.

        catch NoNodeException, like CLEAN

        Good catch.

        Will this work if the version of the znode is set?

        Yea, the -1 means don't care about the version.

        Why don't you support retryOnConnLoss?

        Not sure what this means.

        Would be good to test that the acls get applied recursively

        The existing test does this. Set acls on /, test on /collections/collection1

        maybe change your test to do this (or do both this and the secure/non-secure version, should be simple to do both probably).

        I've been tinkering with a test for this, I'm having some trouble getting the providers and credentials lines up in a way that tests something meaningful. I think I can get it though.

        Show
        Mike Drob added a comment - should take a path, like CLEAN Optional path or required path? Could still default to / if no path given, or could make the path required for consistency. Or could accept multiple paths. I think operating on / will be the most common use case, so it would make sense to default to it, but I'll defer to you on this. catch NoNodeException, like CLEAN Good catch. Will this work if the version of the znode is set? Yea, the -1 means don't care about the version. Why don't you support retryOnConnLoss? Not sure what this means. Would be good to test that the acls get applied recursively The existing test does this. Set acls on /, test on /collections/collection1 maybe change your test to do this (or do both this and the secure/non-secure version, should be simple to do both probably). I've been tinkering with a test for this, I'm having some trouble getting the providers and credentials lines up in a way that tests something meaningful. I think I can get it though.
        Hide
        Gregory Chanan added a comment -

        Optional path or required path? Could still default to / if no path given, or could make the path required for consistency. Or could accept multiple paths.
        I think operating on / will be the most common use case, so it would make sense to default to it, but I'll defer to you on this.

        Whatever you think is best.

        Why don't you support retryOnConnLoss?
        Not sure what this means.

        See a bunch of the other commands in SolrZkClient, like makePath. They support a retryOnConnLoss parameter, which would be useful here.

        The existing test does this. Set acls on /, test on /collections/collection1

        My mistake. I'd check "/" as well, that sort of thing is easy to screw up.

        Show
        Gregory Chanan added a comment - Optional path or required path? Could still default to / if no path given, or could make the path required for consistency. Or could accept multiple paths. I think operating on / will be the most common use case, so it would make sense to default to it, but I'll defer to you on this. Whatever you think is best. Why don't you support retryOnConnLoss? Not sure what this means. See a bunch of the other commands in SolrZkClient, like makePath. They support a retryOnConnLoss parameter, which would be useful here. The existing test does this. Set acls on /, test on /collections/collection1 My mistake. I'd check "/" as well, that sort of thing is easy to screw up.
        Hide
        Mike Drob added a comment -

        Let's say you wanted to switch from secure setup old: (old acls, old credentials) to secure setup new (new acls, new credentials). You can call resetacls with (old acls + new acls, old credentials). Then call reset acls with (new acls, new credentials). That requires an intermediate step, but it isn't unsecure

        I continued working on this and the main "problem" is that VMParamsAllAndReadonlyDigestZkACLProvider and VMParamsSingleSetCredentialsDigestZkCredentialsProvider use the same VM properties for the ACLs and Credentials. Normally, this is nice and makes things simpler, but when migrating and you want them to be different then that doesn't help us much. Since those are the only two out of the box Providers, the unsecure route is the only option when using the command line only.

        It's pretty straightforward to do this with access to writing some java classes, but at that point I'm not sure who our audience is.

        Show
        Mike Drob added a comment - Let's say you wanted to switch from secure setup old: (old acls, old credentials) to secure setup new (new acls, new credentials). You can call resetacls with (old acls + new acls, old credentials). Then call reset acls with (new acls, new credentials). That requires an intermediate step, but it isn't unsecure I continued working on this and the main "problem" is that VMParamsAllAndReadonlyDigestZkACLProvider and VMParamsSingleSetCredentialsDigestZkCredentialsProvider use the same VM properties for the ACLs and Credentials. Normally, this is nice and makes things simpler, but when migrating and you want them to be different then that doesn't help us much. Since those are the only two out of the box Providers, the unsecure route is the only option when using the command line only. It's pretty straightforward to do this with access to writing some java classes, but at that point I'm not sure who our audience is.
        Hide
        Gregory Chanan added a comment -

        It's pretty straightforward to do this with access to writing some java classes, but at that point I'm not sure who our audience is.

        The point was the proposed documentation was incorrect. Our audience is someone who wants to switch from one secure acl regime to another. If you don't think that's a popular enough use case to warrant documentation then I'd suggest getting rid of that part including the incorrect information.

        Show
        Gregory Chanan added a comment - It's pretty straightforward to do this with access to writing some java classes, but at that point I'm not sure who our audience is. The point was the proposed documentation was incorrect. Our audience is someone who wants to switch from one secure acl regime to another. If you don't think that's a popular enough use case to warrant documentation then I'd suggest getting rid of that part including the incorrect information.
        Hide
        Mike Drob added a comment -

        I do not expect it to be a popular use case, but I do expect it to be a non-zero use case. I'm fine with getting a functional implementation for now, though, and then refining it later. Here's new documentation that sidesteps the issue:

        Swapping ACL Schemes

        Over the lifetime of operating your Solr cluster, you may decide to move from a unsecured ZK to a secured instance. Changing the configured zkACLProvider in solr.xml will ensure that newly created nodes are secure, but will not protect the already existing data. To modify all existing ACLs, you can use ZkCLI -cmd resetacl [path]. If no path is specified, then the command will operate on the whole tree.

        To change the ACLs this way, use the following VM properties: -DzkACLProvider=... -DzkCredentialsProvider=....

        • The Credential Provider must be one that has current admin privileges on the nodes. When omitted, the process will use no credentials (suitable for an unsecure configuration).
        • The ACL Provider will be used to compute the new ACLs. When omitted, the process will set all permissions to all users, removing any security present.
        • You may use the VMParamsSingleSetCredentialsDigestZkCredentialsProvider and VMParamsAllAndReadonlyDigestZkACLProvider as described earlier in the page for these properties.

        I will upload a new patch shortly.

        Show
        Mike Drob added a comment - I do not expect it to be a popular use case, but I do expect it to be a non-zero use case. I'm fine with getting a functional implementation for now, though, and then refining it later. Here's new documentation that sidesteps the issue: Swapping ACL Schemes Over the lifetime of operating your Solr cluster, you may decide to move from a unsecured ZK to a secured instance. Changing the configured zkACLProvider in solr.xml will ensure that newly created nodes are secure, but will not protect the already existing data. To modify all existing ACLs, you can use ZkCLI -cmd resetacl [path] . If no path is specified, then the command will operate on the whole tree. To change the ACLs this way, use the following VM properties: -DzkACLProvider=... -DzkCredentialsProvider=... . The Credential Provider must be one that has current admin privileges on the nodes. When omitted, the process will use no credentials (suitable for an unsecure configuration). The ACL Provider will be used to compute the new ACLs. When omitted, the process will set all permissions to all users, removing any security present. You may use the VMParamsSingleSetCredentialsDigestZkCredentialsProvider and VMParamsAllAndReadonlyDigestZkACLProvider as described earlier in the page for these properties. I will upload a new patch shortly.
        Hide
        Gregory Chanan added a comment -

        One thing I'm a bit unclear on from the docs: what is the recommended strategy for changing the permissions? Stop the servers, change the solr.xml, run the ZkCLI command, start the servers? Would be good to specify that.

        What is the current plan with the patch? Do you think it's ready to go or are you still working on more testing?

        Show
        Gregory Chanan added a comment - One thing I'm a bit unclear on from the docs: what is the recommended strategy for changing the permissions? Stop the servers, change the solr.xml, run the ZkCLI command, start the servers? Would be good to specify that. What is the current plan with the patch? Do you think it's ready to go or are you still working on more testing?
        Hide
        Mike Drob added a comment -

        New patch against trunk.

        Going secure -> insecure, probably can do against a running cluster.
        Going to a different secure configuration, yea, would need to update solr.xml. I think that's sufficiently covered in the other sections of the page, though.

        Show
        Mike Drob added a comment - New patch against trunk. Going secure -> insecure, probably can do against a running cluster. Going to a different secure configuration, yea, would need to update solr.xml . I think that's sufficiently covered in the other sections of the page, though.
        Hide
        Gregory Chanan added a comment -

        Going secure -> insecure, probably can do against a running cluster.

        Why probably? Don't you need to update solr.xml?

        Going to a different secure configuration, yea, would need to update solr.xml. I think that's sufficiently covered in the other sections of the page, though.

        Which page are you referring to? https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control? Maybe I'm missing something, but that all seems to be about initial setup.

        Show
        Gregory Chanan added a comment - Going secure -> insecure, probably can do against a running cluster. Why probably? Don't you need to update solr.xml? Going to a different secure configuration, yea, would need to update solr.xml. I think that's sufficiently covered in the other sections of the page, though. Which page are you referring to? https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control? Maybe I'm missing something, but that all seems to be about initial setup.
        Hide
        Mike Drob added a comment -

        Why probably? Don't you need to update solr.xml?

        I was thinking that you don't need to update the Credentials, but now I realize that you would need to update the ACL Provider, otherwise future content will still be locked down.

        Maybe I'm missing something, but that all seems to be about initial setup.

        The steps for initial setup and migration are almost identical, aside from needing to convert existing ACLs.

        How about:

        Swapping ACL Schemes

        Over the lifetime of operating your Solr cluster, you may decide to move from a unsecured ZK to a secured instance. Changing the configured zkACLProvider in solr.xml will ensure that newly created nodes are secure, but will not protect the already existing data. To modify all existing ACLs, you can use ZkCLI -cmd resetacl [path].

        Changing ACLs in ZK should only be done while your SolrCloud cluster is stopped. Attempting to do so while Solr is running may result in inconsistent state and some nodes becoming inaccessible. To configure the new ACLs, run ZkCli with the following VM properties: -DzkACLProvider=... -DzkCredentialsProvider=....

        • The Credential Provider must be one that has current admin privileges on the nodes. When omitted, the process will use no credentials (suitable for an unsecure configuration).
        • The ACL Provider will be used to compute the new ACLs. When omitted, the process will set all permissions to all users, removing any security present.

        You may use the VMParamsSingleSetCredentialsDigestZkCredentialsProvider and VMParamsAllAndReadonlyDigestZkACLProvider implementations as described earlier in the page for these properties.

        After changing the ZK ACLs, make sure that the contents of your solr.xml match, as described for initial set up.

        I made path required to line up better with clear, and to hopefully reduce accidents.

        Aside: There has to be a better way to share this than just pasting my proposed changes in a comment each time.

        Added another test for using the System Properties as well.

        Show
        Mike Drob added a comment - Why probably? Don't you need to update solr.xml? I was thinking that you don't need to update the Credentials, but now I realize that you would need to update the ACL Provider, otherwise future content will still be locked down. Maybe I'm missing something, but that all seems to be about initial setup. The steps for initial setup and migration are almost identical, aside from needing to convert existing ACLs. How about: Swapping ACL Schemes Over the lifetime of operating your Solr cluster, you may decide to move from a unsecured ZK to a secured instance. Changing the configured zkACLProvider in solr.xml will ensure that newly created nodes are secure, but will not protect the already existing data. To modify all existing ACLs, you can use ZkCLI -cmd resetacl [path] . Changing ACLs in ZK should only be done while your SolrCloud cluster is stopped. Attempting to do so while Solr is running may result in inconsistent state and some nodes becoming inaccessible. To configure the new ACLs, run ZkCli with the following VM properties: -DzkACLProvider=... -DzkCredentialsProvider=... . The Credential Provider must be one that has current admin privileges on the nodes. When omitted, the process will use no credentials (suitable for an unsecure configuration). The ACL Provider will be used to compute the new ACLs. When omitted, the process will set all permissions to all users, removing any security present. You may use the VMParamsSingleSetCredentialsDigestZkCredentialsProvider and VMParamsAllAndReadonlyDigestZkACLProvider implementations as described earlier in the page for these properties. After changing the ZK ACLs, make sure that the contents of your solr.xml match, as described for initial set up. I made path required to line up better with clear, and to hopefully reduce accidents. Aside: There has to be a better way to share this than just pasting my proposed changes in a comment each time. Added another test for using the System Properties as well.
        Hide
        Gregory Chanan added a comment -

        Aside: There has to be a better way to share this than just pasting my proposed changes in a comment each time.

        Hmm, you could just go ahead and change the wiki I guess? Don't know of a better way.

        Patch looks good. Some comments:
        1) Provide javadoc for

        +  public Stat setACL(String path, List<ACL> acls, boolean retryOnConnLoss) throws InterruptedException, KeeperException  {
        

        2) Using the @FunctionalInterface stuff means I can't commit this to 5.x, are you okay with that?
        3) The set vs reset in SolrZkClient is kind of confusing. As it stands, set means a single node, reset means recursive. That's not the common usage of the words, e.g. we don't have clean vs reclean to mean a single node vs recursively (there it's delete vs clean). I don't know which terminology to use; reset seems to imply changing from ACLs that existed (either from secure-> other secure or secure->unsecure), while set seems to imply changing from unsecure to secure. This is really a problem with ZooKeeper lacking declarative APIs (what you actually want is an API that says "after this runs, the ACLs are this" – you don't really care how it actually happens). Given that, what makes the most sense to me is to just call everything "set", since this matches the ZK API that you are calling. Maybe instead of setAcl vs resetACLs you should have setAcl vs setAcls or setAcl vs setAclsRecursively. Thoughts?

        Show
        Gregory Chanan added a comment - Aside: There has to be a better way to share this than just pasting my proposed changes in a comment each time. Hmm, you could just go ahead and change the wiki I guess? Don't know of a better way. Patch looks good. Some comments: 1) Provide javadoc for + public Stat setACL( String path, List<ACL> acls, boolean retryOnConnLoss) throws InterruptedException, KeeperException { 2) Using the @FunctionalInterface stuff means I can't commit this to 5.x, are you okay with that? 3) The set vs reset in SolrZkClient is kind of confusing. As it stands, set means a single node, reset means recursive. That's not the common usage of the words, e.g. we don't have clean vs reclean to mean a single node vs recursively (there it's delete vs clean). I don't know which terminology to use; reset seems to imply changing from ACLs that existed (either from secure-> other secure or secure->unsecure), while set seems to imply changing from unsecure to secure. This is really a problem with ZooKeeper lacking declarative APIs (what you actually want is an API that says "after this runs, the ACLs are this" – you don't really care how it actually happens). Given that, what makes the most sense to me is to just call everything "set", since this matches the ZK API that you are calling. Maybe instead of setAcl vs resetACLs you should have setAcl vs setAcls or setAcl vs setAclsRecursively. Thoughts?
        Hide
        Mike Drob added a comment -

        1) Done.
        2) The FunctionalInterface is the right way to do this, but it would be nice to have in 5.x as well. I'm willing to create a separate patch that drops it specifically for 5.x
        3) Naming things is hard, I hadn't considered the possible confusion there but now that you point it out I can't unsee it. Maybe setAcl and updateAcls? updateAllAcl? Is it fine to still call the ZkCli command resetacl? Maybe reinitacl? Original intent was to convey something with gravitas.

        Show
        Mike Drob added a comment - 1) Done. 2) The FunctionalInterface is the right way to do this, but it would be nice to have in 5.x as well. I'm willing to create a separate patch that drops it specifically for 5.x 3) Naming things is hard, I hadn't considered the possible confusion there but now that you point it out I can't unsee it. Maybe setAcl and updateAcls? updateAllAcl? Is it fine to still call the ZkCli command resetacl? Maybe reinitacl? Original intent was to convey something with gravitas.
        Hide
        Gregory Chanan added a comment -

        2) The FunctionalInterface is the right way to do this, but it would be nice to have in 5.x as well. I'm willing to create a separate patch that drops it specifically for 5.x

        Sure, let's do a separate patch if that's what you prefer.

        3) Naming things is hard, I hadn't considered the possible confusion there but now that you point it out I can't unsee it. Maybe setAcl and updateAcls? updateAllAcl? Is it fine to still call the ZkCli command resetacl? Maybe reinitacl? Original intent was to convey something with gravitas.

        I think setAcl and updateAcls is good. I get the gravitas point, but anything with "re" I think is going to cause more confusion because it implies some initial state that may or may not be true. I'd just match the ZkCli command name to the SolrZkClient function name, so in this case updateAcls. But if you feel really strongly for something else, let's do that.

        Show
        Gregory Chanan added a comment - 2) The FunctionalInterface is the right way to do this, but it would be nice to have in 5.x as well. I'm willing to create a separate patch that drops it specifically for 5.x Sure, let's do a separate patch if that's what you prefer. 3) Naming things is hard, I hadn't considered the possible confusion there but now that you point it out I can't unsee it. Maybe setAcl and updateAcls? updateAllAcl? Is it fine to still call the ZkCli command resetacl? Maybe reinitacl? Original intent was to convey something with gravitas. I think setAcl and updateAcls is good. I get the gravitas point, but anything with "re" I think is going to cause more confusion because it implies some initial state that may or may not be true. I'd just match the ZkCli command name to the SolrZkClient function name, so in this case updateAcls. But if you feel really strongly for something else, let's do that.
        Hide
        Mike Drob added a comment -

        Patch with command renamed to UpdateACLs.

        Show
        Mike Drob added a comment - Patch with command renamed to UpdateACLs.
        Hide
        Gregory Chanan added a comment -

        Here's a patch with some minor changes:

        • Changed UPDATEACL to UPDATEACLS to match the constant value
        • Changed the constant value from updateAcls to updateacls for consistency and the test seems to fail without it
        • Added retryOnConnLoss to javadoc

        I'll commit this assuming the tests pass.

        Show
        Gregory Chanan added a comment - Here's a patch with some minor changes: Changed UPDATEACL to UPDATEACLS to match the constant value Changed the constant value from updateAcls to updateacls for consistency and the test seems to fail without it Added retryOnConnLoss to javadoc I'll commit this assuming the tests pass.
        Hide
        ASF subversion and git services added a comment -

        Commit 1724532 from gchanan@apache.org in branch 'dev/trunk'
        [ https://svn.apache.org/r1724532 ]

        SOLR-8415: Provide command to switch between non/secure mode in ZK

        Show
        ASF subversion and git services added a comment - Commit 1724532 from gchanan@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1724532 ] SOLR-8415 : Provide command to switch between non/secure mode in ZK
        Hide
        Gregory Chanan added a comment -

        committed to trunk. Mike Drob if you post a 5x patch, I'll commit.

        Show
        Gregory Chanan added a comment - committed to trunk. Mike Drob if you post a 5x patch, I'll commit.
        Hide
        Mike Drob added a comment -

        Attaching a --no-prefix patch for branch 5.

        Show
        Mike Drob added a comment - Attaching a --no-prefix patch for branch 5.
        Hide
        Gregory Chanan added a comment -

        branch 5 patch seems to be based on a previously posted patch, not what was committed. Attached a version based on the committed version.

        Show
        Gregory Chanan added a comment - branch 5 patch seems to be based on a previously posted patch, not what was committed. Attached a version based on the committed version.
        Hide
        ASF subversion and git services added a comment -

        Commit bc1cbb4812fe76f100788795189d1f2d9833aed1 in lucene-solr's branch refs/heads/branch_5x from Gregory Chanan
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bc1cbb4 ]

        SOLR-8415: Provide command to switch between non/secure mode in ZK

        Show
        ASF subversion and git services added a comment - Commit bc1cbb4812fe76f100788795189d1f2d9833aed1 in lucene-solr's branch refs/heads/branch_5x from Gregory Chanan [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bc1cbb4 ] SOLR-8415 : Provide command to switch between non/secure mode in ZK
        Hide
        Gregory Chanan added a comment -

        Thanks Mike. In addition to the previous Trunk commit, also committed to 5.5.

        Show
        Gregory Chanan added a comment - Thanks Mike. In addition to the previous Trunk commit, also committed to 5.5.
        Hide
        Mike Drob added a comment -

        What's the process for updating the Ref Guide? Should I open a new JIRA for that so my comments don't get lost?

        Show
        Mike Drob added a comment - What's the process for updating the Ref Guide? Should I open a new JIRA for that so my comments don't get lost?
        Hide
        Cassandra Targett added a comment -

        Is the most recent snippet up-to-date? I haven't read the entire issue, but it looks like the most recent snippet refers to resetacl, but then that was changed?

        If it's ready to go, I'll put it in the Ref Guide now to not forget. The other approach would be to add the text as a comment to the page you want to add it to and someone will pick those up (eventually, before 5.5 comes out).

        Show
        Cassandra Targett added a comment - Is the most recent snippet up-to-date? I haven't read the entire issue, but it looks like the most recent snippet refers to resetacl , but then that was changed? If it's ready to go, I'll put it in the Ref Guide now to not forget. The other approach would be to add the text as a comment to the page you want to add it to and someone will pick those up (eventually, before 5.5 comes out).
        Hide
        Mike Drob added a comment -

        Yes, that needs to be changed. Here's a fully updated section.

        Changing ACL Schemes

        Over the lifetime of operating your Solr cluster, you may decide to move from a unsecured ZK to a secured instance. Changing the configured zkACLProvider in solr.xml will ensure that newly created nodes are secure, but will not protect the already existing data. To modify all existing ACLs, you can use ZkCLI -cmd updateAcls /zk-path.

        Changing ACLs in ZK should only be done while your SolrCloud cluster is stopped. Attempting to do so while Solr is running may result in inconsistent state and some nodes becoming inaccessible. To configure the new ACLs, run ZkCli with the following VM properties: -DzkACLProvider=... -DzkCredentialsProvider=....

        • The Credential Provider must be one that has current admin privileges on the nodes. When omitted, the process will use no credentials (suitable for an unsecure configuration).
        • The ACL Provider will be used to compute the new ACLs. When omitted, the process will set all permissions to all users, removing any security present.

        You may use the VMParamsSingleSetCredentialsDigestZkCredentialsProvider and VMParamsAllAndReadonlyDigestZkACLProvider implementations as described earlier in the page for these properties.

        After changing the ZK ACLs, make sure that the contents of your solr.xml match, as described for initial set up.

        Show
        Mike Drob added a comment - Yes, that needs to be changed. Here's a fully updated section. Changing ACL Schemes Over the lifetime of operating your Solr cluster, you may decide to move from a unsecured ZK to a secured instance. Changing the configured zkACLProvider in solr.xml will ensure that newly created nodes are secure, but will not protect the already existing data. To modify all existing ACLs, you can use ZkCLI -cmd updateAcls /zk-path . Changing ACLs in ZK should only be done while your SolrCloud cluster is stopped. Attempting to do so while Solr is running may result in inconsistent state and some nodes becoming inaccessible. To configure the new ACLs, run ZkCli with the following VM properties: -DzkACLProvider=... -DzkCredentialsProvider=... . The Credential Provider must be one that has current admin privileges on the nodes. When omitted, the process will use no credentials (suitable for an unsecure configuration). The ACL Provider will be used to compute the new ACLs. When omitted, the process will set all permissions to all users, removing any security present. You may use the VMParamsSingleSetCredentialsDigestZkCredentialsProvider and VMParamsAllAndReadonlyDigestZkACLProvider implementations as described earlier in the page for these properties. After changing the ZK ACLs, make sure that the contents of your solr.xml match, as described for initial set up.
        Hide
        Gregory Chanan added a comment -

        the command is updateacls, not updateAcls.

        Show
        Gregory Chanan added a comment - the command is updateacls, not updateAcls.
        Hide
        Mike Drob added a comment -

        So it is.

        Show
        Mike Drob added a comment - So it is.
        Hide
        Cassandra Targett added a comment -

        No problem, I'll fix it when I put it in the Ref Guide.

        Show
        Cassandra Targett added a comment - No problem, I'll fix it when I put it in the Ref Guide.
        Hide
        Cassandra Targett added a comment -

        Please take a look at https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control. I decided to make it a level-2 heading and put it in the section with the other config options, since I thought it would be easier to find there.

        Show
        Cassandra Targett added a comment - Please take a look at https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control . I decided to make it a level-2 heading and put it in the section with the other config options, since I thought it would be easier to find there.
        Hide
        Mike Drob added a comment -

        +1

        Show
        Mike Drob added a comment - +1

          People

          • Assignee:
            Gregory Chanan
            Reporter:
            Mike Drob
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development