[
https://issues.apache.org/jira/browse/CASSANDRA-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15262014#comment-15262014
]
Sam Tunnicliffe commented on CASSANDRA-10091:
---------------------------------------------
The inability to authenticate before joining is going to be problematic
particularly when bootstrapping new nodes as nodetool, as well as any other
monitoring tools which depend on it or on JMX directly, will not be functional.
Not being able to monitor node status or streaming progress during bootstrap,
or resume a failed bootstrap via nodetool is clearly a big problem. Also, the
issue described in CASSANDRA-11381 will also apply here; as auth setup occurs
only when the node joins the ring, authentication is not possible on nodes
started with {{join_ring=false}}. The additional consequence in this case is
that operators have no means to have the node join later, with JMX being
inaccessible (short of a restart).
Both of these are nasty edge cases, so I've spent some time trying to figure
out a reasonable way to deal with them. Unfortunately, at the moment I have
nothing as neither of the options I came up with are very appealing:
* Fall back to file based auth prior to joining the ring, then switch to the
integrated auth once joined. This would require operators to configure both the
new and old settings which is confusing and could easily result in
misconfigurations and vulnerabilities. Also, the behaviour of using one set of
credentials for a time, then suddenly switching to another certainly violates
the principal of least surprise.
* Start off in local-only, unauthenticated mode (as if {{LOCAL_JMX=yes}}, which
is the default we ship), then activate the configured auth once joined and
again this seems like unexpected behaviour. More concretely though, once the
RMI registry has been bound, there's no way (that I can see) to replace it with
a new one, which we would need to do here as the registry is bound to the
listening sockets, which is how local mode is enforced.
I think the best we can do right now is to document this and make it clear that
using the new integrated auth is not suitable for bootstrapping nodes (unless
you can live without JMX while bootstrapping) or for non-joining nodes. The
file based auth mechanisms can still be used in these scenarios, as can
unauthenticated local-only mode. The major downside is that switching to
integrated mode after bootstrap or joining will require a restart.
I've rebased & pushed a commit which cleans up the error handling when JMX auth
is attempted before auth setup is complete, any thoughts?
> 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)
