security_config

В разделе security_config файла конфигурации YDB задаются режимы аутентификации, первичная конфигурация локальных пользователей и групп и их права.

security_config:
  # настройка режима аутентификации
  enforce_user_token_requirement: false
  enforce_user_token_check_requirement: false
  default_user_sids: <SID для анонимных запросов>
  all_authenticated_users: <имя группы всех аутентифицированных пользователей>
  all_users_group: <имя группы всех пользователей>

  # первичные настройки безопасности
  default_users: <список пользователей по умолчанию>
  default_groups: <список групп по умолчанию>
  default_access: <список прав по умолчанию на корне кластера>

  # настройки списков доступа
  database_allowed_sids: <список SID'ов, которым разрешён просмотр состояния базы данных>
  viewer_allowed_sids: <список SID'ов с правами просмотра состояния кластера>
  monitoring_allowed_sids: <список SID'ов с правами мониторинга и изменения состояния кластера>
  administration_allowed_sids: <список SID'ов с правами администрирования кластера>
  bootstrap_allowed_sids: <список SID'ов, которым разрешена начальная инициализация кластера>
  register_dynamic_node_allowed_sids: <список SID'ов с правами регистрации узлов баз данных в кластере>

  # настройки встроенной настройки безопасности
  disable_builtin_security: false
  disable_builtin_groups: false
  disable_builtin_access: false

  # настройки сокрытия ошибок доступа
  hide_authentication_failure_reasons: true

Настройки режима аутентификации

