Создание ролей Postgres

При создании проекта Lakebase создает несколько ролей Postgres в проекте:

  • Роль Postgres для удостоверения владельца проекта Azure Databricks (например, user@databricks.comкоторый владеет базой данных по умолчанию databricks_postgres )
  • Административная databricks_superuser роль

Обе эти роли отображаются на вкладке "Роли и базы данных " при первом открытии проекта.

База databricks_postgres данных создается, чтобы подключиться и попробовать Lakebase сразу после создания проекта.

Также создаются несколько системно управляемых ролей. Это внутренние роли, используемые службами Azure Databricks для управления, мониторинга и операций с данными.

Замечание

Роли Postgres управляют доступом к базе данных (кто может запрашивать данные). Разрешения проекта (которые могут управлять инфраструктурой), см. в разделе "Разрешения проекта". Руководство по настройке обоих элементов см. в руководстве. Предоставление доступа к проекту и базе данных новому пользователю.

См. статью "Предварительно созданные роли " и "Системные роли".

Создание ролей Postgres

Lakebase поддерживает два типа ролей Postgres для доступа к базе данных:

  • Роли OAuth для удостоверений Azure Databricks: Создайте их с помощью интерфейса Lakebase, расширения databricks_auth с использованием SQL, или SDK для Python и REST API. Позволяет удостоверениям Azure Databricks (пользователям, субъектам-службам и группам) подключаться с использованием токенов OAuth.
  • Собственные роли паролей Postgres: Создайте их с помощью пользовательского интерфейса Lakebase, SQL или пакета SDK для Python и REST API. Используйте любое допустимое имя роли с проверкой подлинности паролем.

Рекомендации по выбору типа используемой роли см. в обзоре проверки подлинности. Каждая из них предназначена для различных вариантов использования.

Создайте роль OAuth для идентификаторов Azure Databricks

Чтобы разрешить пользователям, главным представлениям или группам Azure Databricks подключаться, используя токены OAuth, создайте роль для OAuth через пользовательский интерфейс Lakebase, расширение databricks_auth с SQL или API REST.

Подробные инструкции по получению маркеров OAuth см. в статье "Получение маркера OAuth" в потоке "пользователь — компьютер " и получение маркера OAuth в потоке "компьютер — компьютер".

Пользовательский интерфейс

  1. На вкладке "Роли и базы данных>" добавьте роль>OAuth , выберите пользователя, субъекта-службы или группу, чтобы предоставить доступ к базе данных.
  2. После создания роли предоставьте соответствующие привилегии базы данных. Узнайте, как управлять разрешениями

Добавление роли — вкладка OAuth

SQL

Необходимые условия:

  • Для базы данных необходимы права CREATE и CREATE ROLE.
  • Необходимо пройти проверку подлинности, используя учетную запись Azure Databricks с действительным маркером OAuth.
  • Собственные сеансы Postgres, прошедшие проверку подлинности, не могут создавать роли OAuth

  1. Создайте расширение databricks_auth. Каждая база данных Postgres должна иметь собственное расширение.

    CREATE EXTENSION IF NOT EXISTS databricks_auth;

  2. Используйте эту функцию databricks_create_role для создания роли Postgres для идентичности Azure Databricks:

    SELECT databricks_create_role('identity_name', 'identity_type');

    Для пользователя Azure Databricks:

    SELECT databricks_create_role('myuser@databricks.com', 'USER');

    Для учетной записи службы Azure Databricks:

    SELECT databricks_create_role('8c01cfb1-62c9-4a09-88a8-e195f4b01b08', 'SERVICE_PRINCIPAL');

    Для группы Azure Databricks:

    SELECT databricks_create_role('My Group Name', 'GROUP');

    Имя группы учитывает регистр и должно точно соответствовать тому, как оно отображается в рабочей области Azure Databricks. При создании роли Postgres для группы любой прямой или косвенный член (пользователь или сервисный принципал) этой группы Databricks может выполнить аутентификацию в Postgres в качестве ролевой группы, используя индивидуальный токен OAuth. Эта модель разрешений на уровне группы позволяет управлять разрешениями в Postgres, а не поддерживать разрешения для отдельных пользователей.

  3. Предоставьте новой роли разрешения на базы данных.

Функция databricks_create_role() создает роль Postgres только с LOGIN разрешениями. После создания роли необходимо предоставить соответствующие привилегии и разрешения базы данных для определенных баз данных, схем или таблиц, к которым пользователь должен получить доступ. Узнайте, как управлять разрешениями

пакет SDK Python

