cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10091) Align JMX authentication with internal authentication
Date Mon, 19 Oct 2015 17:16:05 GMT


Sam Tunnicliffe commented on CASSANDRA-10091:

I've opened CASSANDRA-10551 to look into JMXMP/SASL, so we can focus on the authz side of
things here.

I definitely take your point about the importance of wildcards, but I do question how much
we actually need that level of flexibility and whether it's ultimately worth pursuing.
Let's clarify/simplify the use case a little (and please correct me if I make an incorrect
assumptions). I suspect that in the majority of situations, what we need here in terms of
granularity is a lot simpler than for other types of resources. 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. 

I think a simple hierarchy of {{ROOT/DOMAIN/TYPE}} should be sufficient for what we do need.
The caveat is that {{type}} is not a mandatory key in an {{ObjectName}}, but it *is* a documented
best practice (one followed by all of the beans exposed by C*):

bq.Every Object Name should contain a type= key property. This property should be different
for every object type in a given domain ([ref|])

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. As I mentioned though, I'm not entirely convinced that we actually
need that as I think the relevant distinction is between users who are allowed to access JMX
and those who aren't. I think a multi-tenant system where users are only allowed to interact
with beans relating to their own data resources is something that probably belongs outside
Cassandra, in a management application layer. Also, we *could theoretically* decide to extend
the hierarchy at a later date by adding another level at the bottom representing additional
property pairs (I'm not sure exactly how we would implement those, but it would at least be

As far as permissions go, I'm still not keen on adding a whole new set of permissions which
only apply to one specific type of resource. I still think the mapping I mentioned in my previous
comment could work ok. You said that

bq. in your remapping proposal. One would have to give SELECT, DESCRIBE and EXECUTE to be
able to get all information out of nodetool info. Not something one would expect from such
a command.

I may be missing something, but I don't think that your proposed mappings improve things much
there. I would suggest that the counter-intuitive part in this particular case is having to
grant {{EXECUTE}} in order to simply retrieve the info. But this is due to the fact that rack
and dc info aren't exposed as attributes, but returned from invoked methods. So even with
your custom permissions, you'd have to grant {{MBEXECUTE}} or {{MBINVOKE}} to run {{nodetool
info}}. I don't really see a way around this as it's always going to be likely that we have
some cases like this, where {{invoke}} is required, and we have no good way to distinguish
between those methods with and without side effects. On the related points, I suspect that
pretty much every non trivial usage of jmx is going to require {{DESCRIBE}} for {{queryNames}}
and {{isInstanceOf}}, so I would think a fairly common pattern would be to create a basic
jmx user role and grant {{DESCRIBE ON ALL MBEANS}} to it. That role would then be granted
to others with more specific sets of permissions on particular beans or domains. Running jconsole
or jmc is always going to require elevated privileges, so I would assume that administrators
would create some jmx admin role for that purpose and {{GRANT ALL PERMISSIONS ON ALL MBEANS}}}
to it. 

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}}.

> Align JMX authentication with internal authentication
> -----------------------------------------------------
>                 Key: CASSANDRA-10091
>                 URL:
>             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
> 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

View raw message