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] [Comment Edited] (CASSANDRA-10091) Align JMX authentication with internal authentication
Date Tue, 13 Oct 2015 14:36:05 GMT

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

Jan Karlsson edited comment on CASSANDRA-10091 at 10/13/15 2:35 PM:
--------------------------------------------------------------------

Great points. Thank you for taking the time to review this.

First of all, I agree completely on the use of {{IAuthenticator::legacyAuthenticate}}. Originally
this patch was against 2.1 and I only recently forward ported it. I just wanted to get it
out so we can commence with the discussion. I agree that we will have to make use of the {{IAuthenticator::newSaslAuthenticator}}
and we should Investigate further.

Also great points on {{IAuthorizer::authorizeJMX}}. While I see the merit in your points on
the subject. I cannot stress the importance of wildcards. It seemed like an unpleasant experience
to go through countless permissions and apply them one at a time. I know this is somehow lessened
by the fact that you will only do this once per role, which can then be assigned to different
users. However calling a simple command like {{nodetool status}} will require 4~ different
permissions under the hood while starting Jconsole can only be done by adding 10~ different
permissions.

Simplifying the {{JMXResource}} might be the way to go but we should consider how much freedom
we will lose from doing this. I was actually debating this very thing when I implemented it.
Should I have only meta permission, should I expose all permissions or both? I settled on
doing both to cater to every use case.

The problem is that the mapping between nodetool commands and permissions is somewhat confusing.
For instance 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. This is why these meta-permissions were born.

It is simpler to give {{MBREAD}} to a user, then to give {{MBGET|MBINSTANCEOF|MBQUERYNAMES}}.
With this solution, both variants are possible. Furthermore giving only MBGET or MBINSTANCEOF
is also an option, if you happen to have such a use case. One could argue that this might
be an uncommon use case, but I have a hard time ruling it out.

 However if the consensus is that we should simplify it, which does have it's advantages,
then I agree with your proposal.


was (Author: jan karlsson):
Great points. Thank you for taking the time to review this.

First of all, I agree completely on the use of {{IAuthenticator::legacyAuthenticate}}. Originally
this patch was against 2.1 and I only recently forward ported it. I just wanted to get it
out so we can commence with the discussion. I agree that we will have to make use of the {{IAuthenticator::newSaslAuthenticator}}
and we should Investigate further.

Also great points on {{IAuthorizer::authorizeJMX}}. While I see the merit in your points on
the subject. I cannot stress the importance of wildcards. It seemed like an unpleasant experience
to go through countless permissions and apply them one at a time. I know this is somehow lessened
by the fact that you will only do this once per role, which can then be assigned to different
users. However calling a simple command like {{nodetool status}} will require 4~ different
JMXResources under the hood. 

Simplifying the {{JMXResource}} might be the way to go but we should consider how much freedom
we will lose from doing this. I was actually debating this very thing when I implemented it.
Should I have only meta permission, should I expose all permissions or both? I settled on
doing both to cater to every use case.

The problem is that the mapping between nodetool commands and permissions is somewhat confusing.
For instance 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. This is why these meta-permissions were born.

It is simpler to give {{MBREAD}} to a user, then to give {{MBGET|MBINSTANCEOF|MBQUERYNAMES}}.
With this solution, both variants are possible. Furthermore giving only MBGET or MBINSTANCEOF
is also an option, if you happen to have such a use case. One could argue that this might
be an uncommon use case, but I have a hard time ruling it out.

 However if the consensus is that we should simplify it, which does have it's advantages,
then I agree with your proposal.

> 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