Настройка аутентификации и авторизации узлов баз данных

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

Прежде чем динамический узел базы данных войдёт в состав кластера и начнёт обмен с другими узлами по внутреннему протоколу Interconnect, он должен зарегистрироваться у уже работающих узлов хранения. Для этого запускаемый узел устанавливает gRPC-соединение с одним из узлов хранения, указанных в опции --node-broker, и по этому соединению выполняет служебные вызовы — в том числе запрос на регистрацию. Именно такие gRPC-вызовы и защищаются аутентификацией и авторизацией узлов: без успешной проверки узел не получает право зарегистрироваться и не может войти в кластер.

Что нужно знать перед тем как начать

Идентификаторы узлов:

  • NodeId — уникальный числовой идентификатор узла в кластере (от 1 до 1048575).
  • SID (Subject IDentifier) — уникальный идентификатор субъекта доступа, определяющий, какие операции может выполнять узел (например, registerNode@cert означает «узел с правом регистрации»).

Цель аутентификации. Убедиться, что новый узел БД - это авторизованный узел. Для этого используются сертификаты.

Как проходит проверка узла

  1. Запускаемый узел базы данных открывает gRPC-подключение к одному из узлов хранения, указанных в опции --node-broker. Подключение выполняется по TLS, а в качестве клиентского сертификата используется сертификат запускаемого узла, заданный в опции --grpc-cert.

  2. Узел хранения и узел базы данных выполняют mTLS : каждый узел проверяет сертификат другого. Проверяется цепочка доверия (сертификат подписан известным центром сертификации) и соответствие имени хоста значению поля "Subject Name" сертификата.

  3. Узел хранения проверяет поле "Subject" сертификата на соответствие требованиям, заданным в статической конфигурации в секции client_certificate_authorization. Таким образом узел хранения убеждается, что сертификат издан именно для узлов вашего кластера. Например, вы можете требовать, чтобы все сертификаты узлов имели организацию (O) = "MyCompany", что затруднит подделку сертификата злоумышленникам.

  4. Если все проверки успешны (сертификат подлинный, цепочка доверия в порядке, поле Subject соответствует требованиям), узел хранения доверяет подключению и присваивает ему идентификатор субъекта доступа (SID) — строку типа registerNode@cert, указанную в конфигурации в параметре member_groups. SID определяет, какие операции может выполнять узел (в данном случае — регистрироваться в кластере).

  5. Узел базы данных использует доверенное gRPC-подключение, чтобы «представиться» узлу хранения. Узел БД посылает служебный запрос, в котором передаёт IP-адрес и порт, по которому будут принимать соединения от других узлов кластера. Узел хранения запоминает полученную информацию — это и называется регистрацией в кластере.

  6. Узел хранения проверяет: имеет ли SID, присвоенный подключению на этапе mTLS, право на регистрацию узлов. Для этого узел хранения смотрит на параметр конфигурации register_dynamic_node_allowed_sids — это список SID, которым разрешена регистрация новых узлов БД в кластере. Если SID узла (например, registerNode@cert) содержится в этом списке — регистрация разрешена. Если нет — узел отвергается как неавторизованный.

    После успешной проверки узел хранения выполняет три действия:

    • Присваивает узлу БД уникальный числовой идентификатор — NodeId (например, NodeId=50001).
    • Записывает соответствие: NodeId=50001 → IP-адрес 192.168.1.100:19002 в служебный реестр узлов кластера.
    • Этот реестр используется другими узлами кластера для маршрутизации (куда направить запрос узлу с NodeId=50001).

  7. Теперь узел БД готов к полноценной работе в кластере. Узел БД подключается к другим узлам в кластере через служебный протокол Interconnect и передаёт свой назначенный NodeId (например, 50001) и свой сетевой адрес (host:port). Другие узлы кластера используют эту информацию для маршрутизации запросов. Если какой-то узел попытается подключиться с неизвестным NodeId или IP-адресом (которого нет в реестре), другие узлы его отвергают.

Режим аутентификации узлов при регистрации задаётся параметром node_registration_token в секции auth_config. По умолчанию аутентификация выключена. Такой режим допустим только в полностью изолированных тестовых окружениях.

