cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10091) Integrated JMX authn & authz
Date Thu, 28 Apr 2016 17:39:13 GMT

    [ 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)

Mime
View raw message