cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Karlsson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10091) Align JMX authentication with internal authentication
Date Thu, 22 Oct 2015 07:35:27 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14968712#comment-14968712
] 

Jan Karlsson commented on CASSANDRA-10091:
------------------------------------------

{quote}
For instance, do we actually need to enact fine grained control over nodetool at the keyspace
or table level, such that a user with permissions on keyspace ks_a would be able to run nodetool
status ks_a, but not to run nodetool status ks_b? I think that's overkill and not really needed
by most admins. 
{quote}
The current patch does not restrict access from nodetool in terms of which keyspace/table
the command is run on. This is due to nodetool calling methods in the {{StorageProxy}}. However
if someone were to call these methods from a specific columnfamily, it would prevent that.
I believe preventing users from initiating operations like major compaction on a some tables
but not on others is a fairly common use case. Especially when we provide so many potentially,
in some cases detrimental operations like {{compact}}. Unfortunately this patch does not give
this distinction on nodetool level, because you either have the permission for StorageProxy
or you do not. However it does give you the choice to make that distinction on non-nodetool
users.

{quote}
So for example, this would enable us to grant read access to all the ColumnFamily mbeans with
GRANT SELECT ON ALL MBEANS IN 'org.apache.cassandra.db:type=ColumnFamily', e.g. for running
nodetool cfstats. What it doesn't permit is restricting access to a particular subset of ColumnFamily
beans.
{quote}
Another disadvantage is that if the client application (for example I observed jconsole doing
this) sends a jmx request with a wildcard mbean. For instance it might send something like
{{java.lang:*}} or a wildcard would be send in when a program is trying to receive the names
of all mbeans. Now the latter instance might not be so difficult to handle with your proposal,
since {{queryNames}} and {{isInstanceOf}} are granted to everyone, but there might be other
cases where wildcard mbean are being passed in. We would have to handle this somehow. Otherwise
applications who pass wildcard mbean will have to have root permission.

{quote}
Also, I noticed one other thing regarding the MBeanServerForwarder implementation. We should
create a new ClientState and log the AuthenticatedUser derived from the subject into it, which
would have a couple of benefits. Firstly, the check that the user has the LOGIN privilege
would be performed which isn't the case in the current patch. Second, the permissions check
could include the full resource hierarchy using ensureHasPermission, rather than directly
by calling the IAuthorizer::authorize.
{quote}
+1

Another aspect we need to remember is that currently there is no way to ascertain which mbeans
are needed for a particular nodetool commands or for the different tools that exist (like
jconsole). We probably need to document this somewhere.

> 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
>             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 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)

Mime
View raw message