You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benjamin Lerer (Jira)" <ji...@apache.org> on 2021/03/29 11:49:00 UTC

[jira] [Comment Edited] (CASSANDRA-16404) Provide a nodetool way of invalidating auth caches

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

Benjamin Lerer edited comment on CASSANDRA-16404 at 3/29/21, 11:48 AM:
-----------------------------------------------------------------------

{quote}1. Despite the use case sounds reasonable to me, does the product ever need this functionality?{quote}

It is a tricky question. In an ideal world it should not. Any auth change request should automatically clear the corresponding caches. Now, in a real world even if we had that functionality, problems do happen and this functionality can be useful.  

{quote} 2.  There are multiple caches (roles, permissions, network auth, credentials, JMX permissions), but I feel it is enough to invalidate permissions cache only to handle the use case. Could you please confirm?{quote}

I would have to look as I forgot some of the logic but it would make sense to me to provide the functionality for all of them.

{quote} 3. As far as I can see, the invalidation of permissions cache only does not affect (need for re-login or similar side effects) logged in users. So it is safe to invalidate the cache and does not bother all users of the system. Could you please confirm?{quote}

Not sure I understand your question.

{quote} 4 Even though permissions cache invalidation does not affect other users, we need to provide an optional user parameter, so the administrator can invalidate the cache for that particular user rather than for all users. Thoughts?{quote}

We should always minimize which part of the cache we clean as repopulating the cache under high load can have a significant impact on a cluster. 

{quote} 5. As far as I understand nodetool is executed on a single node, so the auth cache invalidation needs to be triggered on all nodes manually. It seems be slightly inconvenient for the administrator... {quote}

Administrators have tools in place to deal with that problem. Nodetool is single node only.
 


was (Author: blerer):
b.q. 1. Despite the use case sounds reasonable to me, does the product ever need this functionality?

It is a tricky question. In an ideal world it should not. Any auth change request should automatically clear the corresponding caches. Now, in a real world even if we had that functionality, problems do happen and this functionality can be useful.  

b.q. 2.  There are multiple caches (roles, permissions, network auth, credentials, JMX permissions), but I feel it is enough to invalidate permissions cache only to handle the use case. Could you please confirm?

I would have to look as I forgot some of the logic but it would make sense to me to provide the functionality for all of them.

b.q. 3. As far as I can see, the invalidation of permissions cache only does not affect (need for re-login or similar side effects) logged in users. So it is safe to invalidate the cache and does not bother all users of the system. Could you please confirm?

Not sure I understand your question.

b.q. 4 Even though permissions cache invalidation does not affect other users, we need to provide an optional user parameter, so the administrator can invalidate the cache for that particular user rather than for all users. Thoughts?

We should always minimize which part of the cache we clean as repopulating the cache under high load can have a significant impact on a cluster. 

b.q. As far as I understand nodetool is executed on a single node, so the auth cache invalidation needs to be triggered on all nodes manually. It seems be slightly inconvenient for the administrator... 

Administrators have tools in place to deal with that problem. Nodetool is single node only.
 

> Provide a nodetool way of invalidating auth caches
> --------------------------------------------------
>
>                 Key: CASSANDRA-16404
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16404
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sumanth Pasupuleti
>            Assignee: Sumanth Pasupuleti
>            Priority: Normal
>             Fix For: 4.x
>
>
> We currently have nodetool commands to invalidate certain caches like KeyCache, RowCache and CounterCache. 
> Being able to invalidate auth caches as well can come in handy in situations where, critical backend auth changes may need to be in effect right away for all the connections, especially in configurations where cache validity is chosen to be for a longer duration. An example can be that an authenticated user "User1" is no longer authorized to access a table resource "table1" and it is vital that this change is reflected right away, without having to wait for cache expiry/refresh to trigger.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org