natas_hw
/
cassandra
mirror of https://github.com/apache/cassandra
0
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
cassandra/doc/source/cql/security.rst

539 lines
24 KiB
ReStructuredText
Raw Blame History

.. Licensed to the Apache Software Foundation (ASF) under one
.. or more contributor license agreements. See the NOTICE file
.. distributed with this work for additional information
.. regarding copyright ownership. The ASF licenses this file
.. to you under the Apache License, Version 2.0 (the
.. "License"); you may not use this file except in compliance
.. with the License. You may obtain a copy of the License at
..
.. http://www.apache.org/licenses/LICENSE-2.0
..
.. Unless required by applicable law or agreed to in writing, software
.. distributed under the License is distributed on an "AS IS" BASIS,
.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
.. See the License for the specific language governing permissions and
.. limitations under the License.
.. highlight:: cql
.. _cql-security:
Security
--------
.. _cql-roles:
Database Roles
^^^^^^^^^^^^^^
CQL uses database roles to represent users and group of users. Syntactically, a role is defined by:
.. productionlist::
role_name: `identifier` | `string`
.. _create-role-statement:
CREATE ROLE
~~~~~~~~~~~
Creating a role uses the ``CREATE ROLE`` statement:
.. productionlist::
create_role_statement: CREATE ROLE [ IF NOT EXISTS ] `role_name`
: [ WITH `role_options` ]
role_options: `role_option` ( AND `role_option` )*
role_option: PASSWORD '=' `string`
:| LOGIN '=' `boolean`
:| SUPERUSER '=' `boolean`
:| OPTIONS '=' `map_literal`
:| ACCESS TO DATACENTERS `set_literal`
:| ACCESS TO ALL DATACENTERS
For instance::
CREATE ROLE new_role;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
CREATE ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
CREATE ROLE carlos WITH OPTIONS = { 'custom_option1' : 'option1_value', 'custom_option2' : 99 };
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND ACCESS TO DATACENTERS {'DC1', 'DC3'};
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND ACCESS TO ALL DATACENTERS;
By default roles do not possess ``LOGIN`` privileges or ``SUPERUSER`` status.
:ref:`Permissions <cql-permissions>` on database resources are granted to roles; types of resources include keyspaces,
tables, functions and roles themselves. Roles may be granted to other roles to create hierarchical permissions
structures; in these hierarchies, permissions and ``SUPERUSER`` status are inherited, but the ``LOGIN`` privilege is
not.
If a role has the ``LOGIN`` privilege, clients may identify as that role when connecting. For the duration of that
connection, the client will acquire any roles and privileges granted to that role.
Only a client with with the ``CREATE`` permission on the database roles resource may issue ``CREATE ROLE`` requests (see
the :ref:`relevant section <cql-permissions>` below), unless the client is a ``SUPERUSER``. Role management in Cassandra
is pluggable and custom implementations may support only a subset of the listed options.
Role names should be quoted if they contain non-alphanumeric characters.
.. _setting-credentials-for-internal-authentication:
Setting credentials for internal authentication
```````````````````````````````````````````````
Use the ``WITH PASSWORD`` clause to set a password for internal authentication, enclosing the password in single
quotation marks.
If internal authentication has not been set up or the role does not have ``LOGIN`` privileges, the ``WITH PASSWORD``
clause is not necessary.
Restricting connections to specific datacenters
```````````````````````````````````````````````
If a ``network_authorizer`` has been configured, you can restrict login roles to specific datacenters with the
``ACCESS TO DATACENTERS`` clause followed by a set literal of datacenters the user can access. Not specifiying
datacenters implicitly grants access to all datacenters. The clause ``ACCESS TO ALL DATACENTERS`` can be used for
explicitness, but there's no functional difference.
Creating a role conditionally
`````````````````````````````
Attempting to create an existing role results in an invalid query condition unless the ``IF NOT EXISTS`` option is used.
If the option is used and the role exists, the statement is a no-op::
CREATE ROLE other_role;
CREATE ROLE IF NOT EXISTS other_role;
.. _alter-role-statement:
ALTER ROLE
~~~~~~~~~~
Altering a role options uses the ``ALTER ROLE`` statement:
.. productionlist::
alter_role_statement: ALTER ROLE `role_name` WITH `role_options`
For instance::
ALTER ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
Restricting connections to specific datacenters
```````````````````````````````````````````````
If a ``network_authorizer`` has been configured, you can restrict login roles to specific datacenters with the
``ACCESS TO DATACENTERS`` clause followed by a set literal of datacenters the user can access. To remove any
data center restrictions, use the ``ACCESS TO ALL DATACENTERS`` clause.
Conditions on executing ``ALTER ROLE`` statements:
- A client must have ``SUPERUSER`` status to alter the ``SUPERUSER`` status of another role
- A client cannot alter the ``SUPERUSER`` status of any role it currently holds
- A client can only modify certain properties of the role with which it identified at login (e.g. ``PASSWORD``)
- To modify properties of a role, the client must be granted ``ALTER`` :ref:`permission <cql-permissions>` on that role
.. _drop-role-statement:
DROP ROLE
~~~~~~~~~
Dropping a role uses the ``DROP ROLE`` statement:
.. productionlist::
drop_role_statement: DROP ROLE [ IF EXISTS ] `role_name`
``DROP ROLE`` requires the client to have ``DROP`` :ref:`permission <cql-permissions>` on the role in question. In
addition, client may not ``DROP`` the role with which it identified at login. Finally, only a client with ``SUPERUSER``
status may ``DROP`` another ``SUPERUSER`` role.
Attempting to drop a role which does not exist results in an invalid query condition unless the ``IF EXISTS`` option is
used. If the option is used and the role does not exist the statement is a no-op.
.. note:: DROP ROLE intentionally does not terminate any open user sessions. Currently connected sessions will remain
connected and will retain the ability to perform any database actions which do not require :ref:`authorization<authorization>`.
However, if authorization is enabled, :ref:`permissions<cql-permissions>` of the dropped role are also revoked,
subject to the :ref:`caching options<auth-caching>` configured in :ref:`cassandra.yaml<cassandra-yaml>`.
Should a dropped role be subsequently recreated and have new :ref:`permissions<grant-permission-statement>` or
:ref:`roles<grant-role-statement>` granted to it, any client sessions still connected will acquire the newly granted
permissions and roles.
.. _grant-role-statement:
GRANT ROLE
~~~~~~~~~~
Granting a role to another uses the ``GRANT ROLE`` statement:
.. productionlist::
grant_role_statement: GRANT `role_name` TO `role_name`
For instance::
GRANT report_writer TO alice;
This statement grants the ``report_writer`` role to ``alice``. Any permissions granted to ``report_writer`` are also
acquired by ``alice``.
Roles are modelled as a directed acyclic graph, so circular grants are not permitted. The following examples result in
error conditions::
GRANT role_a TO role_b;
GRANT role_b TO role_a;
GRANT role_a TO role_b;
GRANT role_b TO role_c;
GRANT role_c TO role_a;
.. _revoke-role-statement:
REVOKE ROLE
~~~~~~~~~~~
Revoking a role uses the ``REVOKE ROLE`` statement:
.. productionlist::
revoke_role_statement: REVOKE `role_name` FROM `role_name`
For instance::
REVOKE report_writer FROM alice;
This statement revokes the ``report_writer`` role from ``alice``. Any permissions that ``alice`` has acquired via the
``report_writer`` role are also revoked.
.. _list-roles-statement:
LIST ROLES
~~~~~~~~~~
All the known roles (in the system or granted to specific role) can be listed using the ``LIST ROLES`` statement:
.. productionlist::
list_roles_statement: LIST ROLES [ OF `role_name` ] [ NORECURSIVE ]
For instance::
LIST ROLES;
returns all known roles in the system, this requires ``DESCRIBE`` permission on the database roles resource. And::
LIST ROLES OF alice;
enumerates all roles granted to ``alice``, including those transitively acquired. But::
LIST ROLES OF bob NORECURSIVE
lists all roles directly granted to ``bob`` without including any of the transitively acquired ones.
Users
^^^^^
Prior to the introduction of roles in Cassandra 2.2, authentication and authorization were based around the concept of a
``USER``. For backward compatibility, the legacy syntax has been preserved with ``USER`` centric statements becoming
synonyms for the ``ROLE`` based equivalents. In other words, creating/updating a user is just a different syntax for
creating/updating a role.
.. _create-user-statement:
CREATE USER
~~~~~~~~~~~
Creating a user uses the ``CREATE USER`` statement:
.. productionlist::
create_user_statement: CREATE USER [ IF NOT EXISTS ] `role_name` [ WITH PASSWORD `string` ] [ `user_option` ]
user_option: SUPERUSER | NOSUPERUSER
For instance::
CREATE USER alice WITH PASSWORD 'password_a' SUPERUSER;
CREATE USER bob WITH PASSWORD 'password_b' NOSUPERUSER;
``CREATE USER`` is equivalent to ``CREATE ROLE`` where the ``LOGIN`` option is ``true``. So, the following pairs of
statements are equivalent::
CREATE USER alice WITH PASSWORD 'password_a' SUPERUSER;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND SUPERUSER = true;
CREATE USER IF NOT EXISTS alice WITH PASSWORD 'password_a' SUPERUSER;
CREATE ROLE IF NOT EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = true AND SUPERUSER = true;
CREATE USER alice WITH PASSWORD 'password_a' NOSUPERUSER;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true AND SUPERUSER = false;
CREATE USER alice WITH PASSWORD 'password_a' NOSUPERUSER;
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
CREATE USER alice WITH PASSWORD 'password_a';
CREATE ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
.. _alter-user-statement:
ALTER USER
~~~~~~~~~~
Altering the options of a user uses the ``ALTER USER`` statement:
.. productionlist::
alter_user_statement: ALTER USER `role_name` [ WITH PASSWORD `string` ] [ `user_option` ]
For instance::
ALTER USER alice WITH PASSWORD 'PASSWORD_A';
ALTER USER bob SUPERUSER;
.. _drop-user-statement:
DROP USER
~~~~~~~~~
Dropping a user uses the ``DROP USER`` statement:
.. productionlist::
drop_user_statement: DROP USER [ IF EXISTS ] `role_name`
.. _list-users-statement:
LIST USERS
~~~~~~~~~~
Existing users can be listed using the ``LIST USERS`` statement:
.. productionlist::
list_users_statement: LIST USERS
Note that this statement is equivalent to::
LIST ROLES;
but only roles with the ``LOGIN`` privilege are included in the output.
Data Control
^^^^^^^^^^^^
.. _cql-permissions:
Permissions
~~~~~~~~~~~
Permissions on resources are granted to roles; there are several different types of resources in Cassandra and each type
is modelled 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. For example,
granting ``SELECT`` on a ``KEYSPACE`` automatically grants it on all ``TABLES`` in that ``KEYSPACE``. Likewise, granting
a permission on ``ALL FUNCTIONS`` grants it on every defined function, regardless of which keyspace it is scoped in. It
is also possible to grant permissions on all functions scoped to a particular keyspace.
Modifications to permissions are visible to existing client sessions; that is, connections need not be re-established
following permissions changes.
The full set of available permissions is:
- ``CREATE``
- ``ALTER``
- ``DROP``
- ``SELECT``
- ``MODIFY``
- ``AUTHORIZE``
- ``DESCRIBE``
- ``EXECUTE``
Not all permissions are applicable to every type of resource. For instance, ``EXECUTE`` is only relevant in the context
of functions or mbeans; granting ``EXECUTE`` on a resource representing a table is nonsensical. Attempting to ``GRANT``
a permission on resource to which it cannot be applied results in an error response. The following illustrates which
permissions can be granted on which types of resource, and which statements are enabled by that permission.
=============== =============================== =======================================================================
Permission Resource Operations
=============== =============================== =======================================================================
``CREATE`` ``ALL KEYSPACES`` ``CREATE KEYSPACE`` and ``CREATE TABLE`` in any keyspace
``CREATE`` ``KEYSPACE`` ``CREATE TABLE`` in specified keyspace
``CREATE`` ``ALL FUNCTIONS`` ``CREATE FUNCTION`` in any keyspace and ``CREATE AGGREGATE`` in any
keyspace
``CREATE`` ``ALL FUNCTIONS IN KEYSPACE`` ``CREATE FUNCTION`` and ``CREATE AGGREGATE`` in specified keyspace
``CREATE`` ``ALL ROLES`` ``CREATE ROLE``
``ALTER`` ``ALL KEYSPACES`` ``ALTER KEYSPACE`` and ``ALTER TABLE`` in any keyspace
``ALTER`` ``KEYSPACE`` ``ALTER KEYSPACE`` and ``ALTER TABLE`` in specified keyspace
``ALTER`` ``TABLE`` ``ALTER TABLE``
``ALTER`` ``ALL FUNCTIONS`` ``CREATE FUNCTION`` and ``CREATE AGGREGATE``: replacing any existing
``ALTER`` ``ALL FUNCTIONS IN KEYSPACE`` ``CREATE FUNCTION`` and ``CREATE AGGREGATE``: replacing existing in
specified keyspace
``ALTER`` ``FUNCTION`` ``CREATE FUNCTION`` and ``CREATE AGGREGATE``: replacing existing
``ALTER`` ``ALL ROLES`` ``ALTER ROLE`` on any role
``ALTER`` ``ROLE`` ``ALTER ROLE``
``DROP`` ``ALL KEYSPACES`` ``DROP KEYSPACE`` and ``DROP TABLE`` in any keyspace
``DROP`` ``KEYSPACE`` ``DROP TABLE`` in specified keyspace
``DROP`` ``TABLE`` ``DROP TABLE``
``DROP`` ``ALL FUNCTIONS`` ``DROP FUNCTION`` and ``DROP AGGREGATE`` in any keyspace
``DROP`` ``ALL FUNCTIONS IN KEYSPACE`` ``DROP FUNCTION`` and ``DROP AGGREGATE`` in specified keyspace
``DROP`` ``FUNCTION`` ``DROP FUNCTION``
``DROP`` ``ALL ROLES`` ``DROP ROLE`` on any role
``DROP`` ``ROLE`` ``DROP ROLE``
``SELECT`` ``ALL KEYSPACES`` ``SELECT`` on any table
``SELECT`` ``KEYSPACE`` ``SELECT`` on any table in specified keyspace
``SELECT`` ``TABLE`` ``SELECT`` on specified table
``SELECT`` ``ALL MBEANS`` Call getter methods on any mbean
``SELECT`` ``MBEANS`` Call getter methods on any mbean matching a wildcard pattern
``SELECT`` ``MBEAN`` Call getter methods on named mbean
``MODIFY`` ``ALL KEYSPACES`` ``INSERT``, ``UPDATE``, ``DELETE`` and ``TRUNCATE`` on any table
``MODIFY`` ``KEYSPACE`` ``INSERT``, ``UPDATE``, ``DELETE`` and ``TRUNCATE`` on any table in
specified keyspace
``MODIFY`` ``TABLE`` ``INSERT``, ``UPDATE``, ``DELETE`` and ``TRUNCATE`` on specified table
``MODIFY`` ``ALL MBEANS`` Call setter methods on any mbean
``MODIFY`` ``MBEANS`` Call setter methods on any mbean matching a wildcard pattern
``MODIFY`` ``MBEAN`` Call setter methods on named mbean
``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
``AUTHORIZE`` ``ALL FUNCTIONS`` ``GRANT PERMISSION`` and ``REVOKE PERMISSION`` on any function
``AUTHORIZE`` ``ALL FUNCTIONS IN KEYSPACE`` ``GRANT PERMISSION`` and ``REVOKE PERMISSION`` in specified keyspace
``AUTHORIZE`` ``FUNCTION`` ``GRANT PERMISSION`` and ``REVOKE PERMISSION`` on specified function
``AUTHORIZE`` ``ALL MBEANS`` ``GRANT PERMISSION`` and ``REVOKE PERMISSION`` on any mbean
``AUTHORIZE`` ``MBEANS`` ``GRANT PERMISSION`` and ``REVOKE PERMISSION`` on any mbean matching
a wildcard pattern
``AUTHORIZE`` ``MBEAN`` ``GRANT PERMISSION`` and ``REVOKE PERMISSION`` on named mbean
``AUTHORIZE`` ``ALL ROLES`` ``GRANT ROLE`` and ``REVOKE ROLE`` on any role
``AUTHORIZE`` ``ROLES`` ``GRANT ROLE`` and ``REVOKE ROLE`` on specified roles
``DESCRIBE`` ``ALL ROLES`` ``LIST ROLES`` on all roles or only roles granted to another,
specified role
``DESCRIBE`` ``ALL MBEANS`` Retrieve metadata about any mbean from the platform's MBeanServer
``DESCRIBE`` ``MBEANS`` Retrieve metadata about any mbean matching a wildcard patter from the
platform's MBeanServer
``DESCRIBE`` ``MBEAN`` Retrieve metadata about a named mbean from the platform's MBeanServer
``EXECUTE`` ``ALL FUNCTIONS`` ``SELECT``, ``INSERT`` and ``UPDATE`` using any function, and use of
any function in ``CREATE AGGREGATE``
``EXECUTE`` ``ALL FUNCTIONS IN KEYSPACE`` ``SELECT``, ``INSERT`` and ``UPDATE`` using any function in specified
keyspace and use of any function in keyspace in ``CREATE AGGREGATE``
``EXECUTE`` ``FUNCTION`` ``SELECT``, ``INSERT`` and ``UPDATE`` using specified function and use
of the function in ``CREATE AGGREGATE``
``EXECUTE`` ``ALL MBEANS`` Execute operations on any mbean
``EXECUTE`` ``MBEANS`` Execute operations on any mbean matching a wildcard pattern
``EXECUTE`` ``MBEAN`` Execute operations on named mbean
=============== =============================== =======================================================================
.. _grant-permission-statement:
GRANT PERMISSION
~~~~~~~~~~~~~~~~
Granting a permission uses the ``GRANT PERMISSION`` statement:
.. productionlist::
grant_permission_statement: GRANT `permissions` ON `resource` TO `role_name`
permissions: ALL [ PERMISSIONS ] | `permission` [ PERMISSION ]
permission: CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE | DESCRIBE | EXECUTE
resource: ALL KEYSPACES
:| KEYSPACE `keyspace_name`
:| [ TABLE ] `table_name`
:| ALL ROLES
:| ROLE `role_name`
:| ALL FUNCTIONS [ IN KEYSPACE `keyspace_name` ]
:| FUNCTION `function_name` '(' [ `cql_type` ( ',' `cql_type` )* ] ')'
:| ALL MBEANS
:| ( MBEAN | MBEANS ) `string`
For instance::
GRANT SELECT ON ALL KEYSPACES TO data_reader;
This gives any user with the role ``data_reader`` permission to execute ``SELECT`` statements on any table across all
keyspaces::
GRANT MODIFY ON KEYSPACE keyspace1 TO data_writer;
This give any user with the role ``data_writer`` permission to perform ``UPDATE``, ``INSERT``, ``UPDATE``, ``DELETE``
and ``TRUNCATE`` queries on all tables in the ``keyspace1`` keyspace::
GRANT DROP ON keyspace1.table1 TO schema_owner;
This gives any user with the ``schema_owner`` role permissions to ``DROP`` ``keyspace1.table1``::
GRANT EXECUTE ON FUNCTION keyspace1.user_function( int ) TO report_writer;
This grants any user with the ``report_writer`` role permission to execute ``SELECT``, ``INSERT`` and ``UPDATE`` queries
which use the function ``keyspace1.user_function( int )``::
GRANT DESCRIBE ON ALL ROLES TO role_admin;
This grants any user with the ``role_admin`` role permission to view any and all roles in the system with a ``LIST
ROLES`` statement
.. _grant-all:
GRANT ALL
`````````
When the ``GRANT ALL`` form is used, the appropriate set of permissions is determined automatically based on the target
resource.
Automatic Granting
``````````````````
When a resource is created, via a ``CREATE KEYSPACE``, ``CREATE TABLE``, ``CREATE FUNCTION``, ``CREATE AGGREGATE`` or
``CREATE ROLE`` statement, the creator (the role the database user who issues the statement is identified as), is
automatically granted all applicable permissions on the new resource.
.. _revoke-permission-statement:
REVOKE PERMISSION
~~~~~~~~~~~~~~~~~
Revoking a permission from a role uses the ``REVOKE PERMISSION`` statement:
.. productionlist::
revoke_permission_statement: REVOKE `permissions` ON `resource` FROM `role_name`
For instance::
REVOKE SELECT ON ALL KEYSPACES FROM data_reader;
REVOKE MODIFY ON KEYSPACE keyspace1 FROM data_writer;
REVOKE DROP ON keyspace1.table1 FROM schema_owner;
REVOKE EXECUTE ON FUNCTION keyspace1.user_function( int ) FROM report_writer;
REVOKE DESCRIBE ON ALL ROLES FROM role_admin;
Because of their function in normal driver operations, certain tables cannot have their `SELECT` permissions
revoked. The following tables will be available to all authorized users regardless of their assigned role::
* `system_schema.keyspaces`
* `system_schema.columns`
* `system_schema.tables`
* `system.local`
* `system.peers`
.. _list-permissions-statement:
LIST PERMISSIONS
~~~~~~~~~~~~~~~~
Listing granted permissions uses the ``LIST PERMISSIONS`` statement:
.. productionlist::
list_permissions_statement: LIST `permissions` [ ON `resource` ] [ OF `role_name` [ NORECURSIVE ] ]
For instance::
LIST ALL PERMISSIONS OF alice;
Show all permissions granted to ``alice``, including those acquired transitively from any other roles::
LIST ALL PERMISSIONS ON keyspace1.table1 OF bob;
Show all permissions on ``keyspace1.table1`` granted to ``bob``, including those acquired transitively from any other
roles. This also includes any permissions higher up the resource hierarchy which can be applied to ``keyspace1.table1``.
For example, should ``bob`` have ``ALTER`` permission on ``keyspace1``, that would be included in the results of this
query. Adding the ``NORECURSIVE`` switch restricts the results to only those permissions which were directly granted to
``bob`` or one of ``bob``'s roles::
LIST SELECT PERMISSIONS OF carlos;
Show any permissions granted to ``carlos`` or any of ``carlos``'s roles, limited to ``SELECT`` permissions on any
resource.
Reference in New Issue View Git Blame Copy Permalink