Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 13 Oct 2015 11:31:06 +0000 (UTC)
From: "Sam Tunnicliffe (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12856608.1439816261000.23195.1444735866247@Atlassian.JIRA>
In-Reply-To: <JIRA.12856608.1439816261000@Atlassian.JIRA>
References: <JIRA.12856608.1439816261000@Atlassian.JIRA>
 <JIRA.12856608.1439816261379@arcas>
Subject: [jira] [Comment Edited] (CASSANDRA-10091) Align JMX authentication
 with internal authentication
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-10091?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D14954795#comment-14954795 ]=20

Sam Tunnicliffe edited comment on CASSANDRA-10091 at 10/13/15 11:30 AM:
------------------------------------------------------------------------

Thanks for the patch, I think this will make a great feature provided we ca=
n figure out a few issues. Please excuse the wall of text coming up...

My main concern from the authn side of things is the use of {{IAuthenticato=
r::legacyAuthenticate}}. While this works fine for {{PasswordAuthenticator}=
}, the method is optional and only really intended to support legacy Thrift=
 authentication (the fact that {{PasswordAuthenticator}} uses it internally=
 during CQL authentication is an implementation detail). The preferred meth=
od for authentication is through SASL, which allows a wider variety of back=
ends to be plugged in. I know that in the wild there are custom implementat=
ions which use this mechanism to do stuff like Kerberos authentication and =
clusters using those authenticators wouldn't be able to make use of this fu=
nctionality (or at least I can't see how they could as it stands). It would=
 be ideal if we could have {{JMXAuthenticator}} plug into the SASL auth cod=
e and make use of {{IAuthenticator::newSaslAuthenticator}}.=20

I'd like to investigate further, but it looks like this could be possible u=
sing [JMXMP|https://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/].=
 We could switch the connection to JMXMP if configured with advanced JMX au=
th and I think it should be possible to then define a custom {{SaslServer}}=
 which wraps a {{SaslNegotiator}} instance provided by the configured {{IAu=
thenticator}}. Note that I haven't actually *tried* to do this, but reading=
 [the JMXMP docs|http://docs.oracle.com/cd/E19698-01/816-7609/6mdjrf873/], =
particularly section *11.4.2 SASL Provider*, it seems feasible.

On the authz side, I also have a couple of remarks/suggestions.

I'm not a big fan of adding {{IAuthorizer::authorizeJMX}}. One reason is th=
at it's going to require all custom implementations to add a new method bef=
ore upgrading (even though implementors could make that a no-op and require=
 that users don't enable JMX authz). More generally though, it feels bad to=
 special case JMX resources in this this way, and I wouldn't want to set a =
precedent of adding a special authentication method for a particular resour=
ce type, I'd rather think some more about how the resources are modelled an=
d whether that can be changed to fit what's already there bit better. I thi=
nk the fundamental issue with {{JMXResource}} is that JMX {{ObjectName}} is=
 not really hierarchical, but pattern based. For example, with {{DataResour=
ce}}, we're able to grant permissions on a particular keyspace and have tho=
se apply automatically to all tables in the keyspace. I don't think that ki=
nd of hierarchy can be modelled using {{ObjectName}}. On the surface, it se=
ems like something it should be possible by granting perms on {{org.apache.=
cassandra.db:type=3DColumnFamilies,keyspace=3D<keyspace>,columnfamily=3D\*}=
}, but the equally valid mbean name {{org.apache.cassandra.db:type=3DColumn=
Families,keyspace=3D*,columnfamily=3D<table>}} clearly sits outside the hie=
rarchy, and necessitates the special handling of wildcards & patterns which=
 in turn requires {{IAuthorizer::authorizeJMX}}.

I propose a simplification to {{JMXResource}} to allow only fully qualified=
 bean names, with no support for wildcards or pattern matching. I would int=
roduce a level representing the domain into the hierarchy, so that permissi=
ons can be applied at that level, or for specific beans. So the hierarchy w=
ould be {{ROOT/DOMAIN/MBEAN}} where {{MBEAN}} would represent a full set of=
 key/value pairs. The constructor of {{JMXResource}} should canonicalise th=
e key/value pairs in a way consistent with {{ObjectName::getCanonicalKeyPro=
pertyListString}} so that authorizers can do a simple lexical comparision. =
So the some example mappings between an MBean and the corresponding {{JMXRe=
source}} would look like:

||MBean ObjectName||JMXResource||
|org.apache.cassandra.db:type=3DColumnFamilies,keyspace=3Dks,columnfamily=
=3Dtable1|mbeans/org.apache.cassandra.db/type=3DColumnFamilies,keyspace=3Dt=
able1|
|org.apache.cassandra.metrics:name=3DTotalBlockedTasks,path=3Dtransport,sco=
pe=3DNative-Transport-Requests,type=3DThreadPools|mbeans/org.apache.cassand=
ra.metrics/name=3DTotalBlockedTasks,path=3Dtransport,scope=3DNative-Transpo=
rt-Requests,type=3DThreadPools
|java.lang:name=3DG1 Old Gen,type=3DMemoryPool|mbeans/java.lang/name=3DG1 O=
ld Gen,type=3DMemoryPool|

On a related note, it also feels wrong to special case permissions on JMX r=
esources. I'd much prefer it if we could re-use the existing permissions, w=
hich I think we probably can do. It seems as though the proposed new permis=
sions in the patch actually map pretty well to existing perms.=20

||Proposed MB permssion||Existing permission||
|MBGET|SELECT|
|MBSET|MODIFY|
|MBQUERYNAMES|DESCRIBE|
|MBINSTANCEOF|DESCRIBE|
|MBEXECUTE|EXECUTE|
|MBINVOKE|EXECUTE|

I wouldn't bother with the meta-permissions {{MBREAD}} and {{MBWRITE}} as t=
heir existing equivalents are already deprecated.=20

If the consensus is that the semantics of the MBean operations really don't=
 match the existing permission then it would be better to figure out what i=
t is generically that's missing and add new permissions to express that, on=
e which should be re-usable for future, non-JMX resource types.=20

Although the current patch isn't huge by any means, it might also be worth =
splitting this into 2 separate issues, one each for authentication and auth=
orization.=20

I should also say that there's no way this can target 2.2 or even 3.0, so I=
'll update the fixver to 3.x


was (Author: beobal):
Thanks for the patch, I think this will make a great feature provided we ca=
n figure out a few issues. Please excuse the wall of text coming up...

My main concern from the authn side of things is the use of {{IAuthenticato=
r::legacyAuthenticate}}. While this works fine for {{PasswordAuthenticator}=
}, the method is optional and only really intended to support legacy Thrift=
 authentication (the fact that {{PasswordAuthenticator}} uses it internally=
 during CQL authentication is an implementation detail). The preferred meth=
od for authentication is through SASL, which allows a wider variety of back=
ends to be plugged in. I know that in the wild there are custom implementat=
ions which use this mechanism to do stuff like Kerberos authentication and =
clusters using those authenticators wouldn't be able to make use of this fu=
nctionality (or at least I can't see how they could as it stands). It would=
 be ideal if we could have {{JMXAuthenticator}} plug into the SASL auth cod=
e and make use of {{IAuthenticator::newSaslAuthenticator}}.=20

I'd like to investigate further, but it looks like this could be possible u=
sing [JMXMP|https://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/].=
 We could switch the connection to JMXMP if configured with advanced JMX au=
th and I think it should be possible to then define a custom {{SaslServer}}=
 which wraps a {{SaslNegotiator}} instance provided by the configured {{IAu=
thenticator}}. Note that I haven't actually *tried* to do this, but reading=
 [the JMXMP docs|http://docs.oracle.com/cd/E19698-01/816-7609/6mdjrf873/], =
particularly section *11.4.2 SASL Provider*, it seems feasible.

On the authz side, I also have a couple of remarks/suggestions.

I'm not a big fan of adding {{IAuthorizer::authorizeJMX}}. One reason is th=
at it's going to require all custom implementations to add a new method bef=
ore upgrading (even though implementors could make that a no-op and require=
 that users don't enable JMX authz). More generally though, it feels bad to=
 special case JMX resources in this this way, and I wouldn't want to set a =
precedent of adding a special authentication method for a particular resour=
ce type, I'd rather think some more about how the resources are modelled an=
d whether that can be changed to fit what's already there bit better. I thi=
nk the fundamental issue with {{JMXResource}} is that JMX {{ObjectName}}s a=
re not really hierarchical, but pattern based. For example, with {{DataReso=
urce}}s, we're able to grant permissions on a particular keyspace and have =
those apply automatically to all tables in the keyspace. I don't think that=
 kind of hierarchy can be modelled using {{ObjectName}}. On the surface, it=
 seems like something it should be possible by granting perms on {{org.apac=
he.cassandra.db:type=3DColumnFamilies,keyspace=3D<keyspace>,columnfamily=3D=
*}}, but the equally valid mbean name {{org.apache.cassandra.db:type=3DColu=
mnFamilies,keyspace=3D*,columnfamily=3D<table>}} clearly sits outside the h=
ierarchy, and necessitates the special handling of wildcards & patterns whi=
ch in turn requires {{IAuthorizer::authorizeJMX}}.

I propose a simplification to {{JMXResource}} to allow only fully qualified=
 bean names, with no support for wildcards or pattern matching. I would int=
roduce a level representing the domain into the hierarchy, so that permissi=
ons can be applied at that level, or for specific beans. So the hierarchy w=
ould be {{ROOT/DOMAIN/MBEAN}} where {{MBEAN}} would represent a full set of=
 key/value pairs. The constructor of {{JMXResource}} should canonicalise th=
e key/value pairs in a way consistent with {{ObjectName::getCanonicalKeyPro=
pertyListString}} so that authorizers can do a simple lexical comparision. =
So the some example mappings between an MBean and the corresponding {{JMXRe=
source}} would look like:

||MBean ObjectName||JMXResource||
|org.apache.cassandra.db:type=3DColumnFamilies,keyspace=3Dks,columnfamily=
=3Dtable1|mbeans/org.apache.cassandra.db/type=3DColumnFamilies,keyspace=3Dt=
able1|
|org.apache.cassandra.metrics:name=3DTotalBlockedTasks,path=3Dtransport,sco=
pe=3DNative-Transport-Requests,type=3DThreadPools|mbeans/org.apache.cassand=
ra.metrics/name=3DTotalBlockedTasks,path=3Dtransport,scope=3DNative-Transpo=
rt-Requests,type=3DThreadPools
|java.lang:name=3DG1 Old Gen,type=3DMemoryPool|mbeans/java.lang/name=3DG1 O=
ld Gen,type=3DMemoryPool|

On a related note, it also feels wrong to special case permissions on JMX r=
esources. I'd much prefer it if we could re-use the existing permissions, w=
hich I think we probably can do. It seems as though the proposed new permis=
sions in the patch actually map pretty well to existing perms.=20

||Proposed MB permssion||Existing permission||
|MBGET|SELECT|
|MBSET|MODIFY|
|MBQUERYNAMES|DESCRIBE|
|MBINSTANCEOF|DESCRIBE|
|MBEXECUTE|EXECUTE|
|MBINVOKE|EXECUTE|

I wouldn't bother with the meta-permissions {{MBREAD}} and {{MBWRITE}} as t=
heir existing equivalents are already deprecated.=20

If the consensus is that the semantics of the MBean operations really don't=
 match the existing permission then it would be better to figure out what i=
t is generically that's missing and add new permissions to express that, on=
e which should be re-usable for future, non-JMX resource types.=20


> Align JMX authentication with internal authentication
> -----------------------------------------------------
>
>                 Key: CASSANDRA-10091
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1009=
1
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jan Karlsson
>            Assignee: Jan Karlsson
>            Priority: Minor
>             Fix For: 3.x
>
>
> It would be useful to authenticate with JMX through Cassandra's internal =
authentication. This would reduce the overhead of keeping passwords in file=
s on the machine and would consolidate passwords to one location. It would =
also allow the possibility to handle JMX permissions in Cassandra.
> It could be done by creating our own JMX server and setting custom classe=
s for the authenticator and authorizer. We could then add some parameters w=
here the user could specify what authenticator and authorizer to use in cas=
e they want to make their own.
> This could also be done by creating a premain method which creates a jmx =
server. This would give us the feature without changing the Cassandra code =
itself. However I believe this would be a good feature to have in Cassandra=
.
> I am currently working on a solution which creates a JMX server and uses =
a custom authenticator and authorizer. It is currently build as a premain, =
however it would be great if we could put this in Cassandra instead.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)