[james-project] branch master updated: JAMES-3061 James Administration Procedure on Cassandra permissions

[bt...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

btellier pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/james-project.git


The following commit(s) were added to refs/heads/master by this push:
     new 1e7280b  JAMES-3061 James Administration Procedure on Cassandra permissions
1e7280b is described below

commit 1e7280b8197c92f52e73e1b4d87854af212bab03
Author: Tran Tien Duc <dt...@linagora.com>
AuthorDate: Wed Feb 19 18:10:19 2020 +0700

    JAMES-3061 James Administration Procedure on Cassandra permissions
---
 .../server/manage-guice-distributed-james.md       | 84 +++++++++++++++++++++-
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/src/site/markdown/server/manage-guice-distributed-james.md b/src/site/markdown/server/manage-guice-distributed-james.md
index 85c9ed0..bb21016 100644
--- a/src/site/markdown/server/manage-guice-distributed-james.md
+++ b/src/site/markdown/server/manage-guice-distributed-james.md
@@ -21,7 +21,8 @@ advanced users.
  - [Mail Processing](#Mail_Processing)
  - [ElasticSearch Indexing](#Elasticsearch_Indexing)
  - [Solving cassandra inconsistencies](#Solving_cassandra_inconsistencies) 
- 
+ - [Setting Cassandra user permissions](#Setting_Cassandra_user_permissions)
+
 ## Overall architecture
 
 Guice distributed James server intends to provide a horizontally scalable email server.
@@ -325,4 +326,83 @@ avoiding peak traffic in order to address both inconsistencies diagnostic and fi
 
 #### How to solve
 
-Under development: Task for solving mailbox inconsistencies
\ No newline at end of file
+Under development: Task for solving mailbox inconsistencies ([JAMES-3058](https://issues.apache.org/jira/browse/JAMES-3058)).
+
+## Setting Cassandra user permissions
+
+When a Cassandra cluster is serving more than a James cluster, the keyspaces need isolation. 
+It can be achieved by configuring James server with credentials preventing access or modification of other keyspaces.
+
+We recommend you to not use the initial admin user of Cassandra and provide 
+a different one with a subset of permissions for each application. 
+
+### Prerequisites
+
+We're gonna use the Cassandra super users to create roles and grant permissions for them. 
+To do that, Cassandra requires you to login via username/password authentication 
+and enable granting in cassandra configuration file.
+
+For example:
+```
+echo -e "\nauthenticator: PasswordAuthenticator" >> /etc/cassandra/cassandra.yaml
+echo -e "\nauthorizer: org.apache.cassandra.auth.CassandraAuthorizer" >> /etc/cassandra/cassandra.yaml
+```
+### Prepare Cassandra roles & keyspaces for James  
+
+#### Create a role
+
+Have a look at [cassandra documentation](http://cassandra.apache.org/doc/3.11.3/cql/security.html) section `CREATE ROLE` for more information
+
+E.g.
+```
+CREATE ROLE james_one WITH PASSWORD = 'james_one' AND LOGIN = true;
+```
+#### Create a keyspace
+
+Have a look at [cassandra documentation](http://cassandra.apache.org/doc/3.11.3/cql/ddl.html) section `CREATE KEYSPACE` for more information
+
+#### Grant permissions on created keyspace to the role
+
+The role to be used by James needs to have full rights on the keyspace 
+that James is using. Assuming the keyspace name is `james_one_keyspace` 
+and the role be `james_one`.
+```
+GRANT CREATE ON KEYSPACE james_one_keyspace TO james_one; // Permission to create tables on the appointed keyspace
+GRANT SELECT ON	KEYSPACE james_one_keyspace TO james_one; // Permission to select from tables on the appointed keyspace
+GRANT MODIFY ON	KEYSPACE james_one_keyspace TO james_one; // Permission to update data in tables on the appointed keyspace
+```
+**Warning**: The granted role doesn't have the right to create keyspaces, 
+thus, if you haven't created the keyspace, James server will fail to start 
+is expected.  
+
+**Tips**
+
+Since all of Cassandra roles used by different James are supposed to 
+have a same set of permissions, you can reduce the works by creating a 
+base role set like `typical_james_role` with all of necessary permissions. 
+After that, with each James, create a new role and grant the `typical_james_role` 
+to the newly created one. Note that, once a base role set is updated ( 
+granting or revoking rights) all granted roles are automatically updated.  
+
+E.g.
+```
+CREATE ROLE james1 WITH PASSWORD = 'james1' AND LOGIN = true;
+GRANT typical_james_role TO james1;
+
+CREATE ROLE james2 WITH PASSWORD = 'james2' AND LOGIN = true;
+GRANT typical_james_role TO james2;
+```
+#### Revoke harmful permissions from the created role
+
+We want a specific role that cannot describe or query the information of other 
+keyspaces or tables used by another application. 
+By default, Cassandra allows every role created to have the right to 
+describe any keyspace and table. There's no configuration that can make 
+effect on that topic. Consequently, you have to accept that your data models 
+are still being exposed to anyone having credentials to Cassandra. 
+
+For more information, have a look at [cassandra documentation](http://cassandra.apache.org/doc/3.11.3/cql/security.html) section `REVOKE PERMISSION`. 
+
+Except for the case above, the permissions are not auto available for 
+a specific role unless they are granted by `GRANT` command. Therefore, 
+if you didn't provide more permissions than [granting section](#Grant_permissions_on_created_keyspace_to_the_role), there's no need to revoke.
\ No newline at end of file


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org