[jira] [Commented] (ZOOKEEPER-3914) Kerberized Zookeeper doesn't drop connection for unauthenticated clients
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183017#comment-17183017
]
Mate Szalay-Beko commented on ZOOKEEPER-3914:
-
there is this authentication enforcement feature implemented in 3.6.0:
https://issues.apache.org/jira/browse/ZOOKEEPER-1634
did you try this option? {{zookeeper.sessionRequireClientSASLAuth}}
The {{zookeeper.allowSaslFailedClients=false}} you use will cause that whoever
is failing to authenticate (e.g. using a wrong password / keytab file) won't be
able to connect to ZooKeeper with the same privileges as an unauthenticated
user. But still this parameter will not prevent anyone to connect without using
authentication mechanism. ZooKeeper by default allows anyone to connect, but
the unauthenticated clients usually have very limited access, as all the
sensitive zNodes should be 'protected' with proper ACLs on a secure cluster.
> Kerberized Zookeeper doesn't drop connection for unauthenticated clients
>
>
> Key: ZOOKEEPER-3914
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3914
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.6
>Reporter: Ella Kurginyan
>Priority: Critical
>
> my zoo.cfg:
> {code:java}
> tickTime=2000
> initLimit=5
> syncLimit=2
> dataDir=/var/lib/zookeeper
> clientPort=2181
> maxClientCnxns=0
> autopurge.snapRetainCount=3
> autopurge.purgeInterval=24
> standaloneEnabled=false
> authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
> zookeeper.allowSaslFailedClients=false
> jaasLoginRenew=360
> kerberos.removeHostFromPrincipal=true
> kerberos.removeRealmFromPrincipal=true
> server.1=myhost.internal:2888:3888
> {code}
>
> zookeeper-env.sh
> {code:java}
> export JAVA="$JAVA_HOME/bin/java"
> export ZOO_LOG4J_PROP="DEBUG, CONSOLE, ROLLINGFILE"
> export ZOO_LOG_DIR="/var/log/zookeeper"
> export ZOOPIDFILE="/var/run/zookeeper/zookeeper_server.pid"
> export
> SERVER_JVMFLAGS="-Djava.security.auth.login.config=/etc/zookeeper/conf/zookeeper_server_jaas.conf"
> export CLIENT_JVMFLAGS="$CLIENT_JVMFLAGS
> -Djava.security.auth.login.config=/etc/zookeeper/conf/zookeeper_client_jaas.conf"
> {code}
>
> zookeeper_server_jaas.conf:
> {code:java}
> Server {
> com.sun.security.auth.module.Krb5LoginModule required
> doNotPrompt=true
> useKeyTab=true
> storeKey=true
> useTicketCache=false
> keyTab="/tmp/keytabs/zookeeper.keytab"
> principal="zookeeper/myhost.inter...@mydomain.com";
> };{code}
> zookeeper_client_jaas.conf:
> {code:java}
> Client {
> com.sun.security.auth.module.Krb5LoginModule required
> useKeyTab=false
> useTicketCache=true;
> };{code}
> For anonymous user its allowed to connect:
> {code:java}
> 2020-08-17 13:58:18,603 - WARN
> [main-SendThread(localhost:2181):SaslClientCallbackHandler@60] - Could not
> login: the Client is being asked for a password, but the ZooKeeper Client
> code does not currently support obtaining a password from the user. Make sure
> that the Client is configured to use a ticket cache (using the JAAS
> configuration setting 'useTicketCache=true)' and restart the Client. If you
> still get this message after that, the TGT in the ticket cache has expired
> and must be manually refreshed. To do so, first determine if you are using a
> password or a keytab. If the former, run kinit in a Unix shell in the
> environment of the user who is running this Zookeeper Client using the
> command 'kinit ' (where is the name of the Client's Kerberos
> principal). If the latter, do 'kinit -k -t ' (where
> is the name of the Kerberos principal, and is the location of the
> keytab file). After manually refreshing your cache, restart this Client. If
> you continue to see this message after manually refreshing your cache, ensure
> that your KDC host's clock is in sync with this host's clock. 2020-08-17
> 13:58:18,604 - WARN
> [main-SendThread(localhost:2181):ClientCnxn$SendThread@1010] - SASL
> configuration failed: javax.security.auth.login.LoginException: No password
> provided Will continue connection to Zookeeper server without SASL
> authentication,if Zookeeper server allows it. 2020-08-17 13:58:18,606 - INFO
> [main-SendThread(localhost:2181):ClientCnxn$SendThread@1028] - Opening socket
> connection to server localhost/0:0:0:0:0:0:0:1:2181 WATCHER:: WatchedEvent
> state:AuthFailed type:None path:null 2020-08-17 13:58:18,653 - INFO
> [main-SendThread(localhost:2181):ClientCnxn$SendThread@878] - Socket
> connection established to localhost/0:0:0:0:0:0:0:1:2181, initiating session
> 2020-08-17 13:58:18,662 - INFO
> [main-SendThread(localhost:2181):ClientCnxn$SendThread@1302] - Session
> establishment complete on server localhost/0:0:0:0:0:0:0:1:2181, sessionid =
> 0x10
[jira] [Resolved] (ZOOKEEPER-3893) Enhance documentation for property ssl.clientAuth
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mate Szalay-Beko resolved ZOOKEEPER-3893. - Fix Version/s: 3.6.3 3.7.0 3.5.9 Resolution: Fixed Issue resolved by pull request 1405 [https://github.com/apache/zookeeper/pull/1405] > Enhance documentation for property ssl.clientAuth > -- > > Key: ZOOKEEPER-3893 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3893 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Sankalp Bhatia >Assignee: Sankalp Bhatia >Priority: Minor > Fix For: 3.5.9, 3.7.0, 3.6.3 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Currently, the documentation for this property just mentions TBD (check > [https://zookeeper.apache.org/doc/r3.5.7/zookeeperAdmin.html]). I believe > this was ignored until versions 3.5.7 > (https://issues.apache.org/jira/browse/ZOOKEEPER-3674) and a fix was made. It > will be good to add some documentation around it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3917) add the notation
Pengfei Yan created ZOOKEEPER-3917: -- Summary: add the notation Key: ZOOKEEPER-3917 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3917 Project: ZooKeeper Issue Type: Improvement Components: quorum Reporter: Pengfei Yan h1. add the notation for different mode, i.e. Leader, Observer, Follower, and so on -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3912) 4LW MNTR command outputs in float when prometheus activated
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183238#comment-17183238
]
maoling commented on ZOOKEEPER-3912:
I tested the admin command(*wget http://localhost:8080/commands/monitor)* and
*echo mntr | nc 127.0.0.1 2183*, both showed *synced_followers* is float.
{code:java}
"synced_followers" : 2.0, "revalidate_count" : 0.0, "watch_bytes" : 0.0,
zk_synced_followers 2.0 zk_revalidate_count 0.0 zk_watch_bytes 0.0
{code}
But the code said *synced_followers* is a Integer.
{code:java}
* - "fsync_threshold_exceed_count": Long
* - "followers": Integer (leader only)
* - "synced_followers": Integer (leader only)
* - "pending_syncs": Integer (leader only)
*/
public static class MonitorCommand extends CommandBase
{code}
[~der_eismann] Could you please help us improve the *mntr* related doc in the
*zookeeperAdmin.md*
> 4LW MNTR command outputs in float when prometheus activated
> ---
>
> Key: ZOOKEEPER-3912
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3912
> Project: ZooKeeper
> Issue Type: Bug
> Components: metric system
>Affects Versions: 3.6.1
>Reporter: Philipp Trulson
>Priority: Major
>
> We use zookeeper 3.6.1 in combination with solr 8.6.0 on our kubernetes
> cluster. For monitoring purposes we activated the prometheus metrics for
> zookeeper, which had the unexpected side effect that the 4lw mntr command now
> also outputs floats instead of the usual integers. This broke the parser on
> the solr side (SOLR-14752), because it was expecting ints.
> This ticket is to discuss if this is actually a bug or expected behavior
> because this change isn't mentioned anywhere in the release notes or
> documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3918) Authorization Provider: Integration with external identity and access management
Peter Welch created ZOOKEEPER-3918: -- Summary: Authorization Provider: Integration with external identity and access management Key: ZOOKEEPER-3918 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3918 Project: ZooKeeper Issue Type: Improvement Components: server Reporter: Peter Welch New Feature: Add the ability to integrate with an external Identity and access management (ACL) system to provide an additional authorization mechanism. For an organization that manages identities and ACLs (access control lists) in an external system - provide a framework in Zookeeper to apply access control backed on a replica of the external systems' ACLs. The focus is on X509 Identities and a set of simple access control list primitives. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3919) Add ARM64 jobs to Travis-CI
odidev created ZOOKEEPER-3919: - Summary: Add ARM64 jobs to Travis-CI Key: ZOOKEEPER-3919 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3919 Project: ZooKeeper Issue Type: Improvement Reporter: odidev As zoopkeeper supports ARM64 architecture, It would be reasonable to add ARM64 jobs to Travis-CI as well. Refer this PR for details : https://github.com/apache/zookeeper/pull/1433 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3919) Add ARM64 jobs to Travis-CI
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183743#comment-17183743 ] odidev commented on ZOOKEEPER-3919: --- *Add ARM64 jobs to Travis-CI* > Add ARM64 jobs to Travis-CI > --- > > Key: ZOOKEEPER-3919 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3919 > Project: ZooKeeper > Issue Type: Improvement >Reporter: odidev >Priority: Major > > As zoopkeeper supports ARM64 architecture, It would be reasonable to add > ARM64 jobs to Travis-CI as well. > Refer this PR for details : https://github.com/apache/zookeeper/pull/1433 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3912) 4LW MNTR command outputs in float when prometheus activated
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183760#comment-17183760 ] maoling commented on ZOOKEEPER-3912: I also found that when prometheus disables, synced_followers is a integer. However, when enables, it became a float. Cc [~eolivelli] > 4LW MNTR command outputs in float when prometheus activated > --- > > Key: ZOOKEEPER-3912 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3912 > Project: ZooKeeper > Issue Type: Bug > Components: metric system >Affects Versions: 3.6.1 >Reporter: Philipp Trulson >Priority: Major > > We use zookeeper 3.6.1 in combination with solr 8.6.0 on our kubernetes > cluster. For monitoring purposes we activated the prometheus metrics for > zookeeper, which had the unexpected side effect that the 4lw mntr command now > also outputs floats instead of the usual integers. This broke the parser on > the solr side (SOLR-14752), because it was expecting ints. > This ticket is to discuss if this is actually a bug or expected behavior > because this change isn't mentioned anywhere in the release notes or > documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
