[
https://issues.apache.org/jira/browse/CASSANDRA-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14954795#comment-14954795
]
Sam Tunnicliffe commented on CASSANDRA-10091:
---------------------------------------------
Thanks for the patch, I think this will make a great feature provided we can
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
{{IAuthenticator::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 method for authentication is through SASL, which allows a wider
variety of backends to be plugged in. I know that in the wild there are custom
implementations which use this mechanism to do stuff like Kerberos
authentication and clusters using those authenticators wouldn't be able to make
use of this functionality (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 code and make use of {{IAuthenticator::newSaslAuthenticator}}.
I'd like to investigate further, but it looks like this could be possible using
[JMXMP|https://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/]. We could
switch the connection to JMXMP if configured with advanced JMX auth and I think
it should be possible to then define a custom {{SaslServer}} which wraps a
{{SaslNegotiator}} instance provided by the configured {{IAuthenticator}}. 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 that
it's going to require all custom implementations to add a new method before
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 resource type, I'd
rather think some more about how the resources are modelled and whether that
can be changed to fit what's already there bit better. I think the fundamental
issue with {{JMXResource}} is that JMX {{ObjectName}}s are not really
hierarchical, but pattern based. For example, with {{DataResource}}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.apache.cassandra.db:type=ColumnFamilies,keyspace=<keyspace>,columnfamily=*}},
but the equally valid mbean name
{{org.apache.cassandra.db:type=ColumnFamilies,keyspace=*,columnfamily=<table>}}
clearly sits outside the hierarchy, 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
introduce a level representing the domain into the hierarchy, so that
permissions can be applied at that level, or for specific beans. So the
hierarchy would be {{ROOT/DOMAIN/MBEAN}} where {{MBEAN}} would represent a full
set of key/value pairs. The constructor of {{JMXResource}} should canonicalise
the key/value pairs in a way consistent with
{{ObjectName::getCanonicalKeyPropertyListString}} so that authorizers can do a
simple lexical comparision. So the some example mappings between an MBean and
the corresponding {{JMXResource}} would look like:
||MBean ObjectName||JMXResource||
|org.apache.cassandra.db:type=ColumnFamilies,keyspace=ks,columnfamily=table1|mbeans/org.apache.cassandra.db/type=ColumnFamilies,keyspace=table1|
|org.apache.cassandra.metrics:name=TotalBlockedTasks,path=transport,scope=Native-Transport-Requests,type=ThreadPools|mbeans/org.apache.cassandra.metrics/name=TotalBlockedTasks,path=transport,scope=Native-Transport-Requests,type=ThreadPools
|java.lang:name=G1 Old Gen,type=MemoryPool|mbeans/java.lang/name=G1 Old
Gen,type=MemoryPool|
On a related note, it also feels wrong to special case permissions on JMX
resources. I'd much prefer it if we could re-use the existing permissions,
which I think we probably can do. It seems as though the proposed new
permissions in the patch actually map pretty well to existing perms.
||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 their
existing equivalents are already deprecated.
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 it is
generically that's missing and add new permissions to express that, one which
should be re-usable for future, non-JMX resource types.
> Align JMX authentication with internal authentication
> -----------------------------------------------------
>
> Key: CASSANDRA-10091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10091
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jan Karlsson
> Assignee: Jan Karlsson
> Priority: Minor
>
> It would be useful to authenticate with JMX through Cassandra's internal
> authentication. This would reduce the overhead of keeping passwords in files
> 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 classes
> for the authenticator and authorizer. We could then add some parameters where
> the user could specify what authenticator and authorizer to use in case 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)
