Поделиться через

Настройка политики федерации

Федерация токенов OAuth Databricks позволяет безопасно обращаться к API Databricks с помощью токенов от поставщика удостоверений (IdP). Чтобы включить федерацию токенов OAuth, необходимо настроить политику федерации, применяемую ко всему аккаунту Databricks или к рабочим нагрузкам.

На этой странице описывается создание и настройка политики федерации маркеров OAuth.

Федерация удостоверений рабочей нагрузки

Федерация удостоверений рабочих нагрузок позволяет автоматизированным рабочим нагрузкам, выполняемым за пределами Azure Databricks, получать доступ к API Azure Databricks без использования секретов Azure Databricks. Администраторы учетных записей могут настроить федерацию рабочих удостоверений с помощью политики федерации служебного принципала.

Политика федерации служебного принципала связана со служебным принципалом в учетной записи Azure Databricks и определяет:

  • Поставщик удостоверений (или издатель), посредством которого учетная запись службы может пройти проверку подлинности.
  • Удостоверение задания (или субъект), которому разрешено пройти проверку подлинности как учетная запись службы Azure Databricks.

Например, учитывая следующую политику федерации субъекта-службы для рабочей нагрузки Github Actions:

  • Эмитент:https://token.actions.githubusercontent.com
  • Аудитории:https://github.com/my-github-org
  • Тема:repo:my-github-org/my-repo:environment:prod

Этот текст JWT можно использовать для проверки подлинности для Azure Databricks:

{
  "iss": "https://token.actions.githubusercontent.com",
  "aud": "https://github.com/my-github-org",
  "sub": "repo:my-github-org/my-repo:environment:prod"
}

Настройка политики федерации субъекта-службы

Администраторы учетных записей могут настроить политику федерации субъекта службы с помощью интерфейса командной строки Databricks (CLI) или Databricks API. Вы можете создать не более 20 политик федерации для учетной записи службы в Azure Databricks.

Чтобы настроить политику федерации субъекта-службы, необходимо указать следующее:

  • URL-адрес издателя: URL-адрес HTTPS, определяющий поставщика удостоверений рабочей нагрузки, указанный в iss утверждении маркеров удостоверения рабочей нагрузки.

  • Тема: Уникальный идентификатор рабочей нагрузки в среде выполнения рабочей нагрузки. Если не указано, значение по умолчанию равно sub.

  • Аудитории: Предполагаемый получатель токена, указанный в требовании aud . Токен считается совпадением, если его аудитория соответствует по крайней мере одной аудитории в правиле. Если не указано, по умолчанию используется идентификатор учетной записи Azure Databricks.

  • Утверждение субъекта: (необязательно) Указывает утверждение токена, содержащее идентичность рабочей нагрузки (также называемое субъектом) токена. Если параметр не задан, Azure Databricks использует sub по умолчанию. Databricks рекомендует сохранить утверждение по умолчанию sub для федерации удостоверений рабочей нагрузки. Выберите только другое утверждение, если sub не является подходящим или стабильным идентификатором субъекта, что редко. Дополнительные сведения см. в разделе Политики федерации служебного субъекта — примеры.

  • Проверка подписи токена: (необязательно) Открытые ключи или их URL-адрес в формате JSON наборов веб-ключей (JWKS), используемые для проверки подписей токенов. JWKS JSON поддерживает до 5 ключей. Если поставщик удостоверений публикует больше информации, в этом случае используйте URI JWKS.

    Если значение не указано, Azure Databricks извлекает ключи из известной конечной точки издателя, что является рекомендуемым подходом. Поставщик удостоверений должен предоставлять метаданные поставщика OpenID на <issuer-url>/.well-known/openid-configuration, которые включают элемент jwks_uri, указывающий расположение открытых ключей, используемых для проверки подписей токенов.

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

  1. Как администратор учетной записи, войдите в консоль учетной записи Azure Databricks по адресу https://accounts.azuredatabricks.net.
  2. Щелкните "Управление пользователями".
  3. Перейдите на вкладку Субъекты-службы.
  4. Выберите учетную запись службы, для которой нужно создать политику.
  5. Перейдите на вкладку "Учетные данные и секреты ".
  6. На вкладке "Политики федерации" нажмите кнопку "Создать политику".
  7. Выберите федеративный поставщик учетных данных и настройте соответствующие поля.
  8. Нажмите кнопку "Создать политику".

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

