---
metadata:
  - name: generator
    content: Diplodoc Platform v5.50.6
alternate:
  - https://ydb.tech/docs/en/security/authorization.md
  - https://ydb.tech/docs/ru/security/authorization.md
sourcePath: en/core/security/authorization.md
---
> **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/en/llms.txt

# Authorization

## Basic concepts

Authorization in YDB is based on the concepts of:

* [Access object](https://ydb.tech/docs/en/concepts/glossary.md#access-object)
* [Access subject](https://ydb.tech/docs/en/concepts/glossary.md#access-subject)
* [Access right](https://ydb.tech/docs/en/concepts/glossary.md#access-right)
* [Access control list](https://ydb.tech/docs/en/concepts/glossary.md#access-acl)
* [Owner](https://ydb.tech/docs/en/concepts/glossary.md#access-owner)
* [User](https://ydb.tech/docs/en/concepts/glossary.md#access-user)
* [Group](https://ydb.tech/docs/en/concepts/glossary.md#access-group)

Regardless of the [authentication](https://en.wikipedia.org/wiki/Authentication) method, [authorization](https://en.wikipedia.org/wiki/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 {#user}

To create, alter, and delete users in YDB, the following commands are available:

* [CREATE USER](https://ydb.tech/docs/en/yql/reference/syntax/create-user.md)
* [ALTER USER](https://ydb.tech/docs/en/yql/reference/syntax/alter-user.md)
* [DROP USER](https://ydb.tech/docs/en/yql/reference/syntax/drop-user.md)

<!-- source: en/_includes/do-not-create-users-in-ldap.md -->
{% note info %}

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](https://ydb.tech/docs/en/security/authentication.md#ldap-auth-provider).

{% endnote %}
<!-- endsource: en/_includes/do-not-create-users-in-ldap.md -->

{% note info %}

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:

* [Ansible](https://ydb.tech/docs/en/devops/deployment-options/ansible/initial-deployment/index.md)
* [Kubernetes](https://ydb.tech/docs/en/devops/deployment-options/kubernetes/initial-deployment.md)
* [Manually](https://ydb.tech/docs/en/devops/deployment-options/manual/initial-deployment/index.md)

{% endnote %}

YDB allows working with [users](https://ydb.tech/docs/en/concepts/glossary.md#access-user) from different directories and systems, and they differ by [SID](https://ydb.tech/docs/en/concepts/glossary.md#access-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](https://ydb.tech/docs/en/security/authentication.md#ldap-auth-provider), 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 {#group}

Any [user](https://ydb.tech/docs/en/concepts/glossary.md#access-user) can be included in or excluded from a certain [access group](https://ydb.tech/docs/en/concepts/glossary.md#access-group). Once a user is included in a group, they receive all the rights to [database objects](https://ydb.tech/docs/en/concepts/glossary.md#access-object) 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 info %}

An access group can be empty when it does not include any users.

Access groups can be nested.

{% endnote %}

To create, alter, and delete [groups](https://ydb.tech/docs/en/concepts/glossary.md#access-group), the following types of YQL queries are available:

* [CREATE GROUP](https://ydb.tech/docs/en/yql/reference/syntax/create-group.md)
* [ALTER GROUP](https://ydb.tech/docs/en/yql/reference/syntax/alter-group.md)
* [DROP GROUP](https://ydb.tech/docs/en/yql/reference/syntax/drop-group.md)

## Right {#right}

[Rights](https://ydb.tech/docs/en/concepts/glossary.md#access-right) in YDB are tied not to the [subject](https://ydb.tech/docs/en/concepts/glossary.md#access-subject), but to the [access object](https://ydb.tech/docs/en/concepts/glossary.md#access-object).

Each access object has a list of permissions — [ACL](https://ydb.tech/docs/en/concepts/glossary.md#access-acl) (Access Control List) — it stores all the rights provided to [access subjects](https://ydb.tech/docs/en/concepts/glossary.md#subject) (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:

* [GRANT](https://ydb.tech/docs/en/yql/reference/syntax/grant.md).
* [REVOKE](https://ydb.tech/docs/en/yql/reference/syntax/revoke.md).

The following CLI commands are used for managing rights:

* [chown](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-permissions.md#chown)
* [grant](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-permissions.md#grant-revoke)
* [revoke](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-permissions.md#grant-revoke)
* [set](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-permissions.md#set)
* [clear](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-permissions.md#clear)
* [clear-inheritance](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-permissions.md#clear-inheritance)
* [set-inheritance](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-permissions.md#set-inheritance)

The following CLI commands are used to view the ACL of an access object:

* [describe](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-describe.md)
* [list](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-permissions.md#list)

## Object Owner {#owner}

Each access object has an [owner](https://ydb.tech/docs/en/concepts/glossary.md#access-owner). By default, it becomes the [access subject](https://ydb.tech/docs/en/concepts/glossary.md#access-subject) who created the [access object](https://ydb.tech/docs/en/concepts/glossary.md#access-object).

{% note info %}

For the owner, [permission lists](https://ydb.tech/docs/en/concepts/glossary.md#access-control-list) on this [access object](https://ydb.tech/docs/en/concepts/glossary.md#access-object) are not checked.

They have a full set of rights on the object.

{% endnote %}

An object owner exists for the entire cluster and each database.

The owner can be changed using the CLI command [`chown`](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-permissions.md#chown).

The owner of an object can be viewed using the CLI command [`describe`](https://ydb.tech/docs/en/reference/ydb-cli/commands/scheme-describe.md).