где хранить основные данные службы azure при использовании с terraform из CI или docker - PullRequest
Новая
       4

где хранить основные данные службы azure при использовании с terraform из CI или docker

0 голосов
/ 09 февраля 2020

Я читаю все документы terraform об использовании субъекта службы с секретом клиента в файле CI или docker или чем-то еще, и я цитирую:

Мы рекомендуем использование принципала службы или идентификатора управляемой службы при неинтерактивном запуске Terraform (например, при запуске Terraform на сервере CI) и аутентификация с использованием CLI Azure при локальном запуске Terraform.

It затем подробно рассказывает о создании субъекта службы, а затем приводит ужасный пример в конце, когда идентификатор клиента и секрет клиента жестко закодированы в файле путем их сохранения в переменных среды: 

export ARM_CLIENT_ID="00000000-0000-0000-0000-000000000000"
export ARM_CLIENT_SECRET="00000000-0000-0000-0000-000000000000"
export ARM_SUBSCRIPTION_ID="00000000-0000-0000-0000-000000000000"
export ARM_TENANT_ID="00000000-0000-0000-0000-000000000000"

или в блок провайдера terraform: 

provider "azurerm" {
  # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used
  version = "=1.43.0"

  subscription_id = "00000000-0000-0000-0000-000000000000"
  client_id       = "00000000-0000-0000-0000-000000000000"
  client_secret   = "${var.client_secret}"
  tenant_id       = "00000000-0000-0000-0000-000000000000"
}

В нем есть симпатичная желтая рамка о том, что не делайте этого, но нет никаких подсказок, что делать.

Я не думаю client_secret в переменной среды - это особенно хорошая идея.

Должен ли я использовать сертификат клиента и, если да, то же самое возникает вопрос о том, где сохранить конфигурацию.

Я хочу, если возможно, избежать azure -cli.

Azure -cli в любом случае не вернет секрет клиента.

Как мне go передать эти секреты в переменные окружения? Должен ли я положить их в хранилище или есть другой способ?

1 Ответ

0 голосов
/ 11 февраля 2020

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

Вы видите, что удостоверение управляемой услуги доступно только для служб с управляемой Характеристика сервиса. Так что docker не может его использовать. И вам также необходимо назначить его с соответствующим разрешением в качестве участника службы. Вы не хотите использовать Azure CLI, если это возможно, я не знаю почему, но давайте сначала пропустим это.

Я считаю, что принципал обслуживания - хороший способ. Рекомендуется не помещать секрет в переменную внутри файла Terraform. Таким образом, вы можете использовать только переменную окружения. И если вы также не хотите устанавливать переменную окружения, то я не думаю, что есть способ использовать субъект службы. Сертификат для субъекта службы должен только устанавливать путь сертификата больше, чем другой.

И для субъекта службы следует соблюдать осторожность. Вы можете увидеть секрет принципала службы только один раз, когда вы закончите sh, создав его, и тогда он больше не будет отображаться. Если вы забыли, вы можете сбросить только секрет.

Поэтому я считаю, что принцип обслуживания - самый подходящий для вас способ. Вы можете установить переменные окружения с помощью параметра --env команды docker run. Или просто установите их в Dockerfile с помощью ENV. Способ хранения секрета в хранилище ключей, я думаю, вы можете получить ответ в моем предыдущем ответе.

...