Проверка подлинности Terraform в Azure

  • Статья

Terraform поддерживает определение, предварительный просмотр и развертывание облачной инфраструктуры. С помощью Terraform можно создавать файлы конфигурации с применением синтаксиса HCL. Синтаксис HCL позволяет указать поставщика облачных служб, например Azure, и элементы, составляющие облачную инфраструктуру. После создания файлов конфигурации создается план выполнения, который позволяет предварительно просматривать изменения инфраструктуры до их развертывания. После проверки изменений примените план выполнения для развертывания инфраструктуры.

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

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

  • описывать общие сценарии аутентификации Terraform и Azure;
  • выполнять аутентификацию с помощью учетной записи Майкрософт из Cloud Shell (с помощью Bash или PowerShell);
  • выполнять аутентификацию с помощью учетной записи Майкрософт из Windows (с помощью Bash или PowerShell);
  • создавать субъект-службу с помощью Azure CLI;
  • Создание субъекта-службы с помощью Azure PowerShell
  • указывать учетные данные субъекта-службы в переменных среды;
  • указывать учетные данные субъекта-службы в блоке поставщика Terraform.

1. Настройка среды

2. Аутентификация Terraform в Azure

Сценарии проверки подлинности Terraform и Azure

Terraform поддерживает проверку подлинности в Azure только с помощью Azure CLI. Проверка подлинности с помощью Azure PowerShell не поддерживается. Поэтому, хотя вы можете использовать модуль Azure PowerShell при работе с Terraform, сначала необходимо пройти проверку подлинности в Azure с помощью Azure CLI.

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

Проверка подлинности в Azure с помощью учетной записи Майкрософт

Учетная запись Майкрософт — это имя пользователя (связанное с электронной почтой и его учетными данными), которое используется для входа в службы Майкрософт , например Azure. Учетную запись Майкрософт можно связать с одной или несколькими подписками Azure, при этом по умолчанию используется одна из этих подписок.

Ниже показано, как:

  • Войдите в Azure в интерактивном режиме с помощью учетной записи Майкрософт
  • Вывод списка связанных подписок Azure учетной записи (включая подписку по умолчанию)
  • Задайте текущую подписку.

  1. Откройте командную строку, которая имеет доступ к Azure CLI.

  2. Запустите az login без параметров и следуйте инструкциям для входа в Azure.

    az login

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

    • После успешного входа отображается список подписок Azure, az login связанных с учетной записью Майкрософт, вошедшего в систему, включая подписку по умолчанию.

  3. Чтобы подтвердить текущую подписку Azure, выполните команду az account show.

    az account show

  4. Чтобы просмотреть все имена и идентификаторы подписок Azure для конкретной учетной записи Майкрософт, выполните команду az account list.

    az account list --query "[?user.name=='<microsoft_account_email>'].{Name:name, ID:id, Default:isDefault}" --output Table

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

    • Замените заполнитель <microsoft_account_email> адресом электронной почты учетной записи Майкрософт, список подписок Azure которой нужно получить.
    • С помощью учетной записи live ( например, Hotmail или Outlook) может потребоваться указать полный адрес электронной почты. Например, если ваш адрес электронной почты — admin@hotmail.com, может потребоваться заменить заполнитель адресом live.com#admin@hotmail.com.

  5. Чтобы использовать определенную подписку Azure, выполните команду az account set.

    az account set --subscription "<subscription_id_or_subscription_name>"

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

    • Замените заполнитель <subscription_id_or_subscription_name> идентификатором или именем подписки, которую вы хотите использовать.
    • При вызове az account set не отобразятся результаты переключения на указанную подписку Azure. Однако с помощью az account show можно убедиться, что текущая подписка Azure изменилась.
    • Если выполнить команду az account list из предыдущего шага, вы увидите, что подписка Azure по умолчанию была изменена на подписку, указанную в az account set.

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

Разрешения для автоматизированных средств, которые развертывают или используют службы 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*

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

  • Как и в случае с любой переменной среды, для доступа к значению подписки Azure из скрипта Terraform используйте следующий синтаксис: ${env.<environment_variable>}. Например, чтобы получить доступ к значению ARM_SUBSCRIPTION_ID, укажите ${env.ARM_SUBSCRIPTION_ID}.
  • Создание и применение планов выполнения Terraform вносит изменения в подписку Azure, связанную с субъектом-службой. Этот факт иногда может вводить в заблуждение, если вы выполнили вход в одну подписку Azure, а переменные среды указывают на вторую подписку Azure. Рассмотрим следующий пример. Предположим, у вас есть две подписки Azure: SubA и SubB. Если текущая подписка Azure — SubA (определена через az account show), а переменные среды указывают на SubB, любые внесенные Terraform изменения будут применены в SubB. Поэтому вам нужно войти в подписку SubB, чтобы выполнить команды Azure CLI или Azure PowerShell для просмотра изменений.

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

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

terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
      version = "~>2.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

Внимание

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

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

Убедитесь, что вы прошли аутентификацию в подписке Azure, отобразив текущую подписку.

Чтобы подтвердить текущую подписку Azure через Azure CLI, запустите az account show.

az account show

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

Создание группы ресурсов Azure