Параметр	Описание
`enforce_user_token_requirement`	Режим обязательной аутентификации. Возможные значения: `true` — аутентификация обязательна, запросы к YDB обязаны сопровождаться аутентификационным токеном. Запросы проходят аутентификацию и проверку прав. `false` — аутентификация опциональна, запросы к YDB могут не сопровождаться аутентификационным токеном. Запросы без токена выполняются в анонимном режиме и без проверки прав. Запросы с токеном проходят аутентификацию и проверку прав. Но в случае ошибок аутентификации, запросы не запрещаются, а выполняются в анонимном режиме. При `enforce_user_token_check_requirement: true` выполнение запросов с ошибкой аутентификации запрещается. Взамен отсутствующего в запросах токена используется значение параметра `default_user_sids`, если параметр определён и не пустой (см. описание ниже). Тогда аутентификация и проверка прав проводится для субъекта доступа, заданного `default_user_sids`. Значение по умолчанию: `false`.
`enforce_user_token_check_requirement`	Запрещает игнорировать ошибки аутентификации в режиме `enforce_user_token_requirement: false`. Значение по умолчанию: `false`.
`default_user_sids`	Список SID'ов для использования в процессе аутентификации в случае, когда входящий запрос не сопровождается явным аутентификационным токеном. `default_user_sids` используется для анонимных запросов. Первым элементом в списке должен быть SID пользователя, за ним должны идти SID'ы групп, к которым пользователь принадлежит. Непустой `default_user_sids` позволяет использовать режим обязательной аутентификации (`enforce_user_token_requirement: true`) вместе с анонимными запросами. Это может быть полезно в определённых сценариях тестирования YDB или в ознакомительных целях для локальных баз данных. Значение по умолчанию: пустой список.
`all_authenticated_users`	Имя виртуальной группы, в которой состоят все аутентифицированные пользователи. Виртуальную группу не нужно явно создавать, она ведётся системой автоматически. Виртуальную группу нельзя удалить, нельзя получить или изменить список её членов. Пользователь может использовать её для выдачи прав на схемных объектах. Совет Информацию о правах доступа к схемным объектам можно получить из системных представлений YDB, см. {#T}. Значение по умолчанию: `all-users@well-known`.
`all_users_group`	Имя группы, в которую должны добавляться все внутренние пользователи. Если `all_users_group` не пустая, то все локальные пользователи в момент создания будут добавляться в группу с указанным именем. В момент создания пользователей группа, указанная в этом параметре, должна существовать. `all_users_group` автоматически конфигурируется при выполнении встроенной настройки безопасности. Значение по умолчанию: пустая строка.

Следующая диаграмма показывает как взаимодействуют параметры настройки режима аутентификации:

Первичные настройки безопасности

Параметры default_users, default_groups, default_access влияют на настройку кластера, осуществляемую при первом старте YDB. При последующих запусках первичная настройка не выполняется, эти параметры игнорируются.

См. также раздел по встроенной настройке безопасности и влияющие на неё настройки уровня domains_config.

Параметр	Описание
`default_users`	Какие пользователи должны быть созданы на кластере при первом запуске. Список пар логин-пароль. Первый пользователь становится суперпользователем. Примечание Пароли задаются в открытом виде и оставлять их действующими на долгое время небезопасно. Поэтому после первого запуска кластера и его настройки рекомендуется пароли стартовым пользователям поменять средствами YDB (например, `ALTER USER`). Пример: `default_users: - name: root password: <...> - name: user1 password: <...>` Ошибки в списке (повторение логинов) фиксируются в логе, но не влияют на запуск кластера.
`default_groups`	Какие группы должны быть созданы на кластере при первом запуске. Список групп и их членов. Важно Эти группы создаются для всего кластера YDB. Пример: `default_groups: - name: ADMINS members: root - name: USERS members: - ADMINS - root - user1` Порядок перечисления групп важен: группы создаются в порядке перечисления, и указанные члены группы к моменту создания группы должны существовать, иначе они не будут добавлены в группу. Ошибки добавления членов групп фиксируются в логе, но не влияют на запуск кластера.
`default_access`	Какие права должны быть выданы на корне кластера. Список разрешений в формате краткой записи управления доступом. Пример: `default_access: - +(CDB\|DDB\|GAR):ADMINS - +(ConnDB):USERS`

Ошибки в строках прав доступа фиксируются в логе, но не влияют на запуск кластера. Право доступа с ошибкой не будет добавлено.

Настройки административных и других привилегий

Списки уровней доступа настраиваются в секции security_config. Подробная информация о списках уровней доступа, их иерархии и принципах работы приведена в разделе Списки уровней доступа документации по авторизации.

Параметр	Описание
`database_allowed_sids`	Список SID'ов с уровнем доступа database. Этот уровень менее привилегирован, чем viewer. Субъекты с таким уровнем могут работать только в контексте конкретной базы данных — backend-вызовы без указания базы запрещены. Запросы уровня кластера (например, получение списка узлов кластера) возвращают 403. Запросы в контексте базы данных (например, страницы базы в Embedded UI) работают штатно. Предназначен для приложений или пользователей, ограниченных одной базой данных.
`viewer_allowed_sids`	Список SID'ов с уровнем доступа viewer. Даёт возможность просматривать состояние кластера, недоступное публично (включая большую часть страниц Embedded UI), без возможности вносить изменения.
`monitoring_allowed_sids`	Список SID'ов с уровнем доступа monitoring. Даёт дополнительные привилегии для мониторинга и изменения состояния кластера. Например, позволяет выполнять резервное копирование, восстановление базы данных или запускать YQL-запросы через Embedded UI.
`administration_allowed_sids`	Список SID'ов с уровнем доступа administration. Даёт привилегии для администрирования кластера YDB и его баз данных. Также используется для изменения конфигурации, схемных операций, требующих административных прав, и других административных проверок. Пустой список означает, что любой пользователь считается администратором.
`bootstrap_allowed_sids`	Список SID'ов, которым разрешено выполнять начальную инициализацию кластера. Используется для первоначальной инициализации кластера из неинициализированного состояния, когда подсистема аутентификации ещё не функционирует. Начальная инициализация разрешена, если субъект входит в `bootstrap_allowed_sids` или `administration_allowed_sids`. `bootstrap_allowed_sids` позволяет выделить отдельные идентичности для начальной инициализации без выдачи им полных административных привилегий.
`register_dynamic_node_allowed_sids`	Список SID'ов, которым разрешена регистрация узлов баз данных. По техническим причинам этот список должен включать `root@builtin`.

Важно

По умолчанию списки уровней доступа пусты.

Пустой список означает «разрешить любому пользователю»: подходит любой SID, а если разрешён анонимный доступ — даже отсутствие SID. Пустой administration_allowed_sids даёт любому пользователю права администратора; пустой viewer_allowed_sids (если остальные UI-списки тоже пусты) даёт любому пользователю viewer-доступ к Embedded UI. Если все четыре иерархических списка пусты, любой пользователь получает полный административный доступ.

Для защищённого развёртывания YDB важно заранее спланировать модель доступа и определить списки групп до первого запуска кластера.

Списки уровней доступа могут содержать SID пользователей или групп. Субъект соответствует списку, если в нём присутствует его пользовательский SID или любой SID одной из его групп, включая вложенные группы — достаточно одного совпадения.

Рекомендуется включать в списки уровней доступа *_allowed_sids группы пользователей и отдельные сервисные аккаунты. Тогда выдача уровней доступа отдельным пользователям не потребует изменения конфигурации кластера YDB.

Где используются списки:

database_allowed_sids, viewer_allowed_sids, monitoring_allowed_sids, administration_allowed_sids
Для доступа к Embedded UI и viewer HTTP endpoints.
administration_allowed_sids
Для всех административных проверок.
bootstrap_allowed_sids
Только для операции начальной инициализации кластера.
register_dynamic_node_allowed_sids
Для регистрации узлов в кластере (discovery service и подсистема cms).

Примечание

Списки уровней доступа представляют собой слои дополнительных привилегий:

Субъект доступа, не включённый ни в один список уровней доступа, может просматривать только публично доступную информацию о кластере (например, список баз данных в кластере или список узлов кластера).
Список database_allowed_sids определяет роль «database»: такие пользователи менее привилегированы, чем viewers, и не могут выполнять backend-вызовы без указания базы данных; общекластерные запросы для них недоступны.
Списки viewer_allowed_sids, monitoring_allowed_sids и administration_allowed_sids образуют иерархию: administration включает monitoring и viewer, а monitoring включает viewer. Субъекту достаточно находиться только в одном списке, соответствующем его роли — включение в более высокий список автоматически даёт все более низкие привилегии.

Например:

пользователя базы данных (например, приложение, которое должно работать только в рамках одной базы) следует добавлять только в database_allowed_sids;
наблюдателя следует добавлять только в viewer_allowed_sids;
пользователя с уровнем monitoring следует добавлять только в monitoring_allowed_sids (он автоматически получает viewer-привилегии);
администратора следует добавлять только в administration_allowed_sids (он автоматически получает monitoring- и viewer-привилегии).

Настройки встроенной настройки безопасности

Флаги disable_builtin_security, disable_builtin_groups, disable_builtin_access влияют на настройку кластера, осуществляемую только при первом старте кластера YDB.

Параметр	Описание
`disable_builtin_security`	Не выполнять встроенную настройку безопасности. Встроенная настройка включает автоматическое создание суперпользователя `root`, набора встроенных пользовательских групп и выдачу прав доступа этим группам на корне кластера. Эфемерный флаг, не попадает в конфигурацию, сохраняемую в кластере. Значение по умолчанию: `false`.
`disable_builtin_groups`	Отказаться от создания встроенных групп, даже если явные группы по умолчанию (`security_config.default_groups`) заданы. Значение по умолчанию: `false`
`disable_builtin_access`	Отказаться от добавления прав на корне кластера для встроенных групп, даже если явные права по умолчанию (`security_config.default_access`) заданы. Значение по умолчанию: `false`

Настройки сокрытия ошибок доступа

Параметр

Описание

hide_authentication_failure_reasons

Скрывает от пользователя причины ошибок аутентификации.

Позволяет предотвратить утечку информации о внутреннем устройстве и содержимом систем аутентификации YDB.
Например, усложняет для злоумышленника задачу выявления существующих пользователей методом перебора.

Значение по умолчанию: true.

Была ли статья полезна?

resource_broker_config

system_tablet_backup_config