Установите identity_type, USER, SERVICE_PRINCIPAL, или GROUP. Установите postgres_role в адрес электронной почты, идентификатор приложения (UUID) или отображаемое имя группы соответственно. Это значение становится именем роли Postgres и используется в строках подключения и GRANT командах.

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.postgres import Role, RoleIdentityType, RoleRoleSpec

w = WorkspaceClient()

operation = w.postgres.create_role(
    parent="projects/my-project/branches/production",
    role=Role(
        spec=RoleRoleSpec(
            identity_type=RoleIdentityType.USER,
            postgres_role="user@example.com"
        )
    )
)
role = operation.wait()
print(f"Created role: {role.name}")

После создания роли предоставьте соответствующие привилегии базы данных. Узнайте, как управлять разрешениями

интерфейс командной строки (CLI)

Установите identity_type, USER, SERVICE_PRINCIPAL, или GROUP. Установите postgres_role в адрес электронной почты, идентификатор приложения (UUID) или отображаемое имя группы соответственно. Это значение становится именем роли Postgres и используется в строках подключения и GRANT командах.

Для пользователя Azure Databricks:

databricks postgres create-role projects/my-project/branches/production \
  --role-id my-user-role \
  --json '{"spec": {"identity_type": "USER", "postgres_role": "user@example.com"}}'

Для учетной записи службы Azure Databricks:

databricks postgres create-role projects/my-project/branches/production \
  --role-id my-sp-role \
  --json '{"spec": {"identity_type": "SERVICE_PRINCIPAL", "postgres_role": "8c01cfb1-62c9-4a09-88a8-e195f4b01b08"}}'

Для группы Azure Databricks:

databricks postgres create-role projects/my-project/branches/production \
  --role-id my-group-role \
  --json '{"spec": {"identity_type": "GROUP", "postgres_role": "My Group Name"}}'

Команда ожидает завершения операции и возвращает созданную роль. Используйте --no-wait для немедленного возврата, а для опроса по отдельности - databricks postgres get-operation.

После создания роли предоставьте соответствующие привилегии базы данных. Узнайте, как управлять разрешениями

завиток

Установите identity_type, USER, SERVICE_PRINCIPAL, или GROUP. Установите postgres_role в адрес электронной почты, идентификатор приложения (UUID) или отображаемое имя группы соответственно. Это значение становится именем роли Postgres и используется в строках подключения и GRANT командах.

curl -X POST "$WORKSPACE/api/2.0/postgres/projects/my-project/branches/production/roles" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "spec": {
      "identity_type": "USER",
      "postgres_role": "user@example.com"
    }
  }' | jq

Конечная точка возвращает долгосрочную операцию. Продолжайте опрашивать до тех пор, пока done не станет true, затем используйте поле name роли для последующих вызовов API. См. долговременные операции.

После создания роли предоставьте соответствующие привилегии базы данных. Узнайте, как управлять разрешениями

Проверка подлинности на основе групп

При создании роли Postgres для группы Azure Databricks можно включить проверку подлинности на основе групп. Это позволяет любому участнику группы Azure Databricks пройти проверку подлинности в Postgres с помощью роли группы, упрощая управление разрешениями.

Принцип работы.

  1. Создайте роль Postgres для группы Azure Databricks.
  2. Предоставьте разрешения базы данных групповой роли в PostgreSQL. См. раздел "Управление разрешениями".
  3. Любой прямой или косвенный член (пользователь или субъект-служба) группы Azure Databricks может подключаться к Postgres с помощью отдельного маркера OAuth.
  4. При подключении член проходит проверку подлинности в качестве роли группы и наследует все разрешения, предоставленные этой роли.

Поток проверки подлинности:

Когда член группы подключается, он указывает в качестве имени пользователя роль Postgres группы и свой токен OAuth в качестве пароля.

export PGPASSWORD='<OAuth token of a group member>'
export GROUP_ROLE_NAME='<pg-case-sensitive-group-role-name>'

psql -h $HOSTNAME -p 5432 -d databricks_postgres -U $GROUP_ROLE_NAME

