Small question about Cassandra 3.0.8. Not datastax.
is it possible to grant/revoke permissions for users, who use sstableloader? For now, user only authenticate in Cassandra and can update any table...
There is no specific authentication for just sstableloader. However you can
Create separate set of users/roles for each and every table within the keyspace.
In other words, there could be different users with different set of permissions on each and every table.
Here is an example on how to create user and define permission at table level
GRANT SELECT PERMISSIONS ON keyspace1.table1 TO USER1;
GRANT MODIFY PERMISSIONS ON keyspace1.table2 TO USER1;
So in the above example USER1 has select permission on table1 while update permission on table2. So you can authorize who gets to have update access on table1 but not if it comes from sstableloader or cql or application code.
Here is the reference for roles and permissions https://docs.datastax.com/en/cql/3.1/cql/cql_reference/grant_r.html
Related
What I am trying to achieve is similar to what DSE Cassandra provide here, but on Apache Cassandra: Setting up Row Level Access Control (RLAC)
I've tried using Materialized View and grant SELECT permission on the created view to a specific role, but when I'm trying to access the view it returns an unauthorized error asking me to grant SELECT permission on the origin table.
Is there really no way to achieve this?
I'm trying to find any documentation which would state the permission needed to create a new keyspace. I would assume ONLY a role with superuser = true is allowed to create new Keyspaces?
We would like to limit access so one user can not see other keyspaces but still be able to create new keyspaces.
What's the best approach here?
Superuser = true but limit only to keyspaces created by itself or granted
non-super user with keyspace creation privileges.
Not sure if any of these 2 points above is possible.
Thanks for any input.
So the first scenario isn't possible. A super user is a user that cannot be limited.
The second one though, sort of is:
GRANT CREATE
ON ALL KEYSPACES
TO keyspace_creator;
Granting CREATE permissions on ALL KEYSPACES is the only way to grant keyspace creation. Just remember that it also grants table creation (within ALL keyspaces), as well as SELECT and MODIFY on tables they have created.
They can still "see" and describe other keyspaces and tables. But that user cannot access (SELECT) any tables that they have not been explicitly granted access to or did not create themselves.
While exploring cassandra, Is it possible in cassandra that if I created an user "test" and I have multiple keypsaces so if I am logging cqlsh with "test" then I can see only selected keyspaces not others.admin can view or switch all keypsaces. please help if any idea or correct me.
Thanks in advance.
Permissions (Data Control)
https://docs.scylladb.com/operating-scylla/security/authorization/#data-control
Permission Resource Operations
AUTHORIZE ALL KEYSPACES GRANT PERMISSION and REVOKE PERMISSION on any table
AUTHORIZE KEYSPACE GRANT PERMISSION and REVOKE PERMISSION on any table in specified keyspace
AUTHORIZE TABLE GRANT PERMISSION and REVOKE PERMISSION on specified table
GRANT permissions
https://docs.scylladb.com/operating-scylla/security/authorization/#grant-permission
AND / OR
RBAC (Role Based Access Control)
https://docs.scylladb.com/operating-scylla/security/authorization/#database-roles
Will be a good way of accomplishing what you are aiming for
GRANT command should work.
Though test user will be able to see other keyspaces, operation will not be possible unless given permission.
If test user has SELECT grant on particular keyspace it will be able to only issue select query on tables in that keyspace.
https://docs.datastax.com/en/cql/3.3/cql/cql_reference/cqlGrant.html
I have below questions about schema/privilege:
May User have multiple DB roles(schema)?
What is db_denydatareader used for? (it seems can have different DB roles among databases, right?)
What are difference between db_datareader and db_denydatawriter if only want user to read data in particular database?
I tried to revoke SELECT right from schema (TestUser is with default schema db_datareader), why can it still search for tables?
REVOKE SELECT ON SCHEMA::db_datareader TO TestUser;
How can I grant select and update permissions to few tables only to user but not all tables? (i.e. no delete and insert permissions)
What are these system privileges referring to as I could not find in sys.objects table?
select * from sys.database_permissions where major_id <= 0;
Thanks.
It seems you think schemas and roles are the same but they are not the same. Roles are security membership containers, a principal can be member of a role. Schemas contain database schema bound objects, they help to group database objects together, and are owned by a principal. When you create a new user you can choose his default schema, add him to certain roles, and grant him ownership of schemas.
Members of the db_denydatareader fixed database role cannot read any data in the user tables within a database.
About the difference between db_datareader and db_denydatawriter. The db_datareader grants select permissions on all tables, and It does not affect any insert, update, delete permissions. Meanwhile db_denydatawriter denies insert, update and delete permissions on all tables, it denies permission to do any changes to any table. Even if someone was granted insert permissions directly they would still not be able to insert, because deny overrules grant. Assigning a user to the db_denydatawriter role means that they will never be able to make any changes to the database, regardless of what other permissions they have. Deny takes precedence over grant.
About question #4, you can group tables on schemas and then DENY SELECT permission over the schema to a principal or user. db_datareader is a fixed database role and it is not a schema.
DENY SELECT ON schema::[SchemaName] TO [user_name]
Similarly you can grant SELECT and UPDATE permissions over an schema on the database, that contains a group of tables.
GRANT SELECT, UPDATE on SCHEMA::SchemaName TO [user_name]
You can find the list of database roles here.
My application (C#, ASP.Net) needs to insert, update and delete data in the DB, and run stored procedures. I need to prevent it from modifying the DB schema - no altering tables, creating or dropping, no changes to stored procedures.
What permissions combination do I need to grant to the application user? Just 'select' isn't going to work, because it needs to insert/update/delete data in tables.
How do I check permissions and access for a particular login?
How do I grant or deny permissions and access for a login?
I need to give permissions to a new user (login) to access only one database.
Using SQL Server 2008 R2, with SSMS.
If you really want to control this at the object level, you can do:
GRANT SELECT,UPDATE,INSERT,DELETE ON dbo.table TO user;
At the schema level:
GRANT SELECT,UPDATE,INSERT,DELETE ON SCHEMA::dbo TO user;
Ideally, though, you would not allow ad hoc DML against your tables, and control all DML through stored procedures. In which case you just need to grant exec on the procedure itself, and not to the objects it touches:
GRANT EXEC ON dbo.procedure TO user;
Similarly if you want to allow exec on all procedures in a specific schema, you can say:
GRANT EXEC ON SCHEMA::dbo TO user;
The one exception is when your stored procedure composes dynamic SQL. In those cases you might still need to apply permissions to the underlying tables in the context of the dynamic SQL execution, or you may be able to use EXECUTE AS OWNER.