Вы не можете использовать интерфейс командной строки Databricks в веб-терминале рабочей области Azure Databricks для создания политики федерации.

  1. Установите или обновите последнюю версию интерфейса командной строки Databricks.

  2. В качестве администратора учетной записи выполните проверку подлинности в учетной записи Azure Databricks с помощью интерфейса командной строки. Укажите ACCOUNT_CONSOLE_URL и Azure Databricks ACCOUNT_ID:

    databricks auth login --host ${ACCOUNT_CONSOLE_URL} --account-id ${ACCOUNT_ID}

  3. Получите числовой идентификатор субъекта-службы, к которому будет применена политика федерации. (Например, 3659993829438643.)

    Если вы знаете идентификатор приложения субъекта-службы (обычно значение GUID, например bc3cfe6c-469e-4130-b425-5384c4aa30bb) заранее, можно определить числовые идентификаторы субъекта-службы с помощью интерфейса командной строки Databricks:

    databricks account service-principals list --filter 'applicationId eq "<service-principal-application-id>"'

  4. Создайте политику федерации субъекта-службы. Ниже приведен пример создания политики федерации для действия GitHub:

    databricks account service-principal-federation-policy create ${SERVICE_PRINCIPAL_NUMERIC_ID} --json \
'{
  "oidc_policy": {
    "issuer": "https://token.actions.githubusercontent.com",
    "audiences": [
      "https://github.com/my-github-org"
    ],
    "subject": "repo:my-github-org/my-repo:environment:prod"
  }
}'

API для учетной записи Databricks

  1. Получите числовый идентификатор субъекта-службы (например, 3659993829438643) из консоли учетной записи или с помощью API субъектов-служб.

  2. Создайте политику федерации субъекта-службы. Укажите ACCOUNT_CONSOLE_URL, Azure Databricks ACCOUNT_ID, SERVICE_PRINCIPAL_NUMERIC_ID и носителя TOKEN для проверки подлинности:

    curl --request POST \
  --header "Authorization: Bearer $TOKEN" \
  "${ACCOUNT_CONSOLE_URL}/api/2.0/accounts/${ACCOUNT_ID}/servicePrincipals/${SERVICE_PRINCIPAL_NUMERIC_ID}/federationPolicies" \
  --data '{
    "oidc_policy": {
      "issuer": "https://token.actions.githubusercontent.com",
      "audiences": [
        "https://github.com/my-github-org"
      ],
      "subject": "repo:my-github-org/my-repo:environment:prod"
    }
  }'

    Для получения полной справочной документации по API обратитесь к API Политики федерации учетных записей.

Примеры политик федерации субъекта-службы Databricks

В следующей таблице приведены примеры политик федерации субъекта-службы и соответствующего текста JWT.

Полные шаги по настройке федерации удостоверений нагрузки для некоторых из этих распространенных поставщиков удостоверений см. в разделе «Включение федерации удостоверений нагрузки» в CI/CD.

Tool Политика федерации пример сопоставления токенов
GitHub Actions Эмитент:https://token.actions.githubusercontent.comПублика:https://github.com/<github-org>Тема:repo:<github-org>/<repo>:environment:prod { "iss": "https://token.actions.githubusercontent.com", "aud": "https://github.com/<github-org>", "sub": "repo:<github-org>/<repo>:environment:prod" }
Kubernetes Эмитент:https://kubernetes.default.svcПублика:https://kubernetes.default.svcТема:system:serviceaccount:namespace:podnameJWKS JSON:{"keys":[{"kty":"rsa","e":"AQAB","use":"sig","kid":"<key-id>","alg":"RS256","n":"uPUViFv..."}]} { "iss": "https://kubernetes.default.svc", "aud": ["https://kubernetes.default.svc"], "sub": "system:serviceaccount:namespace:podname" }
Azure DevOps Эмитент:https://vstoken.dev.azure.com/<org_id>Публика:api://AzureADTokenExchangeТема:sc://my-org/my-project/my-connection { "iss": "https://vstoken.dev.azure.com/<org_id>", "aud": "api://AzureADTokenExchange", "sub": "sc://my-org/my-project/my-connection" }
GitLab Эмитент:https://gitlab.example.comПублика:https://gitlab.example.comТема:project_path:my-group/my-project:... { "iss": "https://gitlab.example.com", "aud": "https://gitlab.example.com", "sub": "project_path:my-group/my-project:..." }
CircleCI Эмитент:https://oidc.circleci.com/org/<org_id>Публика:<org_id>Тема:7cc1d11b-46c8-4eb2-9482-4c56a910c7ceУтверждение субъекта:oidc.circleci.com/project-id { "iss": "https://oidc.circleci.com/org/<org_id>", "aud": "<org_id>", "oidc.circleci.com/project-id": "7cc1d11b-46c8-4eb2-9482-4c56a910c7ce" }

