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-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org