Важные вопросы:

  • Проверка членства в группах: Членство в группах проверяется только во время проверки подлинности. Если член удаляется из группы Azure Databricks после установления подключения, подключение остается активным. Новые попытки подключения от удаленных членов отклоняются.
  • Область рабочей области: Для проверки подлинности на основе групп поддерживаются только группы, назначенные той же рабочей области Azure Databricks, что и проект. Сведения о назначении групп рабочей области см. в статье "Управление группами".
  • Конфиденциальность регистра: Имя группы, используемое в databricks_create_role() , должно соответствовать имени группы точно так же, как оно отображается в рабочей области Azure Databricks, включая регистр.
  • Управление разрешениями: Управление разрешениями на уровне группы в Postgres эффективнее, чем управление отдельными разрешениями пользователей. При предоставлении разрешений роли группы все текущие и будущие члены группы автоматически наследуют эти разрешения.
  • Переименование идентификации: Если отображаемое имя электронной почты или группы пользователя изменяется в Azure Databricks, аутентификация и существующие права в базе данных нарушаются. Удалите старую роль, создайте новую роль с обновленным именем и обновите строки подключения и разрешения.

Замечание

Имена ролей не могут превышать 63 символов, и некоторые имена не допускаются. Дополнительные сведения: управление ролями

Создание нативной роли пароля Postgres

Подключения к паролям можно отключить на уровне проекта или вычислений. См. раздел "Блокировать подключения к паролям".

Пользовательский интерфейс

  1. На вкладке Роли и базы данных>, Добавить роль>, Пароль, введите имя роли и, при необходимости, назначьте databricks_superuser или системные атрибуты (CREATEDB, CREATEROLE, BYPASSRLS).
  2. Скопируйте созданный пароль и предоставьте его пользователю безопасно. Оно больше не показывается.

Добавление роли — вкладка

SQL

CREATE ROLE role_name WITH LOGIN PASSWORD 'your_secure_password';

Пароль должен содержать не менее 12 символов с сочетанием строчных, прописных, цифр и символов. Определяемые пользователем пароли проверяются во время создания, чтобы проверить 60-разрядную энтропию.

пакет SDK Python

Пропустите identity_type, чтобы создать роль пароля. Операция возвращает Role объект без поля пароляcreate_role. SDK не возвращает сгенерированный пароль. Чтобы получить пригодный пароль, см. раздел «Как получить пароль».

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.postgres import Role, RoleRoleSpec

w = WorkspaceClient()

operation = w.postgres.create_role(
    parent="projects/my-project/branches/production",
    role=Role(
        spec=RoleRoleSpec(
            postgres_role="my-app-role"
        )
    )
)
role = operation.wait()
print(f"Created role: {role.name}")

интерфейс командной строки (CLI)

Пропустите identity_type, чтобы создать роль пароля. Команда возвращает Role объект без поля пароля. CLI не возвращает сгенерированный пароль. Чтобы получить пригодный пароль, см. раздел «Как получить пароль».

databricks postgres create-role projects/my-project/branches/production \
  --role-id my-app-role \
  --json '{"spec": {"postgres_role": "my-app-role"}}'

Команда ожидает завершения операции и возвращает созданную роль.

завиток

Пропустите identity_type, чтобы создать роль пароля. Конечная точка возвращает долгосрочную операцию. Повторяйте опрос, пока done не равен true. Результатом операции является Role объект без поля пароля. API не возвращает сгенерированный пароль. Чтобы получить пригодный пароль, см. раздел «Как получить пароль».

curl -X POST "$WORKSPACE/api/2.0/postgres/projects/my-project/branches/production/roles" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "spec": {
      "postgres_role": "my-app-role"
    }
  }' | jq

Замечание

Собственные роли паролей Postgres поддерживают встроенный пул подключений. См. раздел "Использование пула подключений".

Как получить пароль

Операции создания ролей Python SDK, REST API и CLI не возвращают сгенерированный пароль. Используйте один из следующих методов для получения пароля для нативной роли пароля Postgres:

  • Установите свой пароль при создании с помощью SQL: Запускайте CREATE ROLE role_name WITH LOGIN PASSWORD 'your_secure_password'; через OAuth SQL соединение. Для этого нужна привилегия CREATEROLE . См. вкладку SQL в разделе «Создать роль с собственным паролем Postgres».
  • Сброс пароля в интерфейсе пользователя: Для роли, созданной с помощью Python SDK, REST API, CLI или Terraform, используйте процесс Reset password в приложении Lakebase, чтобы создать новый пароль. См. Сброс пароля.

Замечание

Роли, созданные с помощью Python SDK, REST API или Terraform, принадлежат внутренней роли управляющей плоскости. Принципалы клиентов не могут изменять пароли этих ролей с помощью SQL, поскольку в Postgres 16 для изменения пароля роли требуется, чтобы для этой роли была указана опция ADMIN. Используйте вместо этого процедуру Сброс пароля в интерфейсе.

Как хранятся роли встроенного пароля