Рекомендации по политикам федерации субъекта-службы

Каждый субъект-служба поддерживает не более 20 политик федерации. Следуйте этим рекомендациям, чтобы избежать достижения этого ограничения.

Сопоставление одного внешнего удостоверения на субъект-службу

Создайте выделенную учетную запись службы для каждой отдельной внешней идентичности рабочей нагрузки. Несколько политик федерации в одном объекте службы подходят только в случае проверки подлинности одной логической идентичности с помощью разных поставщиков удостоверений. Например, для рабочей нагрузки, которая выполняется как в GitHub Actions, так и в Azure DevOps требуется две политики( по одному на поставщика) на одном субъекте-службе.

Не используйте несколько политик для сопоставления различных рабочих нагрузок (например, отдельных модулей pod Kubernetes в каждом регионе) с одним субъектом-службой. Вместо этого создайте отдельный сервисный принципал для каждой рабочей нагрузки. Это сохраняет атрибуцию журнала аудита и позволяет отозвать доступ для одной рабочей нагрузки, не влияя на другие.

Упрощение разрешений с помощью групп

Если нескольким субъектам-службам требуются одинаковые разрешения, добавьте их в группу Azure Databricks и назначьте им разрешения. Ознакомьтесь с рекомендациями по идентификации.

Используйте свойство subject_claim для альтернативных утверждений

По умолчанию Azure Databricks использует claim sub из токена идентификации для идентификации рабочей нагрузки. Если поставщик удостоверений не использует sub утверждение в качестве стабильного идентификатора рабочей нагрузки, задайте для свойства subject_claim имя утверждения, которое использует ваш поставщик. Пример см. в разделе "Конфигурация CircleCI" в примерах политик федерации субъекта-службы Databricks. .

Федерация токенов на уровне учетной записи

Администраторы учетных записей могут настроить федерацию токенов OAuth с помощью политики федерации учетной записи в Azure Databricks. Политика федерации учетных записей позволяет всем пользователям и служебным принципалам в учетной записи Azure Databricks доступаться к API Databricks с помощью токенов от поставщика удостоверений. Политика федерации учетной записи указывает следующее:

  • Поставщик удостоверений или издатель, от которого Azure Databricks будет принимать токены.
  • Критерии сопоставления маркера с соответствующим Azure Databricks пользователем или субъектом-службой.

Например, учитывая политику федерации со следующими полями:

  • Эмитент:https://idp.mycompany.com/oidc
  • Аудитории:databricks
  • Утверждение субъекта:sub

Используйте это тело JWT для аутентификации в Azure Databricks как username@mycompany.com:

{
  "iss": "https://idp.mycompany.com/oidc",
  "aud": "databricks",
  "sub": "username@mycompany.com"
}

Настройка политики федерации учетной записи

Администраторы учетных записей могут настроить политику федерации учетной записи с помощью пользовательского интерфейса Azure Databricks, интерфейса командной строки Databricks CLI или REST API Databricks. В вашей учетной записи Azure Databricks можно указать не более 20 политик федерации учетных записей.

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

  • URL-адрес издателя: URL-адрес HTTPS, идентифицирующий поставщика удостоверений, указанный в заявлении токенов iss.

  • Аудитории: Предполагаемый получатель токена, указанный в требовании aud . Токен считается совпадением, если его аудитория соответствует по крайней мере одной аудитории в правиле. Если не указано, по умолчанию используется идентификатор учетной записи Azure Databricks.

  • Subject claim: Утверждение токена, содержащее имя пользователя Azure Databricks, для которого был выдан токен. Если не указано, значение по умолчанию равно sub.

  • Проверка подписи токена: (необязательно) Открытые ключи или их URL-адрес в формате JSON наборов веб-ключей (JWKS), используемые для проверки подписей токенов. JWKS JSON поддерживает до 5 ключей. Если поставщик удостоверений публикует больше информации, в этом случае используйте URI JWKS.

    Если не указано, рекомендуется использовать Azure Databricks для извлечения ключей с хорошо известной конечной точки издателя. Поставщик удостоверений должен предоставлять метаданные поставщика OpenID на <issuer-url>/.well-known/openid-configuration, которые включают элемент jwks_uri, указывающий расположение открытых ключей, используемых для проверки подписей токенов.

