[
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/localh...@example.com
2) Host based Kerberos principal name with _HOST wildcard >>>>
servicename/fully.qualified.domain.n...@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/localh...@example.com
2) Host based Kerberos principal name with _HOST wildcard >>>>
servicename/fully.qualified.domain.n...@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)
