[
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/14/15 8:37 AM:
--------------------------------------------------------------------
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 mbeans under the hood while starting Jconsole can only be done by
adding 10~ different mbeans.
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 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.
> 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)
