Apache Cassandra – Part 06 (User Management)

First of all I’d like to wish you all a happy new year! As the first post of 2017, I’m going to talk about the user management in Cassandra. Actually now it’s role based. Before the version 2.2 the Users existed. But after the version 2.2 Cassandra moved to role based access control. But Users are still exist in order to provide the backward compatibility. There are three main components to talk about here,

  • Permissions – Allow or not to do a particluar thing to a resource
  • Users – Have a set of permissions, password to login
  • Roles – Same as Users

Also we need to do some changes to the cassandra-installtion-location/conf/cassandra.yaml file to enable login and permission. Otherwise by default it is disabled and will grant any user to login. We can check that by executing a command which need permission such as, LIST ROLES, then it will give an error.

0

Also we want be able to view permissions as well,

9

To enable both we need to change authenticator and authorizer as below,

1

Then restart the ./cassandra and login using the default user, cassandra.

2

Now we should be able to LIST USERS.

3

4

PERMISSIONS

Permissions on resources are granted to roles; there are several different types of resources in Cassandra and each type is modeled hierarchically:

  • The hierarchy of Data resources, Keyspaces and Tables has the structure

ALL KEYSPACES -> KEYSPACE -> TABLE.

  • Function resources have the structure

ALL FUNCTIONS -> KEYSPACE -> FUNCTION

  • Resources representing roles have the structure

ALL ROLES -> ROLE

  • Resources representing JMX ObjectNames, which map to sets of MBeans/MXBeans, have the structure

ALL MBEANS -> MBEAN

Permissions can be granted at any level of these hierarchies and they flow downwards. So granting a permission on a resource higher up the chain automatically grants that same permission on all resources lower down. The full set of available permissions are,

  • CREATE
  • ALTER
  • DROP
  • SELECT
  • MODIFY
  • AUTHORIZE
  • DESCRIBE
  • EXECUTE

But we can’t use all these permissions with all the resources. Here is the compatibility of permissions with the resources.

121314

  • Grant permission

GRANT <permission> ON <resource> TO <role>

16

  • List permissions

LIST <permissions> ON <resource> OF <role>

17

  • Revoke permissions

REVOKE <permission> ON <resource> FROM <role>

18

19

ROLES

  • Create role

CREATE ROLE <role-name> WITH PASSWORD = ‘<password>’ AND LOGIN = <true/false>
AND SUPERUSER = <true/false>

6

8

  • List roles

LIST ROLES
7

  • Alter roles

ALTER ROLE <role-name> WITH <option> = <value>

10

  • Drop roles

DROP ROLE <role-name>

11

  • Grant a role to a role – This will give all the permissions of the user one to the user two.

GRANT <role-one-name> TO <role-two-name>

20

21

22

  • Revoke permissions from a role

REVOKE <role-one-name> FROM <role-two-name>

25

26

USERS

Same as Roles. We can view both users and roles by using LIST ROLES and LIST USERS. Both commands will list all the users and roles together. Because there is no difference in USERS and ROLES. As I mentioned earlier earlier versions had users and new versions after 2.2 use roles.

  • Create user

CREATE USER <name>

31

  • List users

LIST USERS
32

LIST ROLES

33

  • Alter users

ALTER USER <user-name> WITH <options>

35

36

  • Drop users

DROP USER <user-name>

37

38

Hope now you have a clear idea about permissions, users and roles in Cassandra. These things are mandatory in security. See you soon with another important topic. Thank You!

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s