cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From slebre...@apache.org
Subject [07/34] cassandra git commit: Add initial version of security section
Date Mon, 27 Jun 2016 18:34:02 GMT
Add initial version of security section


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/898b91a0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/898b91a0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/898b91a0

Branch: refs/heads/trunk
Commit: 898b91a029ff942b09221dea32d138ea988bd2ed
Parents: b1edbd1
Author: Sam Tunnicliffe <sam@beobal.com>
Authored: Thu Jun 16 17:52:51 2016 +0100
Committer: Sylvain Lebresne <sylvain@datastax.com>
Committed: Fri Jun 17 21:28:11 2016 +0200

----------------------------------------------------------------------
 doc/source/operations.rst | 386 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 384 insertions(+), 2 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cassandra/blob/898b91a0/doc/source/operations.rst
----------------------------------------------------------------------
diff --git a/doc/source/operations.rst b/doc/source/operations.rst
index 40b3e09..9e79700 100644
--- a/doc/source/operations.rst
+++ b/doc/source/operations.rst
@@ -437,15 +437,397 @@ Metric Reporters
 Security
 --------
 
+There are three main components to the security features provided by Cassandra:
+
+- TLS/SSL encryption for client and inter-node communication
+- Client authentication
+- Authorization
+
+TLS/SSL Encryption
+^^^^^^^^^^^^^^^^^^
+Cassandra provides secure communication between a client machine and a database cluster and
between nodes within a
+cluster. Enabling encryption ensures that data in flight is not compromised and is transferred
securely. The options for
+client-to-node and node-to-node encryption are managed separately and may be configured independently.
+
+In both cases, the JVM defaults for supported protocols and cipher suites are used when encryption
is enabled. These can
+be overidden using the settings in ``cassandra.yaml``, but this is not recommended unless
there are policies in place
+which dictate certain settings or a need to disable vulnerable ciphers or protocols in cases
where the JVM cannot be
+updated.
+
+FIPS compliant settings can be configured at the JVM level and should not involve changing
encryption settings in
+cassandra.yaml. See `the java document on FIPS <https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/FIPS.html>`__
+for more details.
+
+For information on generating the keystore and truststore files used in SSL communications,
see the
+`java documentation on creating keystores <http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CreateKeystore>`__
+
+Inter-node Encryption
+~~~~~~~~~~~~~~~~~~~~~
+
+The settings for managing inter-node encryption are found in ``cassandra.yaml`` in the ``server_encryption_options``
+section. To enable inter-node encryption, change the ``internode_encryption`` setting from
its default value of ``none``
+to one value from: ``rack``, ``dc`` or ``all``.
+
+Client to Node Encryption
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The settings for managing client to node encryption are found in ``cassandra.yaml`` in the
``client_encryption_options``
+section. There are two primary toggles here for enabling encryption, ``enabled`` and ``optional``.
+
+- If neither is set to ``true``, client connections are entirely unencrypted.
+- If ``enabled`` is set to ``true`` and ``optional`` is set to ``false``, all client connections
must be secured.
+- If both options are set to ``true``, both encrypted and unencrypted connections are supported
using the same port.
+  Client connections using encryption with this configuration will be automatically detected
and handled by the server.
+
+As an alternative to the ``optional`` setting, separate ports can also be configured for
secure and unsecure connections
+where operational requirements demand it. To do so, set ``optional`` to false and use the
``native_transport_port_ssl``
+setting in ``cassandra.yaml`` to specify the port to be used for secure client communication.
+
+.. _operation-roles:
+
 Roles
 ^^^^^
 
-.. todo:: todo
+Cassandra uses database roles, which may represent either a single user or a group of users,
in both authentication and
+permissions management. Role management is an extension point in Cassandra and may be configured
using the
+``role_manager`` setting in ``cassandra.yaml``. The default setting uses ``CassandraRoleManager``,
an implementation
+which stores role information in the tables of the ``system_auth`` keyspace.
+
+See also the :ref:`CQL documentation on roles <roles>`.
+
+Authentication
+^^^^^^^^^^^^^^
+
+Authentication is pluggable in Cassandra and is configured using the ``authenticator`` setting
in ``cassandra.yaml``.
+Cassandra ships with two options included in the default distribution.
+
+By default, Cassandra is configured with ``AllowAllAuthenticator`` which performs no authentication
checks and therefore
+requires no credentials. It is used to disable authentication completely. Note that authentication
is a necessary
+condition of Cassandra's permissions subsystem, so if authentication is disabled, effectively
so are permissions.
+
+The default distribution also includes ``PasswordAuthenticator``, which stores encrypted
credentials in a system table.
+This can be used to enable simple username/password authentication.
+
+.. _password-authentication:
+
+Enabling Password Authentication
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Before enabling client authentication on the cluster, client applications should be pre-configured
with their intended
+credentials. When a connection is initiated, the server will only ask for credentials once
authentication is
+enabled, so setting up the client side config in advance is safe. In contrast, as soon as
a server has authentication
+enabled, any connection attempt without proper credentials will be rejected which may cause
availability problems for
+client applications. Once clients are setup and ready for authentication to be enabled, follow
this procedure to enable
+it on the cluster.
+
+Pick a single node in the cluster on which to perform the initial configuration. Ideally,
no clients should connect
+to this node during the setup process, so you may want to remove it from client config, block
it at the network level
+or possibly add a new temporary node to the cluster for this purpose. On that node, perform
the following steps:
+
+1. Open a ``cqlsh`` session and change the replication factor of the ``system_auth`` keyspace.
By default, this keyspace
+   uses ``SimpleReplicationStrategy`` and a ``replication_factor`` of 1. It is recommended
to change this for any
+   non-trivial deployment to ensure that should nodes become unavailable, login is still
possible. Best practice is to
+   configure a replication factor of 3 to 5 per-DC.
+
+::
+
+    ALTER KEYSPACE system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1':
3, 'DC2': 3};
+
+2. Edit ``cassandra.yaml`` to change the ``authenticator`` option like so:
+
+::
+
+    authenticator: PasswordAuthenticator
+
+3. Restart the node.
+
+4. Open a new ``cqlsh`` session using the credentials of the default superuser:
+
+::
+
+    cqlsh -u cassandra -p cassandra
+
+5. During login, the credentials for the default superuser are read with a consistency level
of ``QUORUM``, whereas
+   those for all other users (including superusers) are read at ``LOCAL_ONE``. In the interests
of performance and
+   availability, as well as security, operators should create another superuser and disable
the default one. This step
+   is optional, but highly recommended. While logged in as the default superuser, create
another superuser role which
+   can be used to bootstrap further configuration.
+
+::
+
+    # create a new superuser
+    CREATE ROLE dba WITH SUPERUSER = true AND LOGIN = true AND PASSWORD = 'super';
+
+6. Start a new cqlsh session, this time logging in as the new_superuser and disable the default
superuser.
+
+::
+
+    ALTER ROLE cassandra WITH SUPERUSER = false AND LOGIN = false;
+
+7. Finally, set up the roles and credentials for your application users with :ref:`CREATE
ROLE <create-role-statement>`
+   statements.
+
+At the end of these steps, the one node is configured to use password authentication. To
roll that out across the
+cluster, repeat steps 2 and 3 on each node in the cluster. Once all nodes have been restarted,
authentication will be
+fully enabled throughout the cluster.
+
+Note that using ``PasswordAuthenticator`` also requires the use of :ref:`CassandraRoleManager
<operation-roles>`.
+
+See also: :ref:`setting-credentials-for-internal-authentication`, :ref:`CREATE ROLE <create-role-statement>`,
+:ref:`ALTER ROLE <alter-role-statement>`, :ref:`ALTER KEYSPACE <calter-keyspace-statement>`
and :ref:`GRANT PERMISSION
+<create-permission-statement>`,
+
+Authorization
+^^^^^^^^^^^^^
+
+Authorization is pluggable in Cassandra and is configured using the ``authorizer`` setting
in ``cassandra.yaml``.
+Cassandra ships with two options included in the default distribution.
+
+By default, Cassandra is configured with ``AllowAllAuthorizer`` which performs no checking
and so effectively grants all
+permissions to all roles. This must be used if ``AllowAllAuthenticator`` is the configured
authenticator.
+
+The default distribution also includes ``CassandraAuthorizer``, which does implement full
permissions management
+functionality and stores its data in Cassandra system tables.
+
+Enabling Internal Authorization
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Permissions are modelled as a whitelist, with the default assumption that a given role has
no access to any database
+resources. The implication of this is that once authorization is enabled on a node, all requests
will be rejected until
+the required permissions have been granted. For this reason, it is strongly recommended to
perform the initial setup on
+a node which is not processing client requests.
+
+The following assumes that authentication has already been enabled via the process outlined
in
+:ref:`password-authentication`. Perform these steps to enable internal authorization across
the cluster:
+
+1. On the selected node, edit ``cassandra.yaml`` to change the ``authorizer`` option like
so:
+
+::
+
+    authorizer: CassandraAuthorizer
+
+2. Restart the node.
+
+3. Open a new ``cqlsh`` session using the credentials of a role with superuser credentials:
+
+::
+
+    cqlsh -u dba -p super
+
+4. Configure the appropriate access privileges for your clients using `GRANT PERMISSION <cql.html#grant-permission>`_
+   statements. On the other nodes, until configuration is updated and the node restarted,
this will have no effect so
+   disruption to clients is avoided.
+
+::
+
+    GRANT SELECT ON ks.t1 TO db_user;
+
+5. Once all the necessary permissions have been granted, repeat steps 1 and 2 for each node
in turn. As each node
+   restarts and clients reconnect, the enforcement of the granted permissions will begin.
+
+See also: :ref:`GRANT PERMISSION <grant-permission-statement>`, `GRANT ALL <grant-all>`
and :ref:`REVOKE PERMISSION
+<revoke-permission-statement>`
+
+Caching
+^^^^^^^
+
+Enabling authentication and authorization places additional load on the cluster by frequently
reading from the
+``system_auth`` tables. Furthermore, these reads are in the critical paths of many client
operations, and so has the
+potential to severely impact quality of service. To mitigate this, auth data such as credentials,
permissions and role
+details are cached for a configurable period. The caching can be configured (and even disabled)
from ``cassandra.yaml``
+or using a JMX client. The JMX interface also supports invalidation of the various caches,
but any changes made via JMX
+are not persistent and will be re-read from ``cassandra.yaml`` when the node is restarted.
+
+Each cache has 3 options which can be set:
+
+Validity Period
+    Controls the expiration of cache entries. After this period, entries are invalidated
and removed from the cache.
+Refresh Rate
+    Controls the rate at which background reads are performed to pick up any changes to the
underlying data. While these
+    async refreshes are performed, caches will continue to serve (possibly) stale data. Typically,
this will be set to a
+    shorter time than the validity period.
+Max Entries
+    Controls the upper bound on cache size.
+
+The naming for these options in ``cassandra.yaml`` follows the convention:
+
+* ``<type>_validity_in_ms``
+* ``<type>_update_interval_in_ms``
+* ``<type>_cache_max_entries``
+
+Where ``<type>`` is one of ``credentials``, ``permissions``, or ``roles``.
+
+As mentioned, these are also exposed via JMX in the mbeans under the ``org.apache.cassandra.auth``
domain.
 
 JMX access
 ^^^^^^^^^^
 
-.. todo:: todo
+Access control for JMX clients is configured separately to that for CQL. For both authentication
and authorization, two
+providers are available; the first based on standard JMX security and the second which integrates
more closely with
+Cassandra's own auth subsystem.
+
+The default settings for Cassandra make JMX accessible only from localhost. To enable remote
JMX connections, edit
+``cassandra-env.sh`` (or ``cassandra-env.ps1`` on Windows) to change the ``LOCAL_JMX`` setting
to ``yes``. Under the
+standard configuration, when remote JMX connections are enabled, :ref:`standard JMX authentication
<standard-jmx-auth>`
+is also switched on.
+
+Note that by default, local-only connections are not subject to authentication, but this
can be enabled.
+
+If enabling remote connections, it is recommended to also use :ref:`SSL <jmx-with-ssl>`
connections.
+
+Finally, after enabling auth and/or SSL, ensure that tools which use JMX, such as :ref:`nodetool
<nodetool>`, are
+correctly configured and working as expected.
+
+.. _standard-jmx-auth:
+
+Standard JMX Auth
+~~~~~~~~~~~~~~~~~
+
+Users permitted to connect to the JMX server are specified in a simple text file. The location
of this file is set in
+``cassandra-env.sh`` by the line:
+
+::
+
+    JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"
+
+Edit the password file to add username/password pairs:
+
+::
+
+    jmx_user jmx_password
+
+Secure the credentials file so that only the user running the Cassandra process can read
it :
+
+::
+
+    $ chown cassandra:cassandra /etc/cassandra/jmxremote.password
+    $ chmod 400 /etc/cassandra/jmxremote.password
+
+Optionally, enable access control to limit the scope of what defined users can do via JMX.
Note that this is a fairly
+blunt instrument in this context as most operational tools in Cassandra require full read/write
access. To configure a
+simple access file, uncomment this line in ``cassandra-env.sh``:
+
+::
+
+    #JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access"
+
+Then edit the access file to grant your JMX user readwrite permission:
+
+::
+
+    jmx_user readwrite
+
+Cassandra must be restarted to pick up the new settings.
+
+See also : `Using File-Based Password Authentication In JMX
+<http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html#gdenv>`__
+
+
+Cassandra Integrated Auth
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+An alternative to the out-of-the-box JMX auth is to useeCassandra's own authentication and/or
authorization providers
+for JMX clients. This is potentially more flexible and secure but it come with one major
caveat. Namely that it is not
+available until `after` a node has joined the ring, because the auth subsystem is not fully
configured until that point
+However, it is often critical for monitoring purposes to have JMX access particularly during
bootstrap. So it is
+recommended, where possible, to use local only JMX auth during bootstrap and then, if remote
connectivity is required,
+to switch to integrated auth once the node has joined the ring and initial setup is complete.
+
+With this option, the same database roles used for CQL authentication can be used to control
access to JMX, so updates
+can be managed centrally using just ``cqlsh``. Furthermore, fine grained control over exactly
which operations are
+permitted on particular MBeans can be acheived via :ref:`GRANT PERMISSION <cgrant-permission-statement>`.
+
+To enable integrated authentication, edit ``cassandra-env.sh`` to uncomment these lines:
+
+::
+
+    #JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.remote.login.config=CassandraLogin"
+    #JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config=$CASSANDRA_HOME/conf/cassandra-jaas.config"
+
+And disable the JMX standard auth by commenting this line:
+
+::
+
+    JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"
+
+To enable integrated authorization, uncomment this line:
+
+::
+
+    #JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.authorizer=org.apache.cassandra.auth.jmx.AuthorizationProxy"
+
+Check standard access control is off by ensuring this line is commented out:
+
+::
+
+   #JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access"
+
+With integrated authentication and authorization enabled, operators can define specific roles
and grant them access to
+the particular JMX resources that they need. For example, a role with the necessary permissions
to use tools such as
+jconsole or jmc in read-only mode would be defined as:
+
+::
+
+    CREATE ROLE jmx WITH LOGIN = false;
+    GRANT SELECT ON ALL MBEANS TO jmx;
+    GRANT DESCRIBE ON ALL MBEANS TO jmx;
+    GRANT EXECUTE ON MBEAN 'java.lang:type=Threading' TO jmx;
+    GRANT EXECUTE ON MBEAN 'com.sun.management:type=HotSpotDiagnostic' TO jmx;
+
+    # Grant the jmx role to one with login permissions so that it can access the JMX tooling
+    CREATE ROLE ks_user WITH PASSWORD = 'password' AND LOGIN = true AND SUPERUSER = false;
+    GRANT jmx TO ks_user;
+
+Fine grained access control to individual MBeans is also supported:
+
+::
+
+    GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=Tables,keyspace=test_keyspace,table=t1'
TO ks_user;
+    GRANT EXECUTE ON MBEAN 'org.apache.cassandra.db:type=Tables,keyspace=test_keyspace,table=*'
TO ks_owner;
+
+This permits the ``ks_user`` role to invoke methods on the MBean representing a single table
in ``test_keyspace``, while
+granting the same permission for all table level MBeans in that keyspace to the ``ks_owner``
role.
+
+Adding/removing roles and granting/revoking of permissions is handled dynamically once the
initial setup is complete, so
+no further restarts are required if permissions are altered.
+
+See also: :ref:`Permissions <permissions>`.
+
+.. _jmx-with-ssl:
+
+JMX With SSL
+~~~~~~~~~~~~
+
+JMX SSL configuration is controlled by a number of system properties, some of which are optional.
To turn on SSL, edit
+the relevant lines in ``cassandra-env.sh`` (or ``cassandra-env.ps1`` on Windows) to uncomment
and set the values of these
+properties as required:
+
+``com.sun.management.jmxremote.ssl``
+    set to true to enable SSL
+``com.sun.management.jmxremote.ssl.need.client.auth``
+    set to true to enable validation of client certificates
+``com.sun.management.jmxremote.registry.ssl``
+    enables SSL sockets for the RMI registry from which clients obtain the JMX connector
stub
+``com.sun.management.jmxremote.ssl.enabled.protocols``
+    by default, the protocols supported by the JVM will be used, override with a comma-separated
list. Note that this is
+    not usually necessary and using the defaults is the preferred option.
+``com.sun.management.jmxremote.ssl.enabled.cipher.suites``
+    by default, the cipher suites supported by the JVM will be used, override with a comma-separated
list. Note that
+    this is not usually necessary and using the defaults is the preferred option.
+``javax.net.ssl.keyStore``
+    set the path on the local filesystem of the keystore containing server private keys and
public certificates
+``javax.net.ssl.keyStorePassword``
+    set the password of the keystore file
+``javax.net.ssl.trustStore``
+    if validation of client certificates is required, use this property to specify the path
of the truststore containing
+    the public certificates of trusted clients
+``javax.net.ssl.trustStorePassword``
+    set the password of the truststore file
+
+See also: `Oracle Java7 Docs <http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html#gdemv>`__,
+`Monitor Java with JMX <https://www.lullabot.com/articles/monitor-java-with-jmx>`__
+
+.. _nodetool:
 
 Nodetool (and other tooling)
 ----------------------------


Mime
View raw message