[ https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17414595#comment-17414595 ]
Aleksei Zotov edited comment on CASSANDRA-16914 at 9/13/21, 9:42 PM: --------------------------------------------------------------------- [~blerer] [~samt] I'd like to finalize the VTs structure we'd like to have. Could you please share your thoughts on the structure below. A small remark: internally (in Java code) the caches use collections, I tried to translate collections to clustering columns while designing VTs schemas. Here is what I came up to so far: h3. Permissions Cache JAVA: Key: Pair<AuthenticatedUser, IResource> Value: Set<Permission> VT: ||Column||Type||Sample||Comment|| |role|Partition|alice| | |resource|Partition|data/ks1| | |permission|Clustering|DROP|It allows to check what is currently cached and to drop a particular permission if needed. Alternatively, an operator can drop all permission for a specific <role, resource>.| h3. Network Permissions Cache JAVA: Key: RoleResource Value: DCPermissions VT: ||Column||Type||Sample||Comment|| |role|Partition|alice| | |allowed_dcs|Regular|ALL|Theoretically this column can be removed since it has just informational purpose. However, I feel it would be useful for operators to understand what is particularly cached before dropping it. Possible values (DCPermissions#toString): - ALL - dc1, dc2 - n/a| h3. JMX Permissions Cache JAVA: Key: RoleResource Value: Set<PermissionDetails> VT: ||Column||Type||Sample||Comment|| |role|Partition|alice|Theoretically this column is enough for dropping all permissions. Other columns have informational purpose and allow to drop necessary permissions granularly: - <role> - <role, grantee> - <role, grantee, resource> - <role, grantee, resource, permission>| |grantee|Clustering|bob| | |resource|Clustering|mbean| | |permission|Clustering|EXECUTE| | h3. Roles Cache JAVA: Key: RoleResource Value: Set<Role> VT: ||Column||Type||Sample||Comment|| |role|Partition|alice| | |resource|Clustering|roles/bob|Role class contains many fields. Here I do not think they make sense to add them to this table (it is possible) because it is to know dependency between roles, but not role details.| h3. Credentials JAVA: Key: String Value: String VT: ||Column||Type||Sample||Comment|| |role|Partition|alice| | |salted_hash|Regular|$2a$10$bBizhBPMwF.XAUrsAPnGaOe8k9r5yszRn0838IzTDf/zAP9Dkfuti|Theoretically this column can be removed since it has just informational purpose. In fact, it has less value that allowed_dcs for network permissions. However, I still feel it makes the VT more logical. | was (Author: azotcsit): [~blerer] [~samt] I'd like to finalize the VTs structure we'd like to have. Could you please share your thoughts on the structure below. A small remark: internally (in Java code) the caches use collections, I tried to translate collections to clustering columns while designing VTs schemas. Here is what I came up to so far: h3. Permissions Cache JAVA: Key: Pair<AuthenticatedUser, IResource> Value: Set<Permission> VT: ||Column||Type||Sample||Comment|| |role|Partition|alice| | |resource|Partition|data/ks1| | |permission|Clustering|DROP|It allows to check what is currently cached and to drop a particular permission if needed. Alternatively, an operator can drop all permission for a specific <role, resource>.| h3. Network Permissions Cache JAVA: Key: RoleResource Value: DCPermissions VT: ||Column||Type||Sample||Comment|| |role|Partition|alice| | |allowed_dcs|Regular|ALL|Theoretically this column can be removed since it has just informational purpose. However, I feel it would be useful for operators to understand what is particularly cached before dropping it. Possible values (DCPermissions#toString): - ALL - dc1, dc2 - n/a| h3. JMX Permissions Cache JAVA: Key: RoleResource Value: Set<PermissionDetails> VT: ||Column||Type||Sample||Comment|| |role|Partition|alice|Theoretically this column is enough for dropping all permissions. Other columns have informational purpose and allow to drop necessary permissions granularly: - <role> - <role, grantee> - <role, grantee, resource> - <role, grantee, resource, permission>| |grantee|Clustering|bob| | |resource|Clustering|mbean| | |permission|Clustering|EXECUTE| | h3. Roles Cache JAVA: Key: RoleResource Value: Set<Role> VT: ||Column||Type||Sample||Comment|| |role|Partition|alice| | |resource|Clustering|roles/bob|Role class contains many fields. Here I do not think they make sense to add them to this table (it is possible) because it is to know dependency between roles, but not role details.| h3. Credentials JAVA: Key: String Value: String VT: ||Column||Type||Sample||Comment|| |role|Partition|alice| | |salted_hash|Regular|$2a$10$bBizhBPMwF.XAUrsAPnGaOe8k9r5yszRn0838IzTDf/zAP9Dkfuti|Theoretically this column can be removed since it has just informational purpose. In fact, it has less value that allowed_dcs for network permissions. However, I still feel it makes the VT more logical. | > 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 > > > {{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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org