Настройка аутентификации и авторизации узлов баз данных

Чтобы включить аутентификацию и авторизацию узлов, перед изменением конфигурации кластера необходимо подготовить инфраструктуру сертификатов и настроить запуск узлов с использованием TLS-сертификатов.

  1. Убедитесь, что в развернутом кластере YDB настроено шифрование gRPC-трафика с использованием TLS.

  2. При выпуске сертификатов для узлов задайте единые правила заполнения поля "Subject", чтобы можно было отличать сертификаты узлов кластера. Подробности — в документации по правилам проверки сертификатов.

    Примечание

    Пример скрипта генерации самоподписанных сертификатов для узлов YDB заполняет поле "Subject" значением O=YDB для всех узлов. Примеры в этой статье рассчитаны именно на такой вариант заполнения поля "Subject".

  3. В параметры командной строки для запуска узлов баз данных добавьте опции с путями к сертификатам и ключу:

    Опция командной строки Описание
    --grpc-ca Путь к файлу сертификатов доверенных центров сертификации ca.crt.
    --grpc-cert Путь к файлу сертификата узла node.crt.
    --grpc-key Путь к файлу секретного ключа узла node.key.

    Пример запуска узла базы данных:

    /opt/ydb/bin/ydbd server --yaml-config  /opt/ydb/cfg/config.yaml --tenant /Root/testdb \
    --grpcs-port 2136 --grpc-ca /opt/ydb/certs/ca.crt \
    --grpc-cert /opt/ydb/certs/node.crt --grpc-key /opt/ydb/certs/node.key \
    --ic-port 19002 --ca /opt/ydb/certs/ca.crt \
    --mon-port 8766 --mon-cert /opt/ydb/certs/web.pem \
    --node-broker grpcs://<ydb1>:2135 \
    --node-broker grpcs://<ydb2>:2135 \
    --node-broker grpcs://<ydb3>:2135

Включение режима аутентификации и авторизации узлов

Чтобы включить обязательную авторизацию узлов баз данных, обновите статическую конфигурацию кластера:

  1. На корневом уровне добавьте блок client_certificate_authorization с требованиями к полю "Subject" сертификатов подключаемых узлов.

    client_certificate_authorization:
  request_client_certificate: true
  client_certificate_definitions:
    - member_groups: ["registerNode@cert"]
      subject_terms:
        - short_name: "O"
          values: ["YDB"]

    При необходимости добавьте дополнительные проверки сертификатов согласно документации по client_certificate_authorization.

    В случае успешной проверки сертификата и соответствия компонентов его поля "Subject" требованиям, заданным в subject_terms, подключению будут присвоены субъекты доступа (SID), перечисленные в member_groups. Чтобы отделять такие субъекты от других групп и учётных записей, необходимо их именовать с добавлением суффикса @cert.

  2. В блоке security_config добавьте параметр register_dynamic_node_allowed_sids со списком SID, которым разрешена регистрация узлов баз данных. Пример:

    domains_config:
  ...
  security_config:
    enforce_user_token_requirement: true
    ...
    register_dynamic_node_allowed_sids:
      - "root@builtin"
      - "registerNode@cert"

    Включение root@builtin в этот список обязательно по техническим причинам: некоторые внутренние процессы кластера используют его независимо от режима аутентификации узлов.

    Подробности о параметрах аутентификации кластера см. в документации по security_config.

  3. В блоке auth_config присвойте параметру node_registration_token пустую строку:

    auth_config:
  ...
  node_registration_token: ""

    Подробности о параметре node_registration_token см. в документации по auth_config.

  4. Обновите статическую конфигурацию на всех узлах кластера вручную или через плейбук Ansible.

  5. Выполните поэтапный перезапуск узлов хранения с помощью ydbops или через плейбук Ansible.

  6. Выполните поэтапный перезапуск узлов баз данных кластера с помощью ydbops или плейбука Ansible.

Предыдущая
SelfHeal подсистем распространения метаданных
Следующая
Управление конфигурацией кластера