You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Rakesh R (JIRA)" <ji...@apache.org> on 2017/10/21 04:43:00 UTC
[jira] [Comment Edited] (ZOOKEEPER-2793) [QP MutualAuth]: Implement
a mechanism to build "authzHosts" for dynamic reconfig servers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16213715#comment-16213715 ]
Rakesh R edited comment on ZOOKEEPER-2793 at 10/21/17 4:42 AM:
---------------------------------------------------------------
Thanks [~phunt] for the comments. Below is my reply,
bq. Perhaps it should be /zookeeper/ensemble/authorized_hosts ?
Agreed.
bq. Can you be more explicit in the definition of a valid value. e.g. do we allow IP addresses or just host names or....
Following are the two ways supported for the principal names.
1) Single shared Kerberos principal name configured in all the servers >>> servicename/localhost@EXAMPLE.COM
2) Host based Kerberos principal name with _HOST wildcard >>>> servicename/fully.qualified.domain.name@EXAMPLE.COM
Below are the possible values of {{/zookeeper/ensemble/authorized_hosts}}.
{{localhost}} or {{FQDN1,FQDN2,FQDN3,..}}
bq. "Admin can update" - what specifically will that map to (acl/id/...) and will operators be able to change this?
I missed this case. How about introducing add/removal/list ZooKeeperAdmin apis similar to reconfig {{"/zookeeper/config"}} and add default ZooDefs.Ids.READ_ACL_UNSAFE to znode {{/zookeeper/ensemble/authorized_hosts}}?
bq. What will happen if the authorized_hosts scope is reduced, say a host that's already part of the quorum is removed from this list, what (if anything, perhaps nothing) will happen?
{{authorized_hosts}} is used during FLE and the authorized_hosts is no more used after FLE process. Assume, quorum lost and also host entry is removed from authorized_hosts, now during re-election authorized_hosts will be again used and throws exception saying "host is not authorized to connect". To handle this, we can restrict removing quorum's host from {{authorized_hosts}}. Should we ?
bq. Is it possible to log changes to this znode in particular? So that we capture in the server logs. auditing purposes, etc...
I think, it is possible and let me try including this.
bq. What keeps me from accidentally messing up the value and then not being able to change the value thereafter. Say the value is corrupted and no peers can form a quorum. How will I update the value of the znode at this stage.
Apart from the following case any other way the corruption can occur - if we allows to remove and then add back the host which is part of the quorum, isn't it?
Proposed Fix : How about restricting removal of a host which is presently part of the quorum so that the quorum won't be disturbed.
was (Author: rakeshr):
Thanks [~phunt] for the comments. Below is my reply,
bq. Perhaps it should be /zookeeper/ensemble/authorized_hosts ?
Agreed.
bq. Can you be more explicit in the definition of a valid value. e.g. do we allow IP addresses or just host names or....
Following are the two ways supported for the principal names.
1) Single shared Kerberos principal name configured in all the servers >>> servicename/localhost@EXAMPLE.COM
2) Host based Kerberos principal name with _HOST wildcard >>>> servicename/fully.qualified.domain.name@EXAMPLE.COM
Below are the possible values of {{/zookeeper/ensemble/authorized_hosts}}.
{{localhost}} or {{FQDN1,FQDN2,FQDN3,..}}
bq. "Admin can update" - what specifically will that map to (acl/id/...) and will operators be able to change this?
I missed this case. How about introducing add/removal/list ZooKeeperAdmin apis similar to reconfig {{"/zookeeper/config"}} and add default ZooDefs.Ids.READ_ACL_UNSAFE to znode {{/zookeeper/ensemble/authorized_hosts}}?
bq. What will happen if the authorized_hosts scope is reduced, say a host that's already part of the quorum is removed from this list, what (if anything, perhaps nothing) will happen?
{{authorized_hosts}} is used during FLE and the authorized_hosts is no more used after FLE process. Assume, if the quorum lost then during re-election {{authorized_hosts}} will be again used and throws exception saying "host is not authorized to connect". Should we restrict removing a used host from {{authorized_hosts}} ?
bq. Is it possible to log changes to this znode in particular? So that we capture in the server logs. auditing purposes, etc...
Let me consider this point. I think, it is possible.
bq. What keeps me from accidentally messing up the value and then not being able to change the value thereafter. Say the value is corrupted and no peers can form a quorum. How will I update the value of the znode at this stage.
Apart from the following case any other case the corruption can occur - if we allows to remove and then add back the host which is part of the quorum, isn't it?
Proposed Fix : How about restricting removal of a host which is presently part of the quorum so that the quorum won't be disturbed.
> [QP MutualAuth]: Implement a mechanism to build "authzHosts" for dynamic reconfig servers
> -----------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-2793
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2793
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: quorum, security
> Reporter: Rakesh R
> Assignee: Rakesh R
> Fix For: 3.5.4, 3.6.0
>
>
> {{QuorumServer}} will do the authorization checks against configured authorized hosts. During LE, QuorumLearner will send an authentication packet to QuorumServer. Now, QuorumServer will check that the connecting QuorumLearner’s hostname exists in the authorized hosts. If not exists then connecting peer is not authorized to join this ensemble and the request will be rejected immediately.
> In {{branch-3.4}} building {{authzHosts}} list is pretty straight forward, can use the ensemble server details in zoo.cfg file. But with dynamic reconfig, it has to consider the dynamic add/remove/update servers and need to discuss the ways to handle dynamic cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)