[
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:41 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:
||Cache||Java Code||CQL Schema||
|Permissions|Key: Pair<AuthenticatedUser, IResource>
Value: Set<Permission>|
||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>.|
|
|Network Permissions|Key: RoleResource
Value: DCPermissions|
||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|
|
|JMX Permissions|Key: RoleResource
Value: Set<PermissionDetails>|
||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| |
|
|Roles|Key: RoleResource
Value: Set<Role>|
||Columns||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.|
|
|Credentials|Key: String
Value: String|
||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: [email protected]
For additional commands, e-mail: [email protected]
