[jira] [Created] (ZOOKEEPER-3514) Use client certificate SAN list for X.509 ACL AuthZ
Jon Bringhurst created ZOOKEEPER-3514:
-
Summary: Use client certificate SAN list for X.509 ACL AuthZ
Key: ZOOKEEPER-3514
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3514
Project: ZooKeeper
Issue Type: Improvement
Reporter: Jon Bringhurst
Hello! We have a TLS environment where services currently utilize various
client certificate SAN fields for authentication. For example, a client
certificate would look contain something like this:
{noformat}
X509v3 Subject Alternative Name: critical
DNS:zookeeper-server-001.example.com, URI:APPLICATION_NAME,
URI:DATACENTER_NAME
{noformat}
My current approach is to simply add the SAN list to the cnxn AuthInfo list.
For example:
{noformat}
protected List getAlternativeClientIds(X509Certificate clientCert) {
return clientCert.getSubjectAlternativeNames();
}
{noformat}
{noformat}
if (this.sslAclIncludeSANAuthZEnabled) {
List alternativeClientIds =
getAlternativeCLientIds(clientCert);
for (int i = 0; i < alternativeClientIds.size(); i++) {
Id altAuthInfo = new Id(getScheme(),
alternativeClientIds.get(i));
cnxn.addAuthInfo(altAuthInfo);
LOG.info("Authenticated Alternative Id '{}' for Scheme '{}'",
altAuthInfo.getId(), altAuthInfo.getScheme());
}
}
{noformat}
So, ACLs would then look something like this:
{noformat}
x509:zookeeper-server-001.example.com:perm
x509:APPLICATION_NAME:perm
x509:DATACENTER_NAME:perm
{noformat}
Before I spend time to put it together, would a patch for this functionality
have any chance of being accepted? :)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (ZOOKEEPER-1281) Stat and srvr 4 letter commands are useless on the leader when leaderServes = false
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16170283#comment-16170283
]
Jon Bringhurst edited comment on ZOOKEEPER-1281 at 9/18/17 4:52 PM:
{quote}
Is there a workaround for this that people are using when monitoring their
Zookeeper ensemble?
{quote}
We've been using Jolokia (http://jolokia.org) attached to the Zookeeper process
with a Python agent that hits the http endpoint, runs through the
org.apache.ZooKeeperService mbeans, then finally emits various metrics
(including if the server is a participant, leader, or observer) to our
monitoring system.
See https://zookeeper.apache.org/doc/r3.4.6/zookeeperJMX.html to get a
non-exhaustive list of what metrics you can get from Zookeeper's mbeans. This
setup has worked well for monitoring our 80+ Zookeeper clusters for several
years now.
was (Author: jonbringhurst):
{quote}
Is there a workaround for this that people are using when monitoring their
Zookeeper ensemble?
{quote}
We've been using Jolokia (http://jolokia.org) attached to the Zookeeper process
with a Python agent that hits the http endpoint, runs through the
org.apache.ZooKeeperService mbeans, then finally emits various metrics
(including if the server is a participant, leader, or observer) to our
monitoring system. See
https://zookeeper.apache.org/doc/r3.4.6/zookeeperJMX.html to get a
non-exhaustive list of what metrics you can get from Zookeeper's mbeans. This
setup has worked well for monitoring our 80+ Zookeeper clusters for several
years now.
> Stat and srvr 4 letter commands are useless on the leader when leaderServes =
> false
> ---
>
> Key: ZOOKEEPER-1281
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1281
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.3.3
>Reporter: Daniel Lord
>
> When leaderServes = false the leader responds to the stat/srvr letter words
> with simply "this ZooKeeper instance is not currently serving requests".
> While I agree that is an accurate statement it's not terribly useful for
> monitoring programs. Additionally, if members of the ensemble are not
> currently in the quorum it becomes impossible to tell who is out of the
> quorum and who is the leader of the quorum.
> I'm not sure if the leader should have a specially formatted response for
> stat/srvr or if it should simply display less information (no connections for
> example).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ZOOKEEPER-1281) Stat and srvr 4 letter commands are useless on the leader when leaderServes = false
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16170283#comment-16170283
]
Jon Bringhurst commented on ZOOKEEPER-1281:
---
{quote}
Is there a workaround for this that people are using when monitoring their
Zookeeper ensemble?
{quote}
We've been using Jolokia (http://jolokia.org) attached to the Zookeeper process
with a Python agent that hits the http endpoint, runs through the
org.apache.ZooKeeperService mbeans, then finally emits various metrics
(including if the server is a participant, leader, or observer) to our
monitoring system. See
https://zookeeper.apache.org/doc/r3.4.6/zookeeperJMX.html to get a
non-exhaustive list of what metrics you can get from Zookeeper's mbeans. This
setup has worked well for monitoring our 80+ Zookeeper clusters for several
years now.
> Stat and srvr 4 letter commands are useless on the leader when leaderServes =
> false
> ---
>
> Key: ZOOKEEPER-1281
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1281
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.3.3
>Reporter: Daniel Lord
>
> When leaderServes = false the leader responds to the stat/srvr letter words
> with simply "this ZooKeeper instance is not currently serving requests".
> While I agree that is an accurate statement it's not terribly useful for
> monitoring programs. Additionally, if members of the ensemble are not
> currently in the quorum it becomes impossible to tell who is out of the
> quorum and who is the leader of the quorum.
> I'm not sure if the leader should have a specially formatted response for
> stat/srvr or if it should simply display less information (no connections for
> example).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ZOOKEEPER-1237) ERRORs being logged when queued responses are sent after socket has closed.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14041348#comment-14041348
]
Jon Bringhurst commented on ZOOKEEPER-1237:
---
[~clarkhaskins]'s stack trace is for Zookeeper 3.3.4.
> ERRORs being logged when queued responses are sent after socket has closed.
> ---
>
> Key: ZOOKEEPER-1237
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1237
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.3.4, 3.4.0, 3.5.0
>Reporter: Patrick Hunt
> Fix For: 3.5.0
>
> Attachments: zookeeper-3.4.5-ZK1237.patch
>
>
> After applying ZOOKEEPER-1049 to 3.3.3 (I believe the same problem exists in
> 3.4/3.5 but haven't tested this) I'm seeing the following exception more
> frequently:
> {noformat}
> Oct 19, 1:31:53 PM ERROR
> Unexpected Exception:
> java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:59)
> at
> org.apache.zookeeper.server.NIOServerCnxn.sendBuffer(NIOServerCnxn.java:418)
> at
> org.apache.zookeeper.server.NIOServerCnxn.sendResponse(NIOServerCnxn.java:1509)
> at
> org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:367)
> at
> org.apache.zookeeper.server.quorum.CommitProcessor.run(CommitProcessor.java:73)
> {noformat}
> This is a long standing problem where we try to send a response after the
> socket has been closed. Prior to ZOOKEEPER-1049 this issues happened much
> less frequently (2 sec linger), but I believe it was possible. The timing
> window is just wider now.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