Important

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

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

  1. Как администратор учетной записи, войдите в консоль учетной записи Azure Databricks в https://accounts.azuredatabricks.net.
  2. Щелкните "Безопасность " и перейдите на вкладку "Проверка подлинности ".
  3. В разделе "Политики федерации" нажмите кнопку "Создать политику".
  4. Введите URL-адрес издателя, аудитории, требование субъекта и необязательную проверку подписи токена.
  5. Нажмите кнопку "Создать политику".

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

Вы не можете использовать интерфейс командной строки Databricks в веб-терминале рабочей области Azure Databricks для создания политики федерации.

  1. Установите или обновите последнюю версию интерфейса командной строки Databricks.

  2. В качестве администратора учетной записи выполните проверку подлинности в учетной записи Azure Databricks с помощью интерфейса командной строки. Укажите ACCOUNT_CONSOLE_URL и Azure Databricks ACCOUNT_ID.

    databricks auth login --host ${ACCOUNT_CONSOLE_URL} --account-id ${ACCOUNT_ID}

  3. Создайте политику федерации аккаунтов. Рассмотрим пример.

    databricks account federation-policy create --json \
'{
  "oidc_policy": {
    "issuer": "https://idp.mycompany.com/oidc",
    "audiences": [
      "databricks"
    ],
    "subject_claim": "sub"
  }
}'

API для учетной записи Databricks

Следующий вызов REST API создает политику федерации учетных записей. Укажите ACCOUNT_CONSOLE_URL, Azure Databricks ACCOUNT_ID и носитель TOKEN для проверки подлинности.

curl --request POST \
  --header "Authorization: Bearer $TOKEN" \
  "${ACCOUNT_CONSOLE_URL}/api/2.0/accounts/${ACCOUNT_ID}/federationPolicies" \
  --data '{
    "oidc_policy": {
      "issuer": "https://idp.mycompany.com/oidc",
      "audiences": [
        "databricks"
      ],
      "subject_claim": "sub"
    }
  }'

Для получения полной справочной документации по API обратитесь к API Политики федерации учетных записей.

Примеры политик федерации учетных записей

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

Политика федерации пример сопоставления токенов
Эмитент:https://idp.mycompany.com/oidcПублика:2ff814a6-3304-4ab8-85cb-cd0e6f879c1d { "iss": "https://idp.mycompany.com/oidc", "aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d", "sub": "username@mycompany.com" }
Эмитент:https://idp.mycompany.com/oidcПублика:2ff814a6-3304-4ab8-85cb-cd0e6f879c1dУтверждение субъекта:preferred_username { "iss": "https://idp.mycompany.com/oidc", "aud": ["2ff814a6-3304-4ab8-85cb-cd0e6f879c1d", "other-audience"], "preferred_username": "username@mycompany.com", "sub": "some-other-ignored-value" }
Эмитент:https://idp.mycompany.com/oidcПублика:2ff814a6-3304-4ab8-85cb-cd0e6f879c1dJWKS JSON:{"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"<key-id>","alg":"RS256","n":"uPUViFv..."}]} { "iss": "https://idp.mycompany.com/oidc", "aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d", "sub": "username@mycompany.com" } (подпись, проверенная с помощью открытого ключа в политике)
Эмитент:https://idp.mycompany.com/oidcПублика:2ff814a6-3304-4ab8-85cb-cd0e6f879c1dURI JWKS:https://idp.mycompany.com/jwks.json { "iss": "https://idp.mycompany.com/oidc", "aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d", "sub": "username@mycompany.com" } (подпись, проверенная с помощью открытого ключа, полученного из jwks_uri)

Дальнейшие шаги

После настройки политики федерации для учетной записи:

  • Настройте поставщика удостоверений (IdP) для создания маркеров, которые пользователи могут обменивать в Azure Databricks. Ознакомьтесь с документацией вашего поставщика удостоверений для получения сведений о настройке. Для получения инструкций по включению федерации удостоверений рабочей нагрузки с распространенными поставщиками удостоверений личности, см. раздел "Включение федерации удостоверений рабочей нагрузки в CI/CD".
  • Используйте JWT из вашего поставщика удостоверений, чтобы получить доступ к API Azure Databricks, сначала обменяв его на токен OAuth Azure Databricks. Добавьте OAuth-токен Azure Databricks в заголовок Bearer: вызова API, чтобы завершить запрос. JWT должен быть допустимым и подписанным с помощью алгоритмов RS256 или ES256. Дополнительные сведения о реализации см. в разделе "Аутентификация с использованием токена удостоверяющей стороны".
  • Last updated on