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

Проверка подлинности в Azure с помощью субъекта-службы

  • Статья

В этой статье объясняется, как выполнить проверку подлинности Terraform в Azure с помощью субъекта-службы.

Вы узнаете, как выполнять следующие задачи:

  • Создание субъекта-службы
  • Указание учетных данных субъекта-службы в переменных среды
  • указывать учетные данные субъекта-службы в блоке поставщика Terraform.

Создание субъекта-службы

Если у вас нет доступа к субъекту-службе, перейдите к этому разделу, чтобы создать новый субъект-службу. Если у вас есть субъект-служба, который можно использовать, перейдите к разделу, укажите учетные данные субъекта-службы.

Разрешения для автоматизированных средств, которые развертывают или используют службы Azure (такие как Terraform), всегда должны быть ограничены. Вместо того, чтобы приложения входили в систему как полностью привилегированный пользователь, Azure предлагает субъекты-службы.

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

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

  2. Если вы создаете субъект-службу из Git Bash, задайте переменную среды MSYS_NO_PATHCONV. (Этот шаг не нужен, если вы используете Cloud Shell.)

    export MSYS_NO_PATHCONV=1

    Основные моменты:

    • Переменную среды MSYS_NO_PATHCONV можно задать глобально (для всех сеансов терминала) или локально (только для текущего сеанса). Так как создание субъекта-службы часто не является тем, что вы делаете, пример задает значение для текущего сеанса. Чтобы задать эту переменную среды глобально, добавьте параметр в файл ~/.bashrc.

  3. Чтобы создать субъект-службу, выполните команду az ad sp create-for-rbac.

    az ad sp create-for-rbac --name <service_principal_name> --role Contributor --scopes /subscriptions/<subscription_id>

    Основные моменты:

    • <service-principal-name> можно заменить пользовательским именем среды или полностью опустить параметр. Если параметр не задан, имя субъекта-службы создается на основе текущей даты и времени.
    • После успешного выполнения az ad sp create-for-rbac отображает несколько значений. Значения appId, password и tenant используются на следующем шаге.
    • Пароль невозможно извлечь, если он утерян. Следовательно, пароль нужно хранить в надежном месте. Если вы забыли пароль, можно сбросить учетные данные субъекта-службы.
    • В рамках этой статьи используется субъект-служба с ролью Участник. Дополнительные сведения о ролях контроль доступа на основе ролей (RBAC) см. в статье RBAC: встроенные роли.
    • Выходные данные, полученные в результате создания субъекта-службы, включают конфиденциальные учетные данные. Убедитесь, что эти учетные данные не включены в код, или проверьте учетные данные в системе управления версиями.
    • Дополнительные сведения о параметрах при создании субъекта-службы с помощью Azure CLI см. в статье "Создание субъекта-службы Azure с помощью Azure CLI".

Указание учетных данных субъекта-службы

Существует несколько способов указать учетные данные субъекта-службы. Однако по соображениям безопасности рекомендуется не хранить учетные данные в блоке поставщика. Этот метод показан только в целях полноты и тестирования.

указывать учетные данные субъекта-службы в переменных среды;

После создания субъекта-службы можно указать его учетные данные в Terraform с помощью переменных среды.

  1. Измените файл ~/.bashrc, добавив следующие переменные среды.

    export ARM_SUBSCRIPTION_ID="<azure_subscription_id>"
export ARM_TENANT_ID="<azure_subscription_tenant_id>"
export ARM_CLIENT_ID="<service_principal_appid>"
export ARM_CLIENT_SECRET="<service_principal_password>"

  2. Чтобы выполнить скрипт ~/.bashrc, выполните команду source ~/.bashrc (или ее сокращенный эквивалент . ~/.bashrc). Можно также выйти и повторно открыть Cloud Shell для автоматического запуска скрипта.

    . ~/.bashrc

  3. После установки переменных среды можно проверить их значения следующим образом:

    printenv | grep ^ARM*

    Основные моменты:

    • Дополнительные сведения о работе с переменными среды в HCL Terraform см. в статье "Чтение и использование переменных среды" в запусках Terraform.
    • Создание и применение планов выполнения Terraform вносит изменения в подписку Azure, связанную с субъектом-службой. Этот факт иногда может вводить в заблуждение, если вы выполнили вход в одну подписку Azure, а переменные среды указывают на вторую подписку Azure. Рассмотрим следующий пример. Предположим, у вас есть две подписки Azure: SubA и SubB. Если текущая подписка Azure — SubA (определена через az account show), а переменные среды указывают на SubB, любые внесенные Terraform изменения будут применены в SubB. Поэтому вам нужно войти в подписку SubB, чтобы выполнить команды Azure CLI или Azure PowerShell для просмотра изменений.

  4. Перейдите к разделу, дальнейшие действия

указывать учетные данные субъекта-службы в блоке поставщика Terraform.

Внимание

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

Блок поставщика Azure определяет синтаксис, позволяющий указать сведения о проверке подлинности в подписке Azure.

terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
      version = "~>3.0"
    }
  }
}

provider "azurerm" {
  features {}

  subscription_id   = "<azure_subscription_id>"
  tenant_id         = "<azure_subscription_tenant_id>"
  client_id         = "<service_principal_appid>"
  client_secret     = "<service_principal_password>"
}

# Your code goes here

Следующие шаги

Проверка результатов