[
https://issues.apache.org/jira/browse/CASSANDRA-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963630#comment-14963630
]
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|http://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html?ssSourceSiteId=ocomen#mozTocId654884])
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 possible).
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: 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)