Каким бы способом вы ни создали собственную роль Postgres с паролем, её пароль никогда не хранится в открытом виде. Ядро Postgres вычислительного узла хранит серверный верификатор SCRAM-SHA-256 (вычислительный параметр по умолчанию — password_encryption = scram-sha-256). Когда Lakebase генерирует пароль за вас (через UI, Python SDK, REST API и CLI), плоскость управления также сохраняет копию учетных данных, зашифрованную с помощью KMS, что позволяет пользовательскому интерфейсу позже отображать пароль или сбрасывать его. Пароли, установленные через SQL, не сохраняются таким образом: хранится только верификатор.

  • UI: Azure Databricks генерирует пароль на сервере, вычисляет верификатор и отображает сгенерированный пароль один раз. Тогда скопируйте это, потому что оно больше не будет показано.
  • Python SDK, REST API и CLI: Azure Databricks генерирует пароль на серверной стороне и вычисляет верификатор, но не возвращает пароль в ответе. Чтобы получить рабочий пароль, используйте SQL во время создания или функцию Сбросить пароль в интерфейсе. Посмотрите, как получить пароль. Эти пути не принимают пароль, который вы предоставляете.
  • SQL: когда вы запускаете CREATE ROLE role_name WITH LOGIN PASSWORD 'your_secure_password'; (или psql в \password), вы предоставляете открытый текст, а сервер хеширует его в верификатор.

Вам никогда не нужно хэшировать пароль самостоятельно.

Просмотр ролей Postgres

Пользовательский интерфейс

Чтобы просмотреть все роли Postgres в проекте, перейдите на вкладку " Роли и базы данных " ветви в приложении Lakebase. Перечислены все роли, созданные в ветви, за исключением системных ролей. Столбец типа проверки подлинности указывает, использует ли каждая роль проверку подлинности OAuth или пароль.

Список ролей

PostgreSQL

Просмотрите все роли с \du помощью команды:

Вы можете просмотреть все роли Postgres, включая системные роли, с помощью \du метакоманд из любого клиента Postgres (например psql) или редактора SQL Lakebase:

\du
                                      List of roles
          Role name          |                         Attributes
-----------------------------+------------------------------------------------------------
 cloud_admin                 | Superuser, Create role, Create DB, Replication, Bypass RLS
 my.user@databricks.com      | Create role, Create DB, Bypass RLS
 databricks_control_plane    | Superuser
 databricks_gateway          |
 databricks_monitor          |
 databricks_reader_12345     | Create role, Create DB, Replication, Bypass RLS
 databricks_replicator       | Replication
 databricks_superuser        | Create role, Create DB, Cannot login, Bypass RLS
 databricks_writer_12345     | Create role, Create DB, Replication, Bypass RLS

пакет SDK Python

Список всех ролей:

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

roles = w.postgres.list_roles(parent="projects/my-project/branches/production")
for role in roles:
    print(f"{role.status.postgres_role} ({role.status.identity_type or 'PASSWORD'}): {role.name}")

Получите определенную роль:

role = w.postgres.get_role(
    name="projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx"
)
print(role)

интерфейс командной строки (CLI)

Список всех ролей:

databricks postgres list-roles projects/my-project/branches/production

Получите определенную роль:

databricks postgres get-role projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx

Выходные данные включают поле name (например, rol-xxxx-xxxxxxxxxx), необходимое для вызовов обновления и удаления.

завиток

Список всех ролей:

curl -X GET "$WORKSPACE/api/2.0/postgres/projects/my-project/branches/production/roles" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" | jq

Получите определенную роль:

curl -X GET "$WORKSPACE/api/2.0/postgres/projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" | jq

Ответ включает name поле (например, rol-xxxx-xxxxxxxxxxобязательное для вызовов обновления и удаления).

Обновление роли

Чтобы обновить атрибуты роли в пользовательском интерфейсе, выберите "Изменить роль " в меню ролей на вкладке " Роли и базы данных ".

Используйте API или CLI для обновления системных ролей или атрибутов роли. Только поля, указанные в маске обновления, изменяются.

Замечание

Чтобы получить имя ресурса роли для использования в вызовах обновления и удаления, используйте конечную точку списка ролей. Имена ресурсов роли используют системный идентификатор (например, rol-xxxx-xxxxxxxxxx), а не значение postgres_role, предоставленное при создании.

интерфейс командной строки (CLI)

Обновите роль, используя шаблон маски обновления. Маска обновления — это второй позиционный аргумент после имени ресурса.

При обновлении spec.attributesнеобходимо указать все три поля атрибутов (createdb, createrole, bypassrls) — API заменяет весь объект атрибутов:

databricks postgres update-role \
  projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx \
  "spec.attributes" \
  --json '{
    "spec": {
      "attributes": {"createdb": true, "createrole": false, "bypassrls": false}
    }
  }'

Чтобы также обновить роли членства, добавьте spec.membership_roles в маску обновления:

databricks postgres update-role \
  projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx \
  "spec.membership_roles" \
  --json '{"spec": {"membership_roles": ["DATABRICKS_SUPERUSER"]}}'

Чтобы удалитьdatabricks_superuser, передайте пустой массив: "membership_roles": []

завиток

curl -X PATCH "$WORKSPACE/api/2.0/postgres/projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx?update_mask=spec.membership_roles%2Cspec.attributes.createdb" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx",
    "spec": {
      "membership_roles": ["DATABRICKS_SUPERUSER"],
      "attributes": { "createdb": true }
    }
  }' | jq

Чтобы удалитьdatabricks_superuser, передайте пустой массив: "membership_roles": []

Удаление роли Postgres

Можно удалить как роли в Azure Databricks, основанные на удостоверениях, так и встроенные роли с паролями в Postgres.

Пользовательский интерфейс

  1. Перейдите на вкладку «Роли и базы данных» ветви в приложении Lakebase.

  2. Щелкните меню для роли, которую вы хотите удалить, и выберите "Удалить".

  3. В диалоговом окне подтверждения дополнительно включите переназначение объектов.

    Роль Postgres нельзя удалить, если она владеет объектами базы данных, такими как таблицы, представления или схемы. При включении появляется раскрывающийся список Переназначить владельца. Выберите роль, чтобы получить владение объектами перед удалением. Объекты, которые не могут быть переназначены, например права, предоставленные удаляемой роли, автоматически удаляются после завершения переназначения. Если параметр отключен, удаление завершается ошибкой, если роль владеет какими-либо объектами.

  4. Нажмите кнопку "Подтвердить".

Удаление роли — необратимое действие, его нельзя отменить.

PostgreSQL

Вы можете удалить любую роль Postgres с помощью стандартных команд Postgres. Дополнительные сведения см. в документации postgreSQL по удалению ролей.

Удаление роли:

DROP ROLE role_name;

После удаления роли, основанной на удостоверениях Azure Databricks, это удостоверение больше не сможет аутентифицироваться в Postgres с помощью токенов OAuth до создания новой роли.

интерфейс командной строки (CLI)

databricks postgres delete-role \
  projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx

Если роль владеет объектами базы данных, используйте --reassign-owned-to для передачи владения другой роли перед удалением:

databricks postgres delete-role \
  projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx \
  --reassign-owned-to projects/my-project/branches/production/roles/rol-yyyy-yyyyyyyyyy

пакет SDK Python

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

operation = w.postgres.delete_role(
    name="projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx"
)
operation.wait()

завиток

curl -X DELETE "$WORKSPACE/api/2.0/postgres/projects/my-project/branches/production/roles/rol-xxxx-xxxxxxxxxx" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" | jq

Предварительно созданные роли

После создания проекта Azure Databricks автоматически создает роли Postgres для администрирования проекта и начала работы.

Role Description Унаследованные привилегии
<project_owner_role> Удостоверение создателя проекта Azure Databricks (например, my.user@databricks.com). Эта роль имеет права на базу данных по умолчанию databricks_postgres и может войти в систему и администрировать проект. Член databricks_superuser
databricks_superuser Внутренняя административная роль. Используется для настройки и управления доступом в проекте. Эта роль предоставляет широкие привилегии. Наследует от pg_read_all_data, pg_write_all_dataи pg_monitor.

Дополнительные сведения о конкретных возможностях и привилегиях этих ролей: предварительно созданные возможности ролей

Системные роли, созданные Azure Databricks

Azure Databricks создает следующие системные роли, необходимые для внутренних служб. Эти роли можно просмотреть, выполнив команду \du из psql или редактора SQL Lakebase.

Role Цель
cloud_admin Роль суперпользователя, используемая для управления облачной инфраструктурой
databricks_control_plane Роль суперпользователя, используемая внутренними компонентами Databricks для операций управления
databricks_monitor Используется службами сбора внутренних метрик
databricks_replicator Используется для операций репликации базы данных
databricks_writer_<dbid> Роль для каждой базы данных, используемая для создания синхронизированных таблиц и управления ими
databricks_reader_<dbid> Роль для каждой базы данных, используемая для чтения таблиц, зарегистрированных в каталоге Unity
databricks_gateway Используется для внутренних соединений в услугах управления потоками данных

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

Дополнительные ресурсы

  • Last updated on