diff --git a/ydb/docs/ru/core/_includes/builtin-groups-graph.md b/ydb/docs/ru/core/_includes/builtin-groups-graph.md new file mode 100644 index 000000000000..d6660b18371f --- /dev/null +++ b/ydb/docs/ru/core/_includes/builtin-groups-graph.md @@ -0,0 +1,56 @@ +```mermaid +--- +config: + layout: elk + elk: + mergeEdges: true + nodePlacementStrategy: NETWORK_SIMPLEX +--- +graph BT + +DATA-WRITERS & DATABASE-ADMINS --> ADMINS +DDL-ADMINS & ACCESS-ADMINS --> DATABASE-ADMINS +DATA-READERS --> DATA-WRITERS +METADATA-READERS --> DATA-READERS & DDL-ADMINS +%%USERS --> METADATA-READERS & DATA-READERS & DATA-WRITERS & DDL-ADMINS & ACCESS-ADMINS & DATABASE-ADMINS & ADMINS +USERS --> METADATA-READERS & DDL-ADMINS & ACCESS-ADMINS + + DATA-READERS["DATA-READERS + +SelectRow" + ] + + DATA-WRITERS["DATA-WRITERS + +UpdateRow + +EraseRow" + ] + + METADATA-READERS["METADATA-READERS + +DescribeSchema + +ReadAttributes" + ] + + DATABASE-ADMINS["DATABASE-ADMINS + +CreateDatabase + +DropDatabase" + ] + + ACCESS-ADMINS["ACCESS-ADMINS + +GrantAccessRights" + ] + + DDL-ADMINS["DDL-ADMINS + +CreateDirectory + +CreateTable + +CreateQueue + +WriteAttributes + +AlterSchema + +RemoveSchema" + ] + + USERS[USERS + +ConnectDatabase + ] + ADMINS[ADMINS] +``` + +[//]: # (diplodoc support for mermaid lacks support for markdown in labels) diff --git a/ydb/docs/ru/core/_includes/do-not-create-users-in-ldap.md b/ydb/docs/ru/core/_includes/do-not-create-users-in-ldap.md index 119b6a658d2a..34b65e2660bf 100644 --- a/ydb/docs/ru/core/_includes/do-not-create-users-in-ldap.md +++ b/ydb/docs/ru/core/_includes/do-not-create-users-in-ldap.md @@ -3,6 +3,6 @@ Область действия команд `CREATE USER`, `ALTER USER`, `DROP USER` не распространяется на внешние каталоги пользователей. Учитывайте это, если к {{ ydb-short-name }} подключаются пользователи со сторонней аутентификацией (например, LDAP). Например, команда `CREATE USER` не создаст пользователя в LDAP-каталоге. -Подробнее про [взаимодействие {{ ydb-short-name }} с LDAP-каталогом](../security/authentication.md#ldap-auth-provider). +Подробнее про [взаимодействие {{ ydb-short-name }} с LDAP-каталогом](../security/authentication.md#ldap). {% endnote %} diff --git a/ydb/docs/ru/core/changelog-server.md b/ydb/docs/ru/core/changelog-server.md index afd5ae5e5abf..47726078fe51 100644 --- a/ydb/docs/ru/core/changelog-server.md +++ b/ydb/docs/ru/core/changelog-server.md @@ -85,7 +85,7 @@ * Добавлена возможность [задать приоритеты](./devops/manual/maintenance-without-downtime#priority) задачам обслуживания в [системе управления кластером](./concepts/glossary#cms). * Добавлена [настройка стабильных имён](./reference/configuration/#node-broker-config) для узлов кластера в рамках тенанта. -* Добавлено получение вложенных групп от [LDAP-сервера](./concepts/auth#ldap-auth-provider), в [LDAP-конфигурации](./reference/configuration/#ldap-auth-config) улучшен парсинг хостов и добавлена настройка для отключения встроенной аутентификацию по логину и паролю. +* Добавлено получение вложенных групп от [LDAP-сервера](./security/authentication.md#ldap), в [LDAP-конфигурации](./reference/configuration/index.md#ldap-auth-config) улучшен парсинг хостов и добавлена настройка для отключения встроенной аутентификацию по логину и паролю. * Добавлена возможность аутентификации [динамических узлов](./concepts/glossary#dynamic) по SSL-сертификату. * Реализовано удаление неактивных узлов из [Hive](./concepts/glossary#hive) без его перезапуска. * Улучшено управление inflight pings при перезапуске Hive в кластерах большого размера. diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md index 3c131a324b30..6792885d824f 100644 --- a/ydb/docs/ru/core/concepts/glossary.md +++ b/ydb/docs/ru/core/concepts/glossary.md @@ -269,6 +269,12 @@ **Секрет** или **secret** — это конфиденциальные метаданные, требующие особого обращения. Например, секреты могут использоваться в определениях [внешних источников данных](#external-data-source) и представляют собой такие сущности, как пароли и токены. +### Аутентификационный токен {#auth-token} + +**Аутентификационный токен** или **auth token** — токен, используемый для [аутентификации](../security/authentication.md) в {{ ydb-short-name }}. + +{{ ydb-short-name }} поддерживает [разные виды аутентификации](../security/authentication.md) и различные типы токенов. + ### Объект схемы {#scheme-object} Схема базы данных состоит из **схемных объектов** или **объектов схемы**, которыми могут быть базы данных, [таблицы](#table) (включая [внешние таблицы](#external-table)), [топики](#topic), [папки](#folder) и т.д. @@ -284,21 +290,36 @@ ### Объект доступа {#access-object} **Объект доступа** или **access object** при [авторизации](../security/authorization.md) — сущность, для которой настраиваются права и ограничения доступа. В {{ ydb-short-name }} объектами доступа являются [объекты схемы](#scheme-object). -У каждого объекта доступа есть [владелец](#access-owner) и [список разрешений](#access-control-list). + +У каждого [объекта схемы](#scheme-object) есть [владелец](#access-owner) и [список прав](#access-control-list) на этот объект, выданных пользователям и группам ([субъектам доступа](#access-subject)). ### Субъект доступа {#access-subject} -**Субъект доступа** или **access subject** — сущность, которая может обращаться к [объектам доступа](#access-object) или выполнять определённые действия в системе. Получение доступа при этих обращениях и действиях зависит от настроенных [списков разрешений](#access-control-list). +**Субъект доступа** или **access subject** — сущность, которая может обращаться к [объектам доступа](#access-object) и выполнять определённые действия в системе. + +Получение доступа при этих обращениях и действиях зависит от настроенных [списков прав](#access-control-list) и [уровня доступа](#access-level) субъекта. Субъектом доступа может быть [пользователь](#access-user) или [группа](#access-group). -### Право доступа {#access-right} +### Право {#access-right} **[Право доступа](../security/authorization.md#right)** или **access right** — сущность, отражающая разрешение [субъекту доступа](#access-subject) выполнять конкретный набор операций в кластере или базе данных над конкретным [объектом доступа](#access-object). -### Список разрешений {#access-control-list} +### Список прав {#access-control-list} + +**[Список прав](../security/authorization.md#right)**, **access control list** или **ACL** — список всех [прав](#access-right), предоставленных [субъектам доступа](#access-subject) (пользователям и группам) на конкретный [объект доступа](#access-object). + +### Уровень доступа {#access-level} + +**[Уровень доступа](../security/authorization.md#level)** — состояние, определяющее дополнительные возможности [субъекта доступа](#access-subject) при работе с [объектами схемы](#scheme-object), а также возможности [субъекта доступа](#access-subject) в контекстах, не связанных с [объектами схемы](#scheme-object). -**Список разрешений**, **access control list** или **ACL** — список всех [прав](#access-right), предоставленных [субъектам доступа](#access-subject) (пользователям и группам) на конкретный [объект доступа](#access-object). +Уровень доступа определяется принадлежностью субъекта к [спискам разрешений](#access-level-list). + +### Список уровня доступа {#access-level-list} + +**Список уровня доступа** или **список разрешений** — список [SID](#access-sid)'ов [субъектов доступа](#access-subject), которым разрешён определённый [уровень доступа](#access-level). + +{{ ydb-short-name }} имеет несколько [списков уровней доступа](../reference/configuration/index.md#security-access-levels), совместно определяющих набор [уровней доступа](#access-level) в системе. ### Владелец {#access-owner} @@ -308,13 +329,21 @@ **[Пользователь](../security/authorization.md#user)** - лицо, использующее {{ ydb-short-name }} для выполнения конкретной функции. +Пользователь идентифицируется [SID](#access-sid). + ### Группа {#access-group} -**[Группа](../security/authorization.md#group)** или **группа доступа** - именованное множество [пользователей](#access-user) с одинаковыми [правами доступа](#access-right) к тем или иным [объектам доступа](#access-object). +**[Группа](../security/authorization.md#group)** или **группа доступа** - именованное множество [пользователей](#access-user) и других групп с равными возможностями для своих членов. + +Группа идентифицируется [SID](#access-sid). ### SID {#access-sid} - **SID** (**Security Identifier**) - строка вида `[@]`, идентифицирующая [субъект доступа](../concepts/glossary.md#access-subject) в [списках разрешений](#access-control-list). +**SID** или **security identifier** — строка вида `` или `@`, идентифицирующая [субъект доступа](../concepts/glossary.md#access-subject). Используется при [аутентификации](../security/authentication.md), [авторизации](../security/authorization.md), в [списках прав](#access-control-list) и в [списках уровней доступа](#access-level-list). + +SID идентифицирует индивидуального [пользователя](#access-user) или [группу пользователей](#access-group). + +Опциональный суффикс `@` идентифицирует источник субъекта доступа, то есть внешний каталог или систему, откуда он был получен. Например, пользователи или группы из LDAP-каталога могут иметь суффикс `@ldap`. Отсутствие суффикса означает, что пользователь или группа созданы и существуют непосредственно в {{ ydb-short-name }}. ### Оптимизатор запросов {#optimizer} diff --git a/ydb/docs/ru/core/devops/manual/initial-deployment.md b/ydb/docs/ru/core/devops/manual/initial-deployment.md index 292af112a8a9..27fc2c52ec02 100644 --- a/ydb/docs/ru/core/devops/manual/initial-deployment.md +++ b/ydb/docs/ru/core/devops/manual/initial-deployment.md @@ -484,7 +484,7 @@ sudo chmod 700 /opt/ydb/certs Если в файле настроек кластера включен режим аутентификации, то перед началом работы с кластером {{ ydb-short-name }} необходимо выполнить первоначальную настройку учетных записей. -При первоначальной установке кластера {{ ydb-short-name }} автоматически создается учетная запись `root` с пустым паролем, а также стандартный набор групп пользователей, описанный в разделе [{#T}](../../yql/reference/syntax/alter-group.md#builtin). +При первоначальной установке кластера {{ ydb-short-name }} автоматически создается учетная запись `root` с пустым паролем, а также стандартный набор групп пользователей, описанный в разделе [{#T}](../../security/builtin-security.md). Для выполнения первоначальной настройки учетных записей в созданном кластере {{ ydb-short-name }} выполните следующие операции: diff --git a/ydb/docs/ru/core/reference/configuration/index.md b/ydb/docs/ru/core/reference/configuration/index.md index 4fd6da53fa9b..fa4b410d6a12 100644 --- a/ydb/docs/ru/core/reference/configuration/index.md +++ b/ydb/docs/ru/core/reference/configuration/index.md @@ -125,20 +125,49 @@ hosts: ## domains_config — домен кластера {#domains-config} -Данный раздел содержит конфигурацию корневого домена кластера {{ ydb-short-name }}, включая [конфигурации Blob Storage](#domains-blob) (хранилища бинарных объектов), [State Storage](#domains-state) (хранилища состояний) и [аутентификации](#auth). - -### Синтаксис +Данный раздел содержит конфигурацию кластера {{ ydb-short-name }}, включая [конфигурации Blob Storage](#domains-blob) (хранилища бинарных объектов), [State Storage](#domains-state) (хранилища состояний) и [настройки безопасности](#security). ``` yaml domains_config: domain: - - name: <имя корневого домена> + - name: <имя корня кластера> storage_pool_types: <конфигурация Blob Storage> state_storage: <конфигурация State Storage> - security_config: <конфигурация аутентификации> + disable_builtin_security: false + default_groups: false + default_access: false + security_config: <конфигурация безопасности> ``` -## Конфигурация Blob Storage {#domains-blob} +{% note info %} + +Формально, поле `domain` может содержать много элементов, так как это список, но имеет значение только первый элемент; остальные будут проигнорированы (в кластере может быть только один «домен»). + +{% endnote %} + +Флаги `disable_builtin_security`, `default_groups`, `default_access` влияют на настройку кластера, осуществляемую только при первом старте кластера {{ ydb-short-name }}. + +#| +|| Параметр | Описание || +|| `disable_builtin_security` | Не выполнять [встроенную настройку безопасности](../../security/builtin-security.md). +Встроенная настройка включает автоматическое создание суперпользователя `root`, набора встроенных пользовательских групп и выдачу прав доступа этим группам на корне кластера. + +Эфемерный флаг, не попадает в конфигурацию, сохраняемую в кластере. + +Значение по умолчанию: `false`. + || +|| `default_groups` | Отказаться от создания [встроенных групп](../../security/builtin-security.md), даже если явные группы по умолчанию ([`security_config.default_groups`](#security)) не заданы. + +Значение по умолчанию: `false` + || +|| `default_access` | Отказаться от добавления прав на корне кластера для [встроенных групп](../../security/builtin-security.md), даже если явные права по умолчанию ([`security_config.default_access`](#security)) не заданы. + +Значение по умолчанию: `false` + || +|# + + +### Конфигурация Blob Storage {#domains-blob} Данный раздел определяет один или более типов пулов хранения, доступных в кластере для данных в базах данных, со следующими возможностями конфигурации: @@ -155,27 +184,27 @@ domains_config: `block-4-2` | Избыточность с коэффициентом 1,5, применяется для однодатацентровых кластеров. `mirror-3-dc` | Избыточность с коэффициентом 3, применяется для мультидатацентровых кластеров. -### Синтаксис - ``` yaml - storage_pool_types: - - kind: <имя пула хранения> - pool_config: - box_id: 1 - encryption_mode: <опциональный, укажите 1 для шифрования данных на диске> - erasure_species: <имя режима отказоустойчивости - none, block-4-2, or mirror-3-dc> - kind: <имя пула хранения - укажите то же значение, что выше> - pdisk_filter: - - property: - - type: <тип устройства для сопоставления с указанным в host_configs.drive.type> - vdisk_kind: Default - - kind: <имя пула хранения> - # ... +domains_config: + domain: + ... + storage_pool_types: + - kind: <имя пула хранения> + pool_config: + box_id: 1 + encryption_mode: <опциональный, укажите 1 для шифрования данных на диске> + erasure_species: <имя режима отказоустойчивости - none, block-4-2, or mirror-3-dc> + kind: <имя пула хранения - укажите то же значение, что выше> + pdisk_filter: + - property: + - type: <тип устройства для сопоставления с указанным в host_configs.drive.type> + vdisk_kind: Default + - kind: <имя пула хранения> ``` Каждой базе данных в кластере назначается как минимум один из доступных пулов хранения, выбираемый в операции создания базы данных. Имена пулов хранения среди назначенных могут быть использованы в атрибуте `DATA` при определении групп колонок в операторах YQL [`CREATE TABLE`](../../yql/reference/syntax/create_table/family.md)/[`ALTER TABLE`](../../yql/reference/syntax/alter_table/family.md). -## Конфигурация State Storage {#domains-state} +### Конфигурация State Storage {#domains-state} State Storage (хранилище состояний) — это независимое хранилище в памяти для изменяемых данных, поддерживающее внутренние процессы {{ ydb-short-name }}. Оно хранит реплики данных на множестве назначенных узлов. @@ -193,37 +222,231 @@ State Storage (хранилище состояний) — это независ При развертывании State Storage на кластерах, в которых применяется несколько пулов хранения с возможным сочетанием режимов отказоустойчивости, рассмотрите возможность увеличения количества узлов с распространением их на разные пулы хранения, так как недоступность State Storage приводит к недоступности всего кластера. -### Синтаксис - ```yaml -state_storage: -- ring: - node: <массив узлов StateStorage> - nto_select: <количество реплик данных в StateStorage> - ssid: 1 +domains_config: + ... + state_storage: + - ring: + node: <массив узлов StateStorage> + nto_select: <количество реплик данных в StateStorage> + ssid: 1 ``` Каждый клиент State Storage (например, таблетка DataShard) использует `nto_select` узлов для записи копий его данных в State Storage. Если State Storage состоит из большего количества узлов чем `nto_select`, то разные узлы могут быть использованы для разных клиентов, поэтому необходимо обеспечить, чтобы любое подмножество из `nto_select` узлов в пределах State Storage отвечало критериям отказоустойчивости. Для `nto_select` должны использоваться нечетные числа, так как использование четных чисел не улучшает отказоустойчивость по сравнению с ближайшим меньшим нечетным числом. -## Конфигурация аутентификации {#auth} - -[Режим аутентификации](../../security/authentication.md) на кластере {{ ydb-short-name }} задается в разделе `domains_config.security_config`. +### Конфигурация безопасности {#security} -### Синтаксис +В разделе `domains_config.security_config` задаются режимы [аутентификации](../../security/authentication.md), первичная конфигурация локальных [пользователей](../../concepts/glossary.md#access-user) и [групп](../../concepts/glossary.md#access-group) и их [права](../../concepts/glossary.md#access-right). ```yaml domains_config: ... security_config: - enforce_user_token_requirement: Bool - ... + # настройка режима аутентификации + enforce_user_token_requirement: false + enforce_user_token_check_requirement: false + default_user_sids: <аутентификационный токен для анонимных запросов> + all_authenticated_users: <имя группы всех аутентифицированных пользователей> + all_users_group: <имя группы всех пользователей> + + # первичные настройки безопасности + default_users: <список пользователей по умолчанию> + default_groups: <список групп по умолчанию> + default_access: <список прав по умолчанию на корне кластера> + + # настройки привилегий + viewer_allowed_sids: <список SID'ов с правами просмотра состояния кластера> + monitoring_allowed_sids: <список SID'ов с правами просмотра и изменения состояния кластера> + administration_allowed_sids: <список SID'ов с доступом администратора кластера> ``` -Ключ | Описание ---- | --- -`enforce_user_token_requirement` | Требовать токен пользователя.
Допустимые значения:
  • `false` — режим аутентификации анонимный, токен не требуется (применяется по умолчанию, если параметр не задан);
  • `true` — режим аутентификации по логину и паролю, для выполнения запроса требуется валидный токен пользователя.
+[//]: # (TODO: wait for pull/9387, dynamic_node_registration to add info about "register_dynamic_node_allowed_sids: <список SID'ов с правами подключения динамических нод в кластер>") + +#### Настройки режима аутентификации {#security-auth} + +#| +|| Параметр | Описание || +|| `enforce_user_token_requirement` | Режим обязательной [аутентификации](../../security/authentication.md). + +- `enforce_user_token_requirement: true` — аутентификация обязательна, запросы к {{ ydb-short-name }} обязаны сопровождаться [аутентификационным токеном](../../concepts/glossary.md#auth-token). + + Запросы проходят аутентификацию и проверку прав. + +- `enforce_user_token_requirement: false` — аутентификация опциональна, запросы к {{ ydb-short-name }} могут не сопровождаться [аутентификационным токеном](../../concepts/glossary.md#auth-token). + + Запросы без токена выполняются в [анонимном режиме](../../security/authentication.md#anonymous) и без проверки прав. + + Запросы с токеном проходят аутентификацию и проверку прав. Но в случае ошибок аутентификации, запросы не запрещаются, а выполняются в анонимном режиме. + + При `enforce_user_token_check_requirement: true` выполнение запросов с ошибкой аутентификации запрещается. + +[//]: # (TODO: добавить про ошибки проверки права на доступ к базе данных, когда появится место для ссылки) + +Взамен отсутствующего в запросах токена используется значение параметра `default_user_sids`, если параметр определён и не пустой (см. описание ниже). Тогда аутентификация и проверка прав проводится для [субъекта доступа](../../concepts/glossary.md#access-subject), заданного `default_user_sids`. + +Значение по умолчанию: `false`. + || +|| `enforce_user_token_check_requirement` | Запрещает игнорировать ошибки аутентификации в режиме `enforce_user_token_requirement: false`. + +Значение по умолчанию: `false`. + || +|| `default_user_sids` | Список [SID](../../concepts/glossary.md#access-sid)'ов для использования в проверке аутентификации в случае, когда входящий запрос не сопровождается явным [аутентификационным токеном](../../concepts/glossary.md#auth-token). + +`default_user_sids` играет роль аутентификационного токена для анонимных запросов. Первым элементом в списке должен быть SID пользователя, за ним должны идти SID'ы групп, к которым пользователь принадлежит. + +Непустой `default_user_sids` позволяет использовать режим обязательной аутентификации (`enforce_user_token_requirement: true`) вместе с анонимными запросами. Это может быть полезно в определённых сценариях тестирования {{ ydb-short-name }} или в ознакомительных целях для локальных баз данных. + +Значение по умолчанию: пустой список. + || +|| `all_authenticated_users` | Имя виртуальной [группы](../../concepts/glossary.md#access-group), в которой состоят все аутентифицированные [пользователи](../../concepts/glossary.md#access-user). + +Виртуальную группу не нужно явно создавать, она ведётся системой автоматически. Виртуальную группу нельзя удалить, нельзя получить или изменить список её членов. +Пользователь может использовать её для выдачи [прав](../../concepts/glossary.md#access-right) на [схемных объектах](../../concepts/glossary.md#scheme-object). + +Значение по умолчанию: `all-users@well-known`. + || +|| `all_users_group` | Имя [группы](../../concepts/glossary.md#access-group), в которую должны добавляться все локальные [пользователи](../../concepts/glossary.md#access-user). + +Если `all_users_group` не пустая, то все локальные пользователи в момент создания будут добавляться в группу с указанным именем. В момент создания пользователей группа должна существовать. + +`all_users_group` автоматически конфигурируется при выполнении [встроенной настройки безопасности](../../security/builtin-security.md). + +Значение по умолчанию: пустая строка. + || +|# + +#### Первичные настройки безопасности {#security-bootstrap} + +Параметры `default_users`, `default_groups`, `default_access` влияют на настройку кластера, осуществляемую при первом старте {{ ydb-short-name }}. При последующих запусках первичная настройка не выполняется, эти параметры игнорируются. + +См. также раздел по [встроенной настройке безопасности](../../security/builtin-security.md) и влияющие на неё настройки [уровня `domains_config`](#domains-config). + +#| +|| Параметр | Описание || +|| `default_users` | Какие [пользователи](../../concepts/glossary.md#access-user) должны быть созданы на кластере при первом запуске. + +Список пар логин-пароль. Первый пользователь становится суперпользователем. + +{% note info %} + +Пароли задаются в открытом виде и оставлять их действующими на долгое время небезопасно. Поэтому после первого запуска кластера и его настройки рекомендуется пароли стартовым пользователям поменять средствами {{ ydb-short-name }} (например, [`ALTER USER`](../../yql/reference/syntax/alter-user.md)). + +[//]: # (TODO: добавить про возможность блокировки этих стартовых пользователей, когда такое описание появится) + +{% endnote %} + +Пример: + +```yaml +default_users: +- name: root + password: <...> +- name: user1 + password: <...> +``` + +Ошибки в списке (повторение логинов) фиксируются в логе, но не влияют на запуск кластера. + + || +|| `default_groups` | Какие [группы](../../concepts/glossary.md#access-group) должны быть созданы на кластере при первом запуске. + +Список групп и их членов. + +Пример: + +```yaml +default_groups: +- name: ADMINS + members: root +- name: USERS + members: + - ADMINS + - root + - user1 +``` + +Порядок перечисления групп важен: группы создаются в порядке перечисления, и указанные члены группы к моменту создания группы должны существовать, иначе они не будут добавлены в группу. + +Ошибки добавления членов групп фиксируются в логе, но не влияют на запуск кластера. + + || +|| `default_access` | Какие [права](../../concepts/glossary.md#access-right) должны быть выданы на корне кластера. + +Список разрешений в формате [краткой записи управления доступом](../../security/short-access-control-notation.md). + +Пример: + +```yaml +default_access: +- +(CDB|DDB|GAR):ADMINS +- +(ConnDB):USERS +``` + + || +|# + +Ошибки в строках прав доступа фиксируются в логе, но не влияют на запуск кластера. Право доступа с ошибкой не будет добавлено. + +[//]: # (TODO: требуется доработка, сейчас ошибка в формате приводит к падению процесса) + +#### Настройки административных и других привилегий {#security-access-levels} + +Управление доступом в {{ ydb-short-name }} реализуется двумя механизмами: + +- [списками прав](../../concepts/glossary.md#access-control-list) на [схемных объектах](../../concepts/glossary.md#scheme-object); +- [уровнями доступа](../../concepts/glossary.md#access-level-list), определяющими дополнительные возможности или ограничения. + +Оба механизма применяются одновременно: для конкретного [субъекта](../../concepts/glossary.md#access-subject) действие оказывается доступно, если оба механизма его разрешают, и не доступно, если хотя бы один не разрешает. + +Уровень доступа субъекта определяется списками разрешений, заданными в конфигурации кластера, и влияет на дополнительные возможности субъекта при работе со [схемными объектами](../../concepts/glossary.md#scheme-object), а также на возможности субъекта в контекстах, не связанных со схемными объектами. + +[//]: # (TODO: добавить ссылку на справку по viewer api и требуемым правам, когда она появится) + +#| +|| Параметр | Описание || +|| `viewer_allowed_sids` | Список [SID](../../concepts/glossary.md#access-sid)'ов с доступом уровня наблюдателя. + +Даёт возможность просмотра состояния системы, закрытого от публичного доступа (это большая часть страниц Embedded UI ([YDB Monitoring](../embedded-ui/ydb-monitoring.md))), без возможности делать изменения. + || +|| `monitoring_allowed_sids` | Список [SID](../../concepts/glossary.md#access-sid)'ов с доступом уровня оператора. + +Даёт дополнительные возможности просмотра и выполнения действий, меняющих состояние системы. Например, выполнение бекапа, восстановления базы или выполнение YQL-запросов через Embedded UI. + || +|| `administration_allowed_sids` | Список [SID](../../concepts/glossary.md#access-sid)'ов с доступом уровня администратора. + +Даёт право на выполнение административных действий с базами или кластером. + || +|# + +[//]: # (TODO: wait for pull/9387, dinamic_node_registration to add info about `register_dynamic_node_allowed_sids`) + +{% note warning %} + +По-умолчанию, все списки пустые. + +Пустой список разрешает доступ любому пользователю (включая анонимного пользователя). + +Все три пустых списка дают возможности администратора любому пользователю системы. + +Для защищённого развёртывания {{ ydb-short-name }} важно заранее определить модель прав и прописать в списках соответствующие группы. + +{% endnote %} + +В списках могут перечисляться индивидуальные SID'ы [пользователей](../../concepts/glossary.md#access-user) или SID'ы [групп пользователей](../../concepts/glossary.md#access-group). Принадлежность пользователя к списку определяется по прямому вхождению или по вхождению в список любой его группы (рекурсивно). +Рекомендуется включать в списки `*_allowed_sids` группы и отдельные сервисные аккаунты, тогда наделение индивидуальных пользователей соответствующими возможностями не будет требовать изменения общей конфигурации кластера. + +Списки разрешений можно воспринимать как слои дополнительных разрешений: + +- Субъект, не состоящий ни в одном списке разрешений, имеет возможность просмотра публично доступной информации в системе (например, может видеть [список баз на кластере](../embedded-ui/ydb-monitoring.md#tenant_list_page) или [список узлов кластера](../embedded-ui/ydb-monitoring.md#node_list_page)). +- Списки `viewer_allowed_sids`, `monitoring_allowed_sids`, `administration_allowed_sids` последовательно наращивают возможности субъекта. Максимальные возможности требуют включения во все три списка. +- Присутствие в списке `monitoring_allowed_sids` или `administration_allowed_sids` без присутствия во `viewer_allowed_sids` не имеет смысла. + +Например: + +- оператор должен состоять (прямо или через группы) во `viewer_allowed_sids` и в `monitoring_allowed_sids`; +- полноценный администратор должен состоять во `viewer_allowed_sids`, `monitoring_allowed_sids` и в `administration_allowed_sids`. ### Примеры {#domains-examples} @@ -599,19 +822,19 @@ blob_storage_config: Для конфигурации расположенной в 3 AZ необходимо указать 3 кольца. Для конфигураций, расположенных в одной AZ, указывается ровно одно кольцо. -## Конфигурирование провайдеров аутентификации {#auth-config} +## Конфигурация аутентификации {#auth-config} -{{ ydb-short-name }} позволяет использовать различные способы аутентификации пользователя. Конфигурирование провайдеров аутентификации задается в секции `auth_config`. +{{ ydb-short-name }} позволяет использовать различные способы аутентификации пользователя в системе. Настройки аутентификации и провайдеров аутентификации задаются в секции `auth_config`. ### Конфигурация LDAP аутентификации {#ldap-auth-config} -Одним из способов аутентификации пользователей в {{ ydb-short-name }} является использование LDAP каталога. Подробнее о таком виде аутентификации написано в разделе про [взаимодействие {{ ydb-short-name }} с LDAP каталогом](../../security/authentication.md#ldap-auth-provider). Для конфигурирования LDAP аутентификации необходимо описать секцию `ldap_authentication`. +Одним из способов аутентификации пользователей в {{ ydb-short-name }} является использование LDAP каталога. Подробнее о таком виде аутентификации написано в разделе про [использование LDAP каталога](../../security/authentication.md#ldap). Для конфигурирования LDAP аутентификации необходимо описать секцию `ldap_authentication`. Пример секции `ldap_authentication`: ```yaml auth_config: - #... + ... ldap_authentication: hosts: - "ldap-hostname-01.example.net" @@ -633,7 +856,7 @@ auth_config: enable_nested_groups_search: true refresh_time: "1h" - #... + ... ``` Параметр | Описание diff --git a/ydb/docs/ru/core/security/admin-users.md b/ydb/docs/ru/core/security/admin-users.md new file mode 100644 index 000000000000..86c09874fd83 --- /dev/null +++ b/ydb/docs/ru/core/security/admin-users.md @@ -0,0 +1,59 @@ +# Привилегированные пользователи + +- `root` -- суперпользователь +- администратор кластера (СУБД) +- администратор базы + +## Суперпользователь + +Суперпользователь создаётся при первом развёртывании кластера. + +По-умолчанию суперпользователь имеет логин `root` и пустой пароль. + +Задать другое имя и пароль для суперпользователя можно в секции [`auth_config`](../reference/configuration/index.md#auth-config) конфигурации кластера. Суперпользователем становится первый пользователь из списка `auth_config.default_users`. + +TODO: суперпользователь -- не полный суперпользователь, если не состоит прямо или косвенно в `domains_config.security_config.administration_allowed_sids`. + +## Администратор кластера (СУБД) + +Администратор кластера имеет неограниченные права на всём кластере. + +Для этого администратор кластера должен: + +1. принадлежать списку `domains_config.security_config.administration_allowed_sids` +2. и иметь полные права на корне схемы кластера + +Принадлежность списку `domains_config.security_config.administration_allowed_sids` определяется прямым вхождением или через группу. + +Например, если кластер развёрнут со [встроенными группами безопасности](./builtin-security.md), то администратор кластера должен принадлежать группе `ADMINS`. + +## Администратор базы данных + +--- + +## Конфиг + +## Пользователи, группа и права по-умолчанию + +`auth_config.default_users` -- какие пользователи должны быть созданы на кластере по-умолчанию +`auth_config.default_groups` -- какие группы должны быть созданы на кластере по-умолчанию +`auth_config.default_access` -- права доступа по-умолчанию на корне кластера + +## Справка по конфигурации + +Эфемерные флаги: + - `domains_config.disable_builtin_security` -- отключить ли использование суперпользователя `root`, "встроенных" групп, и "встроенных" прав доступа на корне кластера (флаг, default: false) + - `domains_config.default_groups` -- регистрировать ли "встроенные" группы, если явные группы по-умолчанию `auth_config.default_groups` не заданы (флаг, default: false) + - `domains_config.default_access` -- прописывать ли "встроенные" права доступа на корне кластера (флаг, default: false) + +`auth_config.default_users` -- какие пользователи должны быть созданы на кластере по-умолчанию (список пар логин-пароль), первый пользователь становится суперпользователем) +`auth_config.default_groups` -- какие группы должны быть созданы на кластере по-умолчанию +`auth_config.default_access` -- права доступа по-умолчанию на корне кластера + +`auth_config.use_builtin_domain` -- разрешено ли использование "встроенных" sid'ов (из аутентификационного домена `@builtin`): `root@builtin` и т.п. (default: true) +`auth_config.enable_login_authentication` -- включена ли возможность логина (то есть обмена логина-пароля на токен) (default: true) + +`auth_config.domain_login_only` -- логины делаются только против корневой базы (то есть против кластера) или можно логиниться в конкретную базу (default: true) + +`auth_config.all_authenticated_users` -- sid для виртуальной группы пользователей, прошедших аутентификацию. Автоматически добавляется к пользовательскому токену в момент аутентификации (default: `all-users@well-known`) + diff --git a/ydb/docs/ru/core/security/authentication.md b/ydb/docs/ru/core/security/authentication.md index d421cbae8b9b..5c24463dd7b8 100644 --- a/ydb/docs/ru/core/security/authentication.md +++ b/ydb/docs/ru/core/security/authentication.md @@ -1,6 +1,6 @@ # Аутентификация -После успешной установки сетевого соединения сервер принимает к обработке запросы от клиента, в которых передается аутентификационная информация. На ее основании сервер определяет учетную запись (аккаунт) клиента и проверяет доступ на выполнение запроса. +После успешной установки сетевого соединения сервер принимает к обработке запросы от клиента, в которых передается аутентификационная информация в виде [аутентификационного токена](../concepts/glossary.md#auth-token). На ее основании сервер определяет [SID](../concepts/glossary.md#access-sid) клиента и проверяет его доступы на выполнение запроса. {% note info %} @@ -8,18 +8,18 @@ {% endnote %} -Поддерживаются следующие режимы аутентификации: +Поддерживаются следующие виды аутентификации: * [Анонимная](#anonymous) аутентификация. * Аутентификация по [логину и паролю](#static-credentials). -* Аутентификация с использованием [LDAP каталога](#ldap-auth-provider). +* Аутентификация с использованием [LDAP-каталога](#ldap). * [Аутентификация с использованием стороннего IAM-провайдера](#iam), например [Yandex Identity and Access Management](https://yandex.cloud/ru/docs/iam/). ## Анонимная аутентификация {#anonymous} -В данном режиме допускается логин без указания аутентификационных данных, таких как имя пользователя или токен. В этом случае также не производится [авторизация](authorization.md) (проверка прав доступа). +По умолчанию, {{ ydb-short-name }} допускает выполнение запросов без указания аутентификационных данных, таких как имя пользователя или [токен](../concepts/glossary.md#auth-token). Проверка прав доступа ([авторизация](authorization.md)) при этом также не проводится. -Но если будет указан пользователь или токен, то будет работать соответствующий режим аутентификации с последующей авторизацией. +Анонимный запрос не может выполнить в системе действия, требующие [административного уровня доступа](../reference/configuration/index.md#security-access-levels). {% note warning %} @@ -27,7 +27,14 @@ {% endnote %} -За включение анонимной аутентификации отвечает ключ `enforce_user_token_requirement` в [конфигурационном файле](../reference/configuration/index.md#auth) кластера. +За выключение режима анонимной аутентификации отвечает флаг `enforce_user_token_requirement` в [настройках режима аутентификации](../reference/configuration/index.md#security-auth) {{ ydb-short-name }}. + +В зависимости от других настроек режима аутентификации, реальная аутентификация может быть не анонимной: + +- Отсутствующий в запросах токен может подменяться на токен по умолчанию +- Явно указанный в запросах токен может проверяться по надлежащим правилам + +Тогда запросы будут выполняться не анонимно, и будет также выполняться проверка прав. ## Аутентификация по логину и паролю {#static-credentials} @@ -37,7 +44,7 @@ Логин пользователя и хеш пароля хранятся в таблице внутри компонента аутентификации. Пароль хеширован методом [Argon2](https://ru.wikipedia.org/wiki/Argon2). Доступ к этой таблице имеет только администратор системы. -В ответ на логин и пароль возвращается токен. Время жизни токена по умолчанию составляет 12 часов. Для ротации токенов клиент, например, [SDK](../reference/ydb-sdk/index.md), самостоятельно обращается к сервису аутентификации. Использование токена ускоряет процесс аутентификации и повышает безопасность. +В ответ на логин и пароль возвращается [аутентификационный токен](../concepts/glossary.md#auth-token). Время жизни токена по умолчанию составляет 12 часов. Для ротации токенов клиент, например, [SDK](../reference/ydb-sdk/index.md), самостоятельно обращается к сервису аутентификации. Использование токена ускоряет процесс аутентификации и повышает безопасность. Процесс аутентификации по логину и паролю включает следующие шаги: @@ -45,45 +52,21 @@ 1. Сервис проверяет аутентификационные данные, при успешном сопоставлении создаёт токен и возвращает его клиенту. 1. Клиент обращается к БД, передавая в качестве аутентификационной информации токен. -Для включения аутентификации по логину и паролю укажите значение `true` для ключа `enforce_user_token_requirement` в [конфигурационном файле](../reference/configuration/index.md#auth) кластера. +Аутентификация по логину и паролю работает по умолчанию. + +[//]: # (TODO: упомянуть и дать ссылку на auth_config.enable_login_authentication, когда auth_config будет описана) Об управлении ролями и пользователями читайте в [{#T}](../security/authorization.md). -## Взаимодействие с LDAP каталогом {#ldap-auth-provider} +## Аутентификация с использованием LDAP-каталога {#ldap} В {{ ydb-short-name }} интегрировано взаимодействие с [LDAP каталогом](https://ru.wikipedia.org/wiki/LDAP). LDAP каталог является внешним по отношению к {{ ydb-short-name }} сервисом и используется для аутентификации и авторизации пользователей базы данных. Прежде чем воспользоваться данным способом аутентификации и авторизации необходимо иметь развернутый LDAP сервис и настроенный сетевой доступ между ним и серверами {{ ydb-short-name }}. Примеры поддерживаемых реализаций LDAP каталогов: [OpenLdap](https://openldap.org/), [Active Directory](https://azure.microsoft.com/en-us/products/active-directory/). -## Аутентификация с использованием стороннего IAM-провайдера {#iam} - -* **Access Token** — параметром для клиента (SDK или CLI) задается фиксированный токен, который передается в запросы. -* **Refresh Token** — параметром для клиента (SDK или CLI) задается [OAuth токен](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/) персональной учетной записи, на основании которого клиент периодически в фоновом режиме обращается к IAM API для ротации (получения следующего) токена, передаваемого в запросы. -* **Service Account Key** — параметром для клиента (SDK или CLI) задаются атрибуты сервисной учетной записи и ключ для подписи, на основании которых клиент периодически в фоновом режиме обращается к IAM API для ротации (получения следующего) токена, передаваемого в запросы. -* **Metadata** — клиент (SDK или CLI) периодически обращается к локальному сервису для ротации (получения следующего) токена, передаваемого в запросы. -* **OAuth 2.0 token exchange** - клиент (SDK или CLI) обменивает токен другого типа на access token по [протоколу обмена токенов OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8693), который затем передаётся в запросы {{ ydb-short-name }} API. - -Любой обладатель валидного токена может получить доступ на выполнение операций, поэтому главная задача системы безопасности — обеспечение секретности токена и предотвращение его компрометации. - -Режимы аутентификации с ротацией токена **Refresh Token** и **Service Account Key** обеспечивают больший уровень безопасности по сравнению с режимом с фиксированным токеном **Access Token**, так как на сервер {{ ydb-short-name }} по сети передаются только короткоживущие секреты. - -Максимальная безопасность и производительность обеспечивается при использовании режима **Metadata**, так как он исключает необходимость работы с секретами при развертывании приложения, а также позволяет обратиться к IAM и закешировать токен заранее, до запуска приложения. - -При выборе режима аутентификации среди поддерживаемых сервером и окружением, следует руководствоваться следующими рекомендациями: - -* **Anonymous** обычно применяется на самостоятельно разворачиваемых локальных кластерах {{ ydb-short-name }}, недоступных по сети. -* **Access Token** применяется при отсутствии поддержки других режимов на стороне сервера или в настроечных/отладочных целях. Он не требует взаимодействий клиента с IAM. Однако, если IAM поддерживает API для ротации токенов, то обычно выдаваемые таким IAM фиксированные токены имеют короткий срок жизни, что вынуждает регулярно обновлять их в IAM вручную заново. -* **Refresh Token** может применяться при выполнении разовых ручных операций под персональной учетной записью, например, связанных с обслуживанием данных в БД, выполнением ad-hoc операций в CLI, или запусками приложений с рабочей станции. Такой токен можно получить вручную в IAM один раз на долгий срок и сохранить в переменной окружения на личной рабочей станции для автоматического применения при запуске CLI без дополнительных параметров аутентификации. -* **Service Account Key** применяется в первую очередь для приложений, рассчитанных на эксплуатацию в окружениях, где поддерживается режим **Metadata**, при их тестировании вне таких окружений (например, на рабочей станции). Также он может применяться для приложений вне таких окружений, работая как аналог **Refresh Token** для сервисных учетных записей. В отличие от персональной учетной записи, объекты доступа и роли сервисной учетной записи могут быть ограничены. -* **Metadata** применяется при разворачивании приложений в облаках. В настоящее время этот режим поддерживается на виртуальных машинах и в {{ sf-name }} {{ yandex-cloud }}. - -Токен для указания в параметрах может быть получен в системе IAM, с которой связана конкретная установка {{ ydb-short-name }}. В частности, для сервиса {{ ydb-short-name }} в {{ yandex-cloud }} применяется Yandex.Passport OAuth и сервисные аккаунты {{ yandex-cloud }}. При использовании {{ ydb-short-name }} в корпоративных контекстах могут применяться стандартные для данной организации системы централизованной аутентификации. - -При использовании режимов, предусматривающих обращение клиента {{ ydb-short-name }} к IAM, дополнительно может быть задан URL IAM, предоставляющий API выдачи токенов. По умолчанию в существующих SDK и CLI производится попытка обращения к API IAM {{ yandex-cloud }}, размещенному на `iam.api.cloud.yandex.net:443`. - ### Аутентификация -Аутентификация с помощью LDAP протокола похожа на процесс аутентификации по логину и паролю. Отличие заключается лишь в том, что роль компонента аутентификации играет LDAP каталог. LDAP каталог используется только для проверки пары логин/пароль. +Аутентификация с помощью LDAP протокола похожа на процесс аутентификации по логину и паролю. Отличие заключается лишь в том, что роль компонента аутентификации играет LDAP каталог. LDAP каталог используется для проверки пары логин/пароль и для определения групп, к которым принадлежит пользователь. {% note info %} @@ -91,9 +74,9 @@ {% endnote %} -На данный момент {{ ydb-short-name }} поддерживает только один способ LDAP аутентификации, так называемый search+bind метод, состоящий из нескольких шагов. После получения логина и пароля пользователя, которого нужно аутентифицировать, выполняется операция *bind* с заранее определенными в секции [ldap_authentication](../reference/configuration/index.md#ldap-auth-config) учетными данными специального сервисного аккаунта. Учетные данные такого сервисного аккаунта задаются через параметры конфигурации **bind_dn** и **bind_password**. После успешной аутентификации сервисного пользователя от его имени выполняется поиск в LDAP каталоге пользователя, который пытается аутентифицироваться в системе. Операция *search* выполняется для всего поддерева, корень которого берется из параметра конфигурации **base_dn**. Поиск записи в поддереве осуществляется в соответствии с фильтром, задаваемым в параметре конфигурации **search_filter**. После того как запись пользователя была найдена, {{ ydb-short-name }} выполняет повторную операцию *bind* от лица этого найденного пользователя, используя ранее запрошенный пароль. Успех аутентификации пользователя определяется результатом повторной операции *bind*. +На данный момент {{ ydb-short-name }} поддерживает только один способ LDAP аутентификации, так называемый *search+bind* метод, состоящий из нескольких шагов. После получения логина и пароля пользователя, которого нужно аутентифицировать, выполняется операция *bind* с заранее определенными в секции [ldap_authentication](../reference/configuration/index.md#ldap-auth-config) учетными данными специального сервисного аккаунта. Учетные данные такого сервисного аккаунта задаются через параметры конфигурации `bind_dn` и `bind_password`. После успешной аутентификации сервисного пользователя от его имени выполняется поиск в LDAP каталоге пользователя, который пытается аутентифицироваться в системе. Операция *search* выполняется для всего поддерева, корень которого берется из параметра конфигурации `base_dn`. Поиск записи в поддереве осуществляется в соответствии с фильтром, задаваемым в параметре конфигурации `search_filter`. После того как запись пользователя была найдена, {{ ydb-short-name }} выполняет повторную операцию *bind* от лица этого найденного пользователя, используя ранее запрошенный пароль. Успех аутентификации пользователя определяется результатом повторной операции *bind*. -После успешной аутентификации пользователя формируется токен. Далее этот токен используется вместо логина и пароля. Оперирование токеном ускоряет процесс аутентификации и повышает безопасность. +В результате успешной проверки логина и пароля пользователя в LDAP каталоге возвращается [аутентификационный токен](../concepts/glossary.md#auth-token) {{ ydb-short-name }}. Далее этот токен используется вместо логина и пароля. Оперирование токеном ускоряет процесс аутентификации и повышает безопасность. {% note info %} @@ -107,15 +90,15 @@ Группы, как и сам пользователь, являются субъектами выполнения операций над объектами схемы базы данных. Для разграничения доступа к различным ресурсам базы данных субъектам могут назначаться права доступа. И в соответствии со списком назначенных прав субъекты будут авторизованы на выполнение тех или иных операций. -Процесс получения списка групп пользователя из LDAP каталога похож на те действия, которые выполняются при аутентификации. Сначала выполняется операция *bind* для сервисного пользователя, учетные данные которого записаны в параметрах **bind_dn** и **bind_password** секции [ldap_authentication](../reference/configuration/index.md#ldap-auth-config) файла конфигурации. После успешной аутентификации выполняется поиск записи пользователя, для которого был ранее сформирован токен. Поиск также выполняется в соответствии с параметром **search_filter**. Если пользователь всё ещё существует, то в качестве возвращаемого результата операции *search* будет список значений атрибута, записанного в параметре **requested_group_attribute**. В случае, если этот параметр пуст, то аттрибутом обратного членства в группе будет являться *memberOf*. Атрибут *memberOf* хранит уникальные имена (Distinguished Name, DN) групп, в которых состоит пользователь. +Процесс получения списка групп пользователя из LDAP каталога похож на те действия, которые выполняются при аутентификации. Сначала выполняется операция *bind* для сервисного пользователя, учетные данные которого записаны в параметрах `bind_dn` и `bind_password` секции [ldap_authentication](../reference/configuration/index.md#ldap-auth-config) файла конфигурации. После успешной аутентификации выполняется поиск записи пользователя, для которого был ранее сформирован токен. Поиск также выполняется в соответствии с параметром `search_filter`. Если пользователь всё ещё существует, то в качестве возвращаемого результата операции *search* будет список значений атрибута, записанного в параметре `requested_group_attribute`. В случае, если этот параметр пуст, то аттрибутом обратного членства в группе будет являться `memberOf`. Атрибут `memberOf` хранит уникальные имена (Distinguished Name, DN) групп, в которых состоит пользователь. #### Получение групп -По умолчанию {{ ydb-short-name }} выполняет поиск только тех групп, в которых пользователь состоит непосредственно. С помощью включения флага **extended_settings.enable_nested_groups_search** секции [ldap_authentication](../reference/configuration/index.md#ldap-auth-config) {{ ydb-short-name }} будет пытаться получить группы на всех уровнях вложенности, а не только те, в которые пользователь входит напрямую. Если {{ ydb-short-name }} настроен для работы с Active Directory, для поиска всех вложенных групп будет использовано специфичное для Active Directory правило соответствия [LDAP_MATCHING_RULE_IN_CHAIN](https://learn.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax?redirectedfrom=MSDN). Это правило позволяет получить все вложенные группы одним запросом. Для LDAP-серверов на основе OpenLDAP поиск групп будет выполнен рекурсивным обходом графа, что в общем случае требует выполнения нескольких запросов. Как для Active Directory, так и для OpenLDAP поиск групп будет выполнен только для поддерева, корень которого берётся из параметра конфигурации **base_dn**. +По умолчанию {{ ydb-short-name }} выполняет поиск только тех групп, в которых пользователь состоит непосредственно. С помощью включения флага `extended_settings.enable_nested_groups_search` секции [ldap_authentication](../reference/configuration/index.md#ldap-auth-config) {{ ydb-short-name }} будет пытаться получить группы на всех уровнях вложенности, а не только те, в которые пользователь входит напрямую. Если {{ ydb-short-name }} настроен для работы с Active Directory, для поиска всех вложенных групп будет использовано специфичное для Active Directory правило соответствия [LDAP_MATCHING_RULE_IN_CHAIN](https://learn.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax?redirectedfrom=MSDN). Это правило позволяет получить все вложенные группы одним запросом. Для LDAP-серверов на основе OpenLDAP поиск групп будет выполнен рекурсивным обходом графа, что в общем случае требует выполнения нескольких запросов. Как для Active Directory, так и для OpenLDAP поиск групп будет выполнен только для поддерева, корень которого берётся из параметра конфигурации `base_dn`. {% note info %} -В текущей реализации имена групп, которыми будет оперировать {{ ydb-short-name }}, совпадают с теми значениями, которые записаны в атрибуте *memberOf*. Они могут иметь большую длину и быть сложночитаемыми. +В текущей реализации имена групп, которыми будет оперировать {{ ydb-short-name }}, совпадают с теми значениями, которые записаны в атрибуте `memberOf`. Они могут иметь большую длину и быть сложночитаемыми. Пример: @@ -127,7 +110,7 @@ cn=Developers,ou=Groups,dc=mycompany,dc=net@ldap {% note info %} -В секции конфигурационного файла, описывающего аутентификационную информацию, можно настроить частоту обновления информации о пользователе и его группах. Этот показатель регулируется параметром **refresh_time**. Подробную информацию о файлах конфигурации можно узнать в разделе о [конфигурировании кластера](../reference/configuration/index.md#auth-config). +В секции конфигурационного файла, описывающего аутентификационную информацию, можно настроить частоту обновления информации о пользователе и его группах. Этот показатель регулируется параметром `refresh_time`. Подробную информацию о файлах конфигурации можно узнать в разделе о [конфигурировании кластера](../reference/configuration/index.md#auth-config). {% endnote %} @@ -137,11 +120,11 @@ cn=Developers,ou=Groups,dc=mycompany,dc=net@ldap {% endnote %} -### LDAP пользователи и группы в {{ ydb-short-name }} +### LDAP-пользователи и LDAP-группы в {{ ydb-short-name }} -Так как {{ ydb-short-name }} позволяет использовать различные способы аутентификации пользователя (аутентификация по логину и паролю, использование IAM провайдера, LDAP каталог), то, оперируя именами пользователей и групп, часто бывает полезно различать, где именно аутентифицировался пользователь. Для всех видов аутентификации, кроме аутентификации по логину и паролю, имена групп и пользователей дополняются суффиксом вида `<имя_пользователя>@`. +Так как {{ ydb-short-name }} позволяет использовать разные способы аутентификации пользователя, то, оперируя именами пользователей и групп, часто бывает полезно различать, где именно аутентифицировался пользователь. Для всех видов аутентификации, кроме аутентификации по логину и паролю, имена групп и пользователей дополняются суффиксом вида `@`. -Для LDAP пользователей *domain* задается в [параметре конфигурации](../reference/configuration/index.md#ldap-auth-config) **ldap_authentication_domain**. По умолчанию имеет значение `ldap`, поэтому все имена пользователей, аутентифицированных с помощью LDAP каталога, и имена групп, в которых они состоят, в {{ ydb-short-name }} будут иметь следующий вид: +Для LDAP пользователей *auth-domain* задается в [параметре конфигурации](../reference/configuration/index.md#ldap-auth-config) `ldap_authentication_domain`. По умолчанию имеет значение `ldap`, поэтому все имена пользователей, аутентифицированных с помощью LDAP каталога, и имена групп, в которых они состоят, в {{ ydb-short-name }} будут иметь следующий вид: - `user1@ldap` - `group1@ldap` @@ -149,7 +132,7 @@ cn=Developers,ou=Groups,dc=mycompany,dc=net@ldap {% note warning %} -Чтобы различать, что введенный логин должен быть логином пользователя из LDAP каталога, а не логином для аутентификации по логину и паролю, к нему нужно добавлять суффикс домена LDAP-аутентификации. Суффикс задается через параметр конфигурации **ldap_authentication_domain**. +Чтобы различать, что введенный логин должен быть логином пользователя из LDAP каталога, а не логином локального пользователя {{ ydb-short-name }}, к нему нужно добавлять суффикс `@ldap`. Ниже приведены примеры аутентификации пользователя `user1` используя [{{ ydb-short-name }} CLI](../reference/ydb-cli/index.md): @@ -174,3 +157,30 @@ cn=Developers,ou=Groups,dc=mycompany,dc=net@ldap #### Расширение LDAP протокола `StartTls` {#starttls} `StartTls` — это расширение протокола LDAP, используемое для шифрования сообщений по протоколу TLS. Оно позволяет передавать в рамках одного соединения с LDAP-сервером одни сообщения в зашифрованном виде, а другие — открыто. Сообщение с этим расширением отправляется от {{ ydb-short-name }} к LDAP-серверу для инициирования TLS-соединения. В случае {{ ydb-short-name }} не предусмотрено включение и выключение TLS-соединения в рамках одного соединения. Поэтому при использовании расширения `StartTls` после установления зашифрованного соединения {{ ydb-short-name }} будет отправлять все дальнейшие сообщения к LDAP-серверу в зашифрованном виде. Одним из преимуществ использования данного расширения вместо схемы `ldaps` (при соответствующей настройке LDAP-сервера) является возможность установить TLS-соединение на нешифрованном порту. Расширение включается в [секции `use_tls`](../reference/configuration/index.md#ldap-auth-config) файла конфигурации. + + +## Аутентификация с использованием стороннего IAM-провайдера {#iam} + +* **Access Token** — параметром для клиента (SDK или CLI) задается фиксированный токен, который передается в запросы. +* **Refresh Token** — параметром для клиента (SDK или CLI) задается [OAuth токен](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/) персональной учетной записи, на основании которого клиент периодически в фоновом режиме обращается к IAM API для ротации (получения следующего) токена, передаваемого в запросы. +* **Service Account Key** — параметром для клиента (SDK или CLI) задаются атрибуты сервисной учетной записи и ключ для подписи, на основании которых клиент периодически в фоновом режиме обращается к IAM API для ротации (получения следующего) токена, передаваемого в запросы. +* **Metadata** — клиент (SDK или CLI) периодически обращается к локальному сервису для ротации (получения следующего) токена, передаваемого в запросы. +* **OAuth 2.0 token exchange** - клиент (SDK или CLI) обменивает токен другого типа на access token по [протоколу обмена токенов OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8693), который затем передаётся в запросы {{ ydb-short-name }} API. + +Любой обладатель валидного токена может получить доступ на выполнение операций, поэтому главная задача системы безопасности — обеспечение секретности токена и предотвращение его компрометации. + +Режимы аутентификации с ротацией токена **Refresh Token** и **Service Account Key** обеспечивают больший уровень безопасности по сравнению с режимом с фиксированным токеном **Access Token**, так как на сервер {{ ydb-short-name }} по сети передаются только короткоживущие секреты. + +Максимальная безопасность и производительность обеспечивается при использовании режима **Metadata**, так как он исключает необходимость работы с секретами при развертывании приложения, а также позволяет обратиться к IAM и закешировать токен заранее, до запуска приложения. + +При выборе режима аутентификации среди поддерживаемых сервером и окружением, следует руководствоваться следующими рекомендациями: + +* **Anonymous** обычно применяется на самостоятельно разворачиваемых локальных кластерах {{ ydb-short-name }}, недоступных по сети. +* **Access Token** применяется при отсутствии поддержки других режимов на стороне сервера или в настроечных/отладочных целях. Он не требует взаимодействий клиента с IAM. Однако, если IAM поддерживает API для ротации токенов, то обычно выдаваемые таким IAM фиксированные токены имеют короткий срок жизни, что вынуждает регулярно обновлять их в IAM вручную заново. +* **Refresh Token** может применяться при выполнении разовых ручных операций под персональной учетной записью, например, связанных с обслуживанием данных в БД, выполнением ad-hoc операций в CLI, или запусками приложений с рабочей станции. Такой токен можно получить вручную в IAM один раз на долгий срок и сохранить в переменной окружения на личной рабочей станции для автоматического применения при запуске CLI без дополнительных параметров аутентификации. +* **Service Account Key** применяется в первую очередь для приложений, рассчитанных на эксплуатацию в окружениях, где поддерживается режим **Metadata**, при их тестировании вне таких окружений (например, на рабочей станции). Также он может применяться для приложений вне таких окружений, работая как аналог **Refresh Token** для сервисных учетных записей. В отличие от персональной учетной записи, объекты доступа и роли сервисной учетной записи могут быть ограничены. +* **Metadata** применяется при разворачивании приложений в облаках. В настоящее время этот режим поддерживается на виртуальных машинах и в {{ sf-name }} {{ yandex-cloud }}. + +Токен для указания в параметрах может быть получен в системе IAM, с которой связана конкретная установка {{ ydb-short-name }}. В частности, для сервиса {{ ydb-short-name }} в {{ yandex-cloud }} применяется Yandex.Passport OAuth и сервисные аккаунты {{ yandex-cloud }}. При использовании {{ ydb-short-name }} в корпоративных контекстах могут применяться стандартные для данной организации системы централизованной аутентификации. + +При использовании режимов, предусматривающих обращение клиента {{ ydb-short-name }} к IAM, дополнительно может быть задан URL IAM, предоставляющий API выдачи токенов. По умолчанию в существующих SDK и CLI производится попытка обращения к API IAM {{ yandex-cloud }}, размещенному на `iam.api.cloud.yandex.net:443`. diff --git a/ydb/docs/ru/core/security/authorization.md b/ydb/docs/ru/core/security/authorization.md index 504d7b42a42f..7b81c5adb7a7 100644 --- a/ydb/docs/ru/core/security/authorization.md +++ b/ydb/docs/ru/core/security/authorization.md @@ -7,7 +7,7 @@ * [Объект доступа](../concepts/glossary.md#access-object) * [Субъект доступа](../concepts/glossary.md#access-subject) * [Право доступа](../concepts/glossary.md#access-right) -* [Список разрешений](../concepts/glossary.md#access-acl) +* [Список доступов](../concepts/glossary.md#access-acl) * [Владелец](../concepts/glossary.md#access-owner) * [Пользователь](../concepts/glossary.md#access-user) * [Группа](../concepts/glossary.md#access-group) @@ -35,13 +35,14 @@ * [Ansible](../devops/ansible/initial-deployment.md) * [Kubernetes](../devops/kubernetes/initial-deployment.md) * [Вручную](../devops/manual/initial-deployment.md) +* [{#T}](./builtin-security.md) {% endnote %} {{ ydb-short-name }} позволяет работать с [пользователями](../concepts/glossary.md#access-user) из разных каталогов и систем, и они отличаются [SID](../concepts/glossary.md#access-sid) с использованием суффикса. -Суффикс `@` идентифицирует «источник пользователя» или «auth-домен», внутри которых гарантируется уникальность всех `login`. Например, в случае [аутентификации LDAP](authentication.md#ldap-auth-provider) имена пользователей будут `user1@ldap` и `user2@ldap`. -Если указан `login` без суффикса, то имеются в виду пользователи, непосредственно созданные в кластере {{ ydb-short-name }}. +Суффикс `@` идентифицирует «источник пользователя», внутри которого гарантируется уникальность всех логинов или идентификаторов пользователей. Например, в случае [аутентификации LDAP](authentication.md#ldap-auth-provider) имена пользователей будут `user1@ldap` и `user2@ldap`.
+Если имя пользователя указано без суффикса, то имеется в виду локальный пользователь, созданный и существующий непосредственно в кластере {{ ydb-short-name }}. ## Группа {#group} @@ -64,9 +65,9 @@ ## Право {#right} -[Права](../concepts/glossary.md#access-right) в {{ ydb-short-name }} привязаны не [субъекту](../concepts/glossary.md#access-subject), а к [объекту доступа](../concepts/glossary.md#access-object). +[Права доступа](../concepts/glossary.md#access-right) в {{ ydb-short-name }} привязаны не [субъекту](../concepts/glossary.md#access-subject), а к [объекту доступа](../concepts/glossary.md#access-object). -У каждого объекта доступа есть список разрешений — [ACL](../concepts/glossary.md#access-acl) (Access Control List) — он хранит все предоставленные [субъектам доступа](../concepts/glossary.md#subject) (пользователям и группам) права на объект. +У каждого объекта доступа есть список прав — [ACL](../concepts/glossary.md#access-acl) (Access Control List) — он хранит все предоставленные [субъектам доступа](../concepts/glossary.md#subject) (пользователям и группам) права на объект. По умолчанию, права наследуются от родителей потомкам по дереву объектов доступа. @@ -96,7 +97,7 @@ {% note info %} -Для владельца не проверяются [списки разрешений](../concepts/glossary.md#access-control-list) на данный [объект доступа](../concepts/glossary.md#access-object). +Для владельца не проверяются [списки прав](../concepts/glossary.md#access-control-list) на данный [объект доступа](../concepts/glossary.md#access-object). Он имеет полный набор прав на объект. diff --git a/ydb/docs/ru/core/security/builtin-security.md b/ydb/docs/ru/core/security/builtin-security.md new file mode 100644 index 000000000000..430822c7dea8 --- /dev/null +++ b/ydb/docs/ru/core/security/builtin-security.md @@ -0,0 +1,54 @@ +# Встроенная настройка безопасности + +Встроенная настройка безопасности выполняется автоматически при первом запуске кластера {{ ydb-short-name }}, если секция настроек безопасности в конфигурации кластера ([секция `security_config`](../reference/configuration/index.md#security)) не содержит явных настроек `default_users`, `default_groups`, `default_access`. + +Применение встроенной конфигурации безопасности выключается по [флагу `domains_config.disable_builtin_security`](../reference/configuration/index.md#domains-config). + +Встроенная настройка безопасности добавляет в систему суперпользователя, а также реализует набор ролей безопасности для удобного управления пользователями. + +## Роли + +Роль | Описание +--- | --- +`ADMINS` | Неограниченные права на всю схему кластера. +`DATABASE-ADMINS` | Права на управление базами, схемой и доступами на схеме, без доступа к данным. +`ACCESS-ADMINS` | Права на управление доступами на схеме, без доступа к данным. +`DDL-ADMINS` | Права на управление схемой, без доступа к данным. +`DATA-WRITERS` | Права на доступ к схемным объектам, и на чтение и изменение данных. +`DATA-READERS` | Права на доступ к схемным объектам, и на чтение данных. +`METADATA-READERS` | Права на доступ к схемным объектам, без доступа к данным. +`USERS` | Права на доступ к базам, общая группа всех пользователей. + +## Группы + +Роли реализуются с помощью иерархии [пользовательских](../concepts/glossary.md#access-user) [групп](./authorization.md#group) и необходимых наборов [прав](./authorization.md#right) для этих групп. Возможности групп задаются с помощью прав, выданных на корне схемы кластера. + +Группы включаются друг в друга и таким образом по цепочке наследуют соответствующие разрешения: + +{% include notitle [builtin-groups-graph](../_includes/builtin-groups-graph.md) %} + +Например, пользователям группы `DATA-WRITERS` разрешено: + +- смотреть схему — `METADATA-READERS`; +- читать данные — `DATA-READERS`; +- и менять их — `DATA-WRITERS`. + +Пользователям группы `DDL-ADMINS` разрешено: + +- смотреть схему — `METADATA-READERS`; +- и менять ёё — `DDL-ADMINS`. + +Пользователи группы `ADMINS` со схемой и данными могут делать всё. + +## Суперпользователь + +Суперпользователь входит в группы `ADMINS` и `USERS` и обладает полными правами на схему кластера. + +По умолчанию суперпользователь называется `root` и имеет пустой пароль. + +## Группа всех пользователей + +Группа `USERS` также определяется как общая [группа](../concepts/glossary.md#access-group) всех локальных [пользователей](../concepts/glossary.md#access-user). При последующем [создании локальных пользователей](./authorization.md#user) они будут автоматически становиться членами группы `USERS`. + + +Об управлении группами и пользователями читайте в разделе [{#T}](../security/authorization.md). diff --git a/ydb/docs/ru/core/security/index.md b/ydb/docs/ru/core/security/index.md index 1026268e9b7b..9d3851d0601b 100644 --- a/ydb/docs/ru/core/security/index.md +++ b/ydb/docs/ru/core/security/index.md @@ -6,6 +6,7 @@ - [{#T}](authentication.md) - [{#T}](authorization.md) +- [{#T}](builtin-security.md) - [{#T}](audit-log.md) - Шифрование: diff --git a/ydb/docs/ru/core/security/toc_p.yaml b/ydb/docs/ru/core/security/toc_p.yaml index adc1a854600c..de2af6df02d6 100644 --- a/ydb/docs/ru/core/security/toc_p.yaml +++ b/ydb/docs/ru/core/security/toc_p.yaml @@ -3,6 +3,8 @@ items: href: authentication.md - name: Авторизация href: authorization.md +- name: Встроенная настройка безопасности + href: builtin-security.md - name: Аудитный лог href: audit-log.md - name: Шифрование diff --git a/ydb/docs/ru/core/yql/reference/yql-core/syntax/_assets/builtin_groups.svg b/ydb/docs/ru/core/yql/reference/yql-core/syntax/_assets/builtin_groups.svg deleted file mode 100644 index cb8c96f20719..000000000000 --- a/ydb/docs/ru/core/yql/reference/yql-core/syntax/_assets/builtin_groups.svg +++ /dev/null @@ -1,3 +0,0 @@ - - -
ADMINS
ADMINS
DATABASE-ADMINS
DATABASE-ADMINS
ACCESS-ADMINS
ACCESS-ADMINS
DDL-ADMINS
DDL-ADMINS
DATA-WRITERS
DATA-WRITERS
DATA-READERS
DATA-READERS
METADATA-READERS
METADATA-READERS
USERS
USERSViewer does not support full SVG 1.1 \ No newline at end of file diff --git a/ydb/docs/ru/core/yql/reference/yql-core/syntax/_includes/builtin_groups.md b/ydb/docs/ru/core/yql/reference/yql-core/syntax/_includes/builtin_groups.md deleted file mode 100644 index e1c98b6ebccf..000000000000 --- a/ydb/docs/ru/core/yql/reference/yql-core/syntax/_includes/builtin_groups.md +++ /dev/null @@ -1,20 +0,0 @@ -## Встроенные группы {#builtin} - -Кластер {{ ydb-short-name }} имеет встроенные группы, предоставляющие заранее определенные наборы ролей: - -Группа | Описание ---- | --- -`ADMINS` | Неограниченные права на всю схему кластера -`DATABASE-ADMINS` | Права на создание и удаление баз данных (`CreateDatabase`, `DropDatabase`) -`ACCESS-ADMINS` | Права на управление правами других пользователей (`GrantAccessRights`) -`DDL-ADMINS` | Права на изменение схемы баз данных (`CreateDirectory`, `CreateTable`, `WriteAttributes`, `AlterSchema`, `RemoveSchema`) -`DATA-WRITERS` | Права на изменение данных (`UpdateRow`, `EraseRow`) -`DATA-READERS` | Права на чтение данных (`SelectRow`) -`METADATA-READERS` | Права на чтение метаинформации, без доступа к данным (`DescribeSchema` и `ReadAttributes`) -`USERS` | Права на подключение к базам данных (`ConnectDatabase`) - -Все пользователи по умолчанию входят в группу `USERS`. Пользователь `root` по умолчанию входит в группу `ADMINS`. - -Ниже показано, как группы наследуют разрешения друг друга. Например, в `DATA-WRITERS` входят все разрешения `DATA-READERS`: - -![builtin_groups](../_assets/builtin_groups.svg) diff --git a/ydb/docs/ru/core/yql/reference/yql-core/syntax/_includes/initial_groups_and_users.md b/ydb/docs/ru/core/yql/reference/yql-core/syntax/_includes/initial_groups_and_users.md new file mode 100644 index 000000000000..3145e0ee9250 --- /dev/null +++ b/ydb/docs/ru/core/yql/reference/yql-core/syntax/_includes/initial_groups_and_users.md @@ -0,0 +1,5 @@ +{{ ydb-short-name }} может иметь набор групп и пользователей уже с момента начального развёртывания. + +Подробнее см. [{#T}](../../../../reference/configuration/index.md#security-bootstrap) и [{#T}](../../../../security/builtin-security.md). + +Такие пользователи и группы ничем не отличаются от пользователей и групп, созданных позже. diff --git a/ydb/docs/ru/core/yql/reference/yql-core/syntax/alter-group.md b/ydb/docs/ru/core/yql/reference/yql-core/syntax/alter-group.md index e5c92a61610c..84b067d74d6e 100644 --- a/ydb/docs/ru/core/yql/reference/yql-core/syntax/alter-group.md +++ b/ydb/docs/ru/core/yql/reference/yql-core/syntax/alter-group.md @@ -12,4 +12,6 @@ ALTER GROUP role_name DROP USER user_name [, ... ] * `role_name` — имя группы. * `user_name` — имя пользователя. -{% include [x](_includes/builtin_groups.md) %} +## Встроенные группы + +{% include [!](_includes/initial_groups_and_users.md) %} diff --git a/ydb/docs/ru/core/yql/reference/yql-core/syntax/alter-user.md b/ydb/docs/ru/core/yql/reference/yql-core/syntax/alter-user.md index 2c61075b2757..10e846b4fcf0 100644 --- a/ydb/docs/ru/core/yql/reference/yql-core/syntax/alter-user.md +++ b/ydb/docs/ru/core/yql/reference/yql-core/syntax/alter-user.md @@ -15,3 +15,7 @@ ALTER USER user_name [ WITH ] option [ ... ] * `PASSWORD NULL` — устанавливает пустой пароль. * `NOLOGIN` - запрет на логин пользователя (блокировка пользователя). * `LOGIN` - разрешение на логин пользователя (разблокировка пользователя). + +## Встроенные пользователи + +{% include [!](_includes/initial_groups_and_users.md) %} diff --git a/ydb/docs/ru/core/yql/reference/yql-core/syntax/create-group.md b/ydb/docs/ru/core/yql/reference/yql-core/syntax/create-group.md index c0c86aa2375b..b2b55f7abc95 100644 --- a/ydb/docs/ru/core/yql/reference/yql-core/syntax/create-group.md +++ b/ydb/docs/ru/core/yql/reference/yql-core/syntax/create-group.md @@ -9,3 +9,7 @@ CREATE GROUP group_name ``` * `group_name` — имя группы. Может содержать строчные буквы латинского алфавита и цифры. + +## Встроенные группы + +{% include [!](_includes/initial_groups_and_users.md) %} diff --git a/ydb/docs/ru/core/yql/reference/yql-core/syntax/create-user.md b/ydb/docs/ru/core/yql/reference/yql-core/syntax/create-user.md index 1d61bb2b06b1..7faa39fced1d 100644 --- a/ydb/docs/ru/core/yql/reference/yql-core/syntax/create-user.md +++ b/ydb/docs/ru/core/yql/reference/yql-core/syntax/create-user.md @@ -11,8 +11,12 @@ CREATE USER user_name [option] * `user_name` — имя пользователя. Может содержать строчные буквы латинского алфавита и цифры. * `option` — опция команды: * `PASSWORD 'password'` — создает пользователя с паролем `password`. - * `PASSWORD NULL` — создает пользователя с пустым паролем (по умолчанию). + * `PASSWORD NULL` — создает пользователя с пустым паролем (по умолчанию). * `NOLOGIN` - запрет на логин пользователя (блокировка пользователя). * `LOGIN` - разрешение на логин пользователя (по умолчанию). {% include [!](../../../_includes/do-not-create-users-in-ldap.md) %} + +## Встроенные пользователи + +{% include [!](_includes/initial_groups_and_users.md) %} diff --git a/ydb/docs/ru/core/yql/reference/yql-core/syntax/drop-group.md b/ydb/docs/ru/core/yql/reference/yql-core/syntax/drop-group.md index d27f6230e082..ceb745e92901 100644 --- a/ydb/docs/ru/core/yql/reference/yql-core/syntax/drop-group.md +++ b/ydb/docs/ru/core/yql/reference/yql-core/syntax/drop-group.md @@ -10,3 +10,7 @@ DROP GROUP [ IF EXISTS ] group_name [, ...] * `IF EXISTS` — не выводить ошибку, если группа не существует. * `group_name` — имя группы, которого нужно удалить. + +## Встроенные группы + +{% include [!](_includes/initial_groups_and_users.md) %} diff --git a/ydb/docs/ru/core/yql/reference/yql-core/syntax/drop-user.md b/ydb/docs/ru/core/yql/reference/yql-core/syntax/drop-user.md index b6e814361c22..ce15db9828a0 100644 --- a/ydb/docs/ru/core/yql/reference/yql-core/syntax/drop-user.md +++ b/ydb/docs/ru/core/yql/reference/yql-core/syntax/drop-user.md @@ -10,3 +10,7 @@ DROP USER [ IF EXISTS ] user_name [, ...] * `IF EXISTS` — не выводить ошибку, если пользователь не существует. * `user_name` — имя удаляемого пользователя. Поддерживается возможность задать список пользователей через запятую, например: `DROP USER user1, user2, user3;`. + +## Встроенные пользователи + +{% include [!](_includes/initial_groups_and_users.md) %}