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