[
https://issues.apache.org/jira/browse/CASSANDRA-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15262594#comment-15262594
]
Sam Tunnicliffe commented on CASSANDRA-10091:
---------------------------------------------
Well, I'm not suggesting JMX access is disallowed, just using the new
integrated auth feature. As I said, unauthenticated local only mode & the
standard file based auth will continue to work as usual. So really, the caveat
for this feature is not to turn it on on a node until after you've bootstrapped.
bq. Could we apply a restricted policy while the node has not joined and allow
unauthenticated access during that phase?
Possible, but messy. For instance, how do we define the restricted policy? One
of the use cases for this is to permit access to table/keyspace level resources
to only their "owners", which I don't see how we'd model here. Also, which are
the "necessary methods" for {{EXECUTE}}? Just the ones required to run
jconsole, or some specific nodetool commands, or all nodetool commands? I also
worry that this would be either brittle (in the face of new nodetool or JMX
methods) or insecure (as in we could accidentally expose something with
potential for harm) or both.
bq. Maybe also restricted to connections from localhost
Refusing remote connections based on the client address is certainly possible
by wrapping the server socket, but going further than that is more difficult.
Setting a threadlocal is tricky because the {{accept}} is performed by a
selector thread, which then hands off to a processing thread to do the actual
RPC. So we could reject outright any non-local connection while waiting for
auth setup to complete, but we'd need to pair that with having the
authentication proxy work in AllowAll mode during that phase *and* figure out
the permissive policy mentioned above. All of which is essentially the same as
running in local only mode.
The sum benefit of that is to avoid a config change and restart after joining,
and only for users of the new feature. As this is completely new functionality
and existing behaviour is completely preserved, I'd prefer to commit this as it
is & see if it's a genuine problem before implementing anything further.
> Integrated JMX authn & authz
> ----------------------------
>
> Key: CASSANDRA-10091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10091
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jan Karlsson
> Assignee: Sam Tunnicliffe
> 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)
