Authorization
Basic concepts
Authorization in YDB is based on the concepts of:
Regardless of the authentication method, authorization is always performed on the server side of YDB based on the stored information about access objects and rights. Access rights determine the set of operations available to perform.
Authorization is performed for each user action: the rights are not cached, as they can be revoked or granted at any time.
User
To create, alter, and delete users in YDB, the following commands are available:
Note
The scope of the commands CREATE USER, ALTER USER, and DROP USER does not extend to external user directories. Keep this in mind if users with third-party authentication (e.g., LDAP) are connecting to YDB. For example, the CREATE USER command does not create a user in the LDAP directory. Learn more about YDB's interaction with the LDAP directory.
Note
There is a separate user root with maximum rights. It is created during the initial deployment of the cluster, during which a password must be set immediately. It is not recommended to use this account long-term; instead, users with limited rights should be created.
More about initial deployment:
YDB allows working with users from different directories and systems, and they differ by SID using a suffix.
The suffix @<subsystem> identifies the "user source" or "auth domain", within which the uniqueness of all login is guaranteed. For example, in the case of LDAP authentication, user names will be user1@ldap and user2@ldap.
If a login without a suffix is specified, it implies users directly created in the YDB cluster.
Group
Any user can be included in or excluded from a certain access group. Once a user is included in a group, they receive all the rights to database objects that were provided to the access group.
With access groups in YDB, business roles for user applications can be implemented by pre-configuring the required access rights to the necessary objects.
Note
An access group can be empty when it does not include any users.
Access groups can be nested.
To create, alter, and delete groups, the following types of YQL queries are available:
Right
Rights in YDB are tied not to the subject, but to the access object.
Each access object has a list of permissions — ACL (Access Control List) — it stores all the rights provided to access subjects (users and groups) for the object.
By default, rights are inherited from parents to descendants in the access objects tree.
The following types of YQL queries are used for managing rights:
The following CLI commands are used for managing rights:
The following CLI commands are used to view the ACL of an access object:
Object Owner
Each access object has an owner. By default, it becomes the access subject who created the access object.
Note
For the owner, permission lists on this access object are not checked.
They have a full set of rights on the object.
An object owner exists for the entire cluster and each database.
The owner can be changed using the CLI command chown.
The owner of an object can be viewed using the CLI command describe.