Skip to content

Commit

Permalink
Add TCM LDAP authentication (#4468)
Browse files Browse the repository at this point in the history
Resolves #3635 

Co-authored-by: Andrey Aksenov <38073144+andreyaksenov@users.noreply.github.com>
  • Loading branch information
p7nov and andreyaksenov authored Aug 28, 2024
1 parent ccf83b2 commit a855e17
Show file tree
Hide file tree
Showing 11 changed files with 368 additions and 148 deletions.
2 changes: 1 addition & 1 deletion doc/tooling/tcm/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ to read data. LDAP authorization is supported as well.
tcm_cluster_management/index
tcm_cluster_data_access
tcm_cluster_migrations
tcm_access_control
tcm_access_control/index
tcm_audit_log
tcm_configuration
tcm_backend_store
Expand Down
31 changes: 31 additions & 0 deletions doc/tooling/tcm/tcm_access_control/index.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
.. _tcm_access_control:

Access control
==============

.. include:: ../index.rst
:start-after: ee_note_tcm_start
:end-before: ee_note_tcm_end

|tcm_full_name| provides means for managing user and client applications access
to its own functions and connected clusters:

- :ref:`Local role-based access model <tcm_access_control_rbac>` allow flexible
access management with user accounts created inside |tcm|.
- :ref:`LDAP authentication <tcm_ldap_auth>` enable authentication with an external
directory server.
- :ref:`Access control list <tcm_access_control_list>` enables fine-grained access
to entities stored on connected clusters.
- :ref:`API tokens <tcm_access_control_api_tokens>` enable integration with third-party applications.
- :ref:`Sessions management <tcm_access_control_sessions>` allow administrators to view and
revoke user sessions.


.. toctree::
:maxdepth: 1

tcm_access_control_rbac
tcm_ldap_auth
tcm_access_control_list
tcm_api_tokens
tcm_sessions
77 changes: 77 additions & 0 deletions doc/tooling/tcm/tcm_access_control/tcm_access_control_list.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
.. _tcm_access_control_list:

Access control list
===================

.. include:: ../index.rst
:start-after: ee_note_tcm_start
:end-before: ee_note_tcm_end

|tcm_full_name| *access control list* (*ACL*) determines user access to particular data
and functions stored in clusters. You can use it to allow or deny access to specific
stored objects one by one.

Each ACL entry specifies privileges that a |tcm| user has on a particular
space or a function. There are three access privileges that can be granted in the ACL:
read, write, and execute (for stored functions only). The privileges work as follows:

- Spaces:

- ``Read``: the user sees the space and its tuples on the **Tuples** and **Explorer** pages
- ``Write``: the user can add new and edit existing tuples of the space

- Functions:

- ``Read``: the user sees the function on the **Functions** tab of the instance details page.
- ``Write``: the user can edit or delete the function
- ``Execute``: the user can call the function

.. important::

User access to space data and stored functions is primarily defined by the
:ref:`cluster permissions <tcm_access_control_permissions_cluster>` ``cluster.space.data.*`` and ``cluster.func.*``.
ACL only increases the access control granularity to particular objects.
Make sure that users have these permissions before enabling ACL for them.

.. _tcm_access_control_list_enable:

Enabling ACL for a user
~~~~~~~~~~~~~~~~~~~~~~~

To granularly manage a user's access to particular objects in a cluster, enable
the use of ACL in the user profile:

#. Go to **Users** and click **Edit** in the **Actions** menu of the corresponding table row.

#. In the user's **Clusters** list, add a cluster on which you want to use ACL
or click the pencil icon if the cluster is already on the list.

#. Select the **Use Access Control List (ACL)** checkbox and save changes.

#. Repeat two previous steps for each cluster on which you want to use ACL for this user.

#. Click **Update** to save the user account.

If the user doesn't exist yet, you can do the same when creating it.

.. important::

When ACL use is enabled for a user, this user loses access to all spaces and
functions of the selected cluster except the ones explicitly specified in the ACL.

.. _tcm_access_control_list_manage:

Managing ACL
------------

The tools for managing ACL are located on the **ACL** page.

To add an ACL entry:

#. Click **Add**.
#. Select a user to which you want to grant access.
#. Select a cluster that stores the target object: a space or a function.
#. Select the target object type and enter its name.
#. Select the privileges you want to grant.

To delete an ACL entry, click **Delete** in the **Actions** menu of the corresponding table row.
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
.. _tcm_access_control:
.. _tcm_access_control_rbac:

Access control
==============
Role-based access control
=========================

.. include:: index.rst
.. include:: ../index.rst
:start-after: ee_note_tcm_start
:end-before: ee_note_tcm_end

Expand Down Expand Up @@ -57,7 +57,7 @@ There are two types of permissions in |tcm|: *administrative* and *cluster* perm
Cluster permissions are assigned to users individually when creating or editing them.

For a fine-grained control over user access to particular spaces and functions stored
in clusters, there is the :ref:`access control list <tcm_access_control_acl>`.
in clusters, there is the :ref:`access control list <tcm_access_control_list>`.

Permissions are predefined in |tcm|, there is no way to change, add, or delete them.
The complete lists of administrative and cluster permissions in |tcm| are provided
Expand Down Expand Up @@ -259,145 +259,6 @@ There are the following password policy settings:
- **Digits (0-9)**
- **Symbols (such as !@#$%^&\*()_+№"':,.;=][{}`?>/.)**

.. _tcm_access_control_acl:

Access control list
-------------------

|tcm|'s *access control list* (*ACL*) determines user access to particular data
and functions stored in clusters. You can use it to allow or deny access to specific
stored objects one by one.

Each ACL entry specifies privileges that a |tcm| user has on a particular
space or a function. There are three access privileges that can be granted in the ACL:
read, write, and execute (for stored functions only). The privileges work as follows:

- Spaces:

- ``Read``: the user sees the space and its tuples on the **Tuples** and **Explorer** pages
- ``Write``: the user can add new and edit existing tuples of the space

- Functions:

- ``Read``: the user sees the function on the **Functions** tab of the instance details page.
- ``Write``: the user can edit or delete the function
- ``Execute``: the user can call the function

.. important::

User access to space data and stored functions is primarily defined by the
:ref:`cluster permissions <tcm_access_control_permissions_cluster>` ``cluster.space.data.*`` and ``cluster.func.*``.
ACL only increases the access control granularity to particular objects.
Make sure that users have these permissions before enabling ACL for them.

.. _tcm_access_control_acl_enable:

Enabling ACL for a user
~~~~~~~~~~~~~~~~~~~~~~~

To granularly manage a user's access to particular objects in a cluster, enable
the use of ACL in the user profile:

#. Go to **Users** and click **Edit** in the **Actions** menu of the corresponding table row.

#. In the user's **Clusters** list, add a cluster on which you want to use ACL
or click the pencil icon if the cluster is already on the list.

#. Select the **Use Access Control List (ACL)** checkbox and save changes.

#. Repeat two previous steps for each cluster on which you want to use ACL for this user.

#. Click **Update** to save the user account.

If the user doesn't exist yet, you can do the same when creating it.

.. important::

When ACL use is enabled for a user, this user loses access to all spaces and
functions of the selected cluster except the ones explicitly specified in the ACL.

.. _tcm_access_control_acl_manage:

Managing ACL
~~~~~~~~~~~~

The tools for managing ACL are located on the **ACL** page.

To add an ACL entry:

#. Click **Add**.
#. Select a user to which you want to grant access.
#. Select a cluster that stores the target object: a space or a function.
#. Select the target object type and enter its name.
#. Select the privileges you want to grant.

To delete an ACL entry, click **Delete** in the **Actions** menu of the corresponding table row.

.. _tcm_access_control_sessions:

Sessions
--------

Administrators can view and revoke user sessions in |tcm|. All active sessions
are listed on the **Sessions** page. To revoke a session, click **Revoke** in the
**Actions** menu of the corresponding table row.

To revoke all sessions of a user, go to **Users** and click **Revoke all sessions**
in the **Actions** menu of the corresponding table row.

.. _tcm_access_control_api_tokens:

API tokens
----------

|tcm| uses the Bearer HTTP authentication scheme with *API tokens* to authenticate
external applications' requests to |tcm|. For example, these can be Prometheus
jobs that retrieve metrics of connected Tarantool clusters.

The API tokens functionality is disabled by default. To enable it, set the
:ref:`feature.api-token <tcm_configuration_reference_feature_api-token>` configuration option to ``true``.

.. code-block:: yaml
feature:
api-token: true
Each |tcm| API token belongs to the user that created it and has the same :ref:`access permissions <tcm_access_control_permissions>`.
Thus, if a user has a permission to view a cluster's metrics in |tcm|, this user's
API tokens can be used to read this cluster's metrics with Prometheus.

API tokens have expiration dates that are set during the token creation and cannot
be changed.

.. _tcm_access_control_api_tokens_manage:

Managing API tokens
~~~~~~~~~~~~~~~~~~~

.. note::

Each user, including **Default Admin** and other administrators, can create only
their own tokens. There is no way to create a token for another user.

To create a |tcm| API token:

#. Open the user settings by clicking the user's name in the top-right corner.
#. Go to the **API tokens** tab and click **Add**.
#. Specify the token expiration date and an optional description and click **Add**.

The created token is shown in a dialog.

.. important::

An API token is shown only once after its creation. There is no way to view
it again after you close the dialog. Make sure to copy the token in a safe place.

To delete an API token, click **Delete** in the actions menu of the corresponding
**API tokens** table row.

Administrators can also view information about users' API tokens and delete them
on the **Secrets** page. To open a user's secrets, click **Secrets** in the **Actions**
menu of the corresponding **Users** table row.

.. _tcm_access_control_permissions_ref:

Expand Down
57 changes: 57 additions & 0 deletions doc/tooling/tcm/tcm_access_control/tcm_api_tokens.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
.. _tcm_access_control_api_tokens:

API tokens
==========

.. include:: ../index.rst
:start-after: ee_note_tcm_start
:end-before: ee_note_tcm_end

|tcm_full_name| uses the Bearer HTTP authentication scheme with *API tokens* to authenticate
external applications' requests to |tcm|. For example, these can be Prometheus
jobs that retrieve metrics of connected Tarantool clusters.

The API tokens functionality is disabled by default. To enable it, set the
:ref:`feature.api-token <tcm_configuration_reference_feature_api-token>` configuration option to ``true``.

.. code-block:: yaml
feature:
api-token: true
Each |tcm| API token belongs to the user that created it and has the same :ref:`access permissions <tcm_access_control_permissions>`.
Thus, if a user has a permission to view a cluster's metrics in |tcm|, this user's
API tokens can be used to read this cluster's metrics with Prometheus.

API tokens have expiration dates that are set during the token creation and cannot
be changed.

.. _tcm_access_control_api_tokens_manage:

Managing API tokens
-------------------

.. note::

Each user, including **Default Admin** and other administrators, can create only
their own tokens. There is no way to create a token for another user.

To create a |tcm| API token:

#. Open the user settings by clicking the user's name in the top-right corner.
#. Go to the **API tokens** tab and click **Add**.
#. Specify the token expiration date and an optional description and click **Add**.

The created token is shown in a dialog.

.. important::

An API token is shown only once after its creation. There is no way to view
it again after you close the dialog. Make sure to copy the token in a safe place.

To delete an API token, click **Delete** in the actions menu of the corresponding
**API tokens** table row.

Administrators can also view information about users' API tokens and delete them
on the **Secrets** page. To open a user's secrets, click **Secrets** in the **Actions**
menu of the corresponding **Users** table row.
Loading

0 comments on commit a855e17

Please sign in to comment.