-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configuration: document the 'credentials' option #4035
Conversation
ea999ec
to
9138851
Compare
949cf7d
to
1750c3d
Compare
707582d
to
232d204
Compare
328befc
to
cc629f0
Compare
cc629f0
to
377fe57
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the patchset! See my 6 comments on the privileges/permissions patch below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Credentials part of the patchset looks good, LGTM. See my only proposal below.
credentials.roles.* | ||
~~~~~~~~~~~~~~~~~~~ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I would prefer to have user
section before role
, because it has the primary meaning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, just some minor comments from my side.
doc/concepts/configuration.rst
Outdated
@@ -395,18 +395,15 @@ Access control | |||
~~~~~~~~~~~~~~ | |||
|
|||
The ``credentials`` section allows you to create users and grant them the specified privileges. | |||
In the example below, there are two users: | |||
In the example below, a password for the built-in 'admin' user is set: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the example below, a password for the built-in 'admin' user is set: | |
In the example below, a password for the built-in ``admin`` user is set: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can read more about the main concepts of Tarantool access control system in the :ref:`authentication` section. | ||
|
||
This topic describes how to create users and grant them the specified privileges in the :ref:`credentials <configuration_reference_credentials>` section of a YAML configuration. | ||
This might be used to create specific users used in communications between Tarantool instances. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Used to create users used
- needs rephrasing.
Also, specific
and specified
seem redundant in sentences of this paragraphs. It's better to keep short.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I get it right, these replication and sharding users are necessary in case of a sharded cluster (which is the main use case of Tarantool 3.0). If it's true, I'd expect a stronger wording expressing this, not just might be used
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Al right, the last comment on this paragraph =)
The only example made me think that this section is only for such technical users, while regular users are created from the Lua console. Maybe a bit more explicit explanation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Decided to remove the second sentence at all:
This topic describes how to create users and grant them the specified privileges in the :ref:`credentials <configuration_reference_credentials>` section of a YAML configuration.
For example, you can define users with the ``replication`` and ``sharding`` roles to maintain :ref:`replication <replication-master_replica_configuring_credentials>` and sharding in a Tarantool cluster.
:end-at: [ writers_space_reader ] | ||
:dedent: | ||
|
||
Apart from assigning a role to a user, you can grant specific privileges directly using :ref:`credentials.users.\<username\>.privileges <configuration_reference_credentials_users_name_privileges>`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: intro part Apart from assigning a role to a user
doesn't seem to add meaning, so I'd drop it to keep short. Up to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idea: maybe make separate headings Granting roles
and Granting privileges
to make the right ToC more explicit?
|
||
.. confval:: <user_or_role_name>.privileges.permissions | ||
|
||
Permissions assigned to this user or a user with this role. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possible values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New/updated topics
Configuration
section. Note that main concepts of access control system is described in the reworked Access control topic (PR: Rework the Access control topic #4024).New reference sections
Changes not directly related to this PR
Given that a privilege is a container for a permission and a corresponding object, it is necessary to clarify terminology in the existing
Access control
topic and related admin functions. So,privilege
is changed topermission
where applicable:Topic:
Reference - Updated signatures and descriptions: