[
https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17422695#comment-17422695
]
Sam Tunnicliffe commented on CASSANDRA-16914:
---------------------------------------------
Hey [~azotcsit], sorry it took a while to respond, I agree it would be ideal to
deliver the nodetool & VT stuff in the same release.
Basically, I disagree with the intention of these VTs. One of the motivations
behind VTs (maybe the primary one) was to provide an alternative to JMX for
accessing configuration and metrics data. My perspective is that conceptually
these specific tables should exist in order to provide operators with the
ability to configure and control the auth caches without requiring JMX and, by
extension, nodetool. There is some prior art in the system_views.caches table,
which provides read-only metrics info for the counter, row and key caches. It
would be good to expose similar metrics info for the auth caches, but I see
that as a) not super critical as the datasets are so much smaller for auth
data, the hit/miss/occupancy rates are less significant b) outside the scope of
the original issue, which was to provide an operator-friendly way to invalidate
cached data. Perhaps we can file a follow up ticket to expose this data and
other cache config which can be mutated currently via JMX in a separate set of
VTs.
Putting conceptual concerns aside, I don't see there's any real value in being
able to retrieve the precise values that are currently cached from these VTs.
Firstly, there are existing means to obtain that data if required (i.e. using
the LIST X statements and/or querying the underlying tables directly). Second,
knowing that a particular auth datum it is cached _at this time_ doesn't really
benefit an operator. Consider the flow when an invalidation-triggering event
occurs; for instance, if a user has a privilege revoked, checking the VT to see
if it is cached or not is unnecessary work when an operator can simply issue
the idempotent invalidation query. In CASSANDRA-16404, we didn't implement a
set of query commands to look up precisely which values were cached (why would
we?), only the tools to invalidate them, should that be possible. So just
because it's possible to expose the full set of cached data (or even a subset
of it), it doesn't mean we should.
As well as being a somewhat pointless duplication, exposing the entire contents
of the auth tables in this way broadens the surface area of potential security
issues, as you mentioned. That said, permissions do apply to tables in
system_views, so the exposure is perhaps not as broad as you feared, however I
know there are already concerns about allowing read access to system_auth
tables.
My proposal would be to stick to modelling the invalidation commands as
provided by CASSANDRA-16404. Meaning, I would model the tables such that the
primary keys match the cache keys in the auth caches and not include anything
else:
{code}
cassandra@cqlsh> DESCRIBE TABLE system_views.permissions_cache_entries;
/*
Warning: Table system_views.permissions_cache_entries is a virtual table and
cannot be recreated with CQL.
Structure, for reference:
VIRTUAL TABLE system_views.permissions_cache_entries (
role text,
resource text,
PRIMARY KEY (role, resource)
) WITH comment = 'entries in the permissions cache';
*/
cassandra@cqlsh> SELECT * FROM system_views.permissions_cache_entries;
role | resource |
---------+--------------------------+
user_a | data/test_ks/test_table1 |
user_b | data/test_ks/test_table2 |
user_b | data/test_ks/test_table3 |
user_c | data/test_ks/test_table4 |
# invalidate permissions for a single user on a single resource
cassandra@cqlsh> DELETE FROM system_views.permissions_cache_entries WHERE
role='user_a' AND resource='data/test_ks/test_table1';
# invalidate all permissions for a single user
cassandra@cqlsh> DELETE FROM system_views.permissions_cache_entries WHERE
role='user_b' ;
# invalidate the entire cache
cassandra@cqlsh> TRUNCATE system_views.permissions_cache_entries;
{code}
As I said, I think we could follow up this work with additional tables to expose
* metrics (analogous to system_views.caches)
* configuration options currently only exposed via JMX or yaml
(capacity/validity/updateinterval)
> Implement Virtual Tables for Auth Caches
> ----------------------------------------
>
> Key: CASSANDRA-16914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16914
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization, Feature/Virtual Tables
> Reporter: Aleksei Zotov
> Assignee: Aleksei Zotov
> Priority: Low
> Fix For: 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{NodeTool}} commands for Auth Caches invalidation were implemented as a part
> of CASSANDRA-16404 ticket. While discussing that ticket it was agreed that
> there is a need to develop the same kind of functionality through Vitrual
> Tables. Unfortunately, VT did not have {{TRUNCATE}} and {{DELETE}} support.
> And CASSANDRA-16806 was created for that reason. Once it is completed,
> further work can be started.
> The goal of this ticket is to create VTs for the following caches:
> * {{CredentialsCache}}
> * {{JmxPermissionsCache}}
> * {{NetworkPermissionsCache}}
> * {{PermissionsCache}}
> * {{RolesCache}}
> The VTs should support reading from and modification of the in the Auth
> Caches.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
