Управление доступом к Azure Key Vault и секретами из конвейера DevOps
Azure Key Vault — это мощный ресурс для развертывания ваших приложений в Microsoft Azure. В этой статье будут рассмотрены некоторые интеграции, которые можно выполнить в Azure DevOps, чтобы разрешить предоставление Key Vault и заполнить его некоторыми данными, которые могут использоваться в дальнейшем другими компонентами в конвейере.
Соглашение об именах — ключ к успеху
Соглашение об именовании является ключом к успеху любого проекта «инфраструктура как код» (IaC). Некоторым людям нравится передавать параметры для имени объектов. Тем не менее, он полностью поддерживается и используется. По мере того, как вы получаете большие среды, работа, необходимая для соединения всех параметров с реализацией, может стать громоздкой.
Рекомендуется создать строгое соглашение об именах, которое не имеет значения, где вы находитесь. Вы всегда можете найти ресурсы на основе соглашения об именах. Имена могут быть созданы как переменные, что исключает ввод данных конечными пользователями, и это сделает наш код более согласованным и устойчивым в разных средах.
В этой статье мы будем использовать две-три цифры для ресурса, кода региона, среды и имени приложения. Простым примером такого соглашения об именах может быть метка Key Vault как KV-CaC-DEV-ProjectX.
Подготовка Azure Key Vault и некоторые хитрости в полевых условиях
Чтобы подготовить Key Vault, нам нужно только имя (элемент 1). Однако в нашем коде мы добавим политики доступа (пункт 2) и сетевые ACLS (пункт 3) из файлов параметров. Все остальные значения из шаблона являются стандартными, и вы можете изменить их в соответствии с вашими текущими корпоративными стандартами (например, включить защиту от очистки, количество дней для удаленного контента и т. д.).
Поскольку мы упомянули параметры, которые нам потребуются, вот список всех параметров, которые нам потребуются в нашем шаблоне ARM.
В нашей статье мы должны сделать небольшое отступление, чтобы определить ObjectID субъекта-службы, на котором запущен конвейер выпуска Azure DevOps. Это важно, потому что мы будем использовать эту учетную запись для назначения разрешений в политиках доступа к хранилищу ключей, и это даст нам достаточно возможностей для добавления информации в хранилище ключей Azure во время развертывания. Как это круто?
В этой статье мы создадим простой конвейер, который развертывает наш код (почти Azure Key Vault со всеми функциями, обсуждаемыми в этой статье). В конвейере нам нужно узнать информацию о нашем подключении к Azure Resource Manager, нажав «Управление» (элемент 1).
Примечание. Если вы не знаете, как настроить и запустить конвейер выпуска, посмотрите мою серию, в которой показано, как это сделать с нуля. Вот ссылка.
На новой странице нажмите Manage Service Principal. Мы будем перенаправлены в Azure Active Directory. На этой странице мы настроим имя субъекта-службы. Нажмите «Брендинг» (пункт 1), укажите имя (в нашем случае AP6Labs-Techgenix.svc.account, как показано в пункте 2), наконец, нажмите «Сохранить» (пункт 3).
Если мы вернемся на страницу обзора, мы сможем получить идентификатор арендатора, который будет использоваться далее в этой статье.
Последняя остановка перед тем, как вернуться к коду, — найти ObjectID учетной записи субъекта-службы, которую мы используем Azure DevOps.
Откройте элемент Azure Active Directory на портале Azure, щелкните Корпоративные приложения. В новой колонке выберите Все приложения и введите имя субъекта-службы. Нажмите на него из списка ниже.
Мы нашли это! Скопируйте идентификатор объекта, выделенный на изображении ниже. Нам понадобится эта информация в нашем файле параметров, ожидающем нас в нашем репозитории в Azure DevOps.
Последний шаг — перейти к файлам параметров (в этой статье мы обозначили их как keyvault.dev.json), и нам нужно определить параметры, такие как среда, региональный код, списки управления доступом Key Vault Network и политики доступа..
Политики доступа выделены на изображении ниже. Нам нужно указать objectID и tenantID, а также необходимые разрешения для секрета, ключа или сертификата.
После развертывания Azure Key Vault с использованием кода, который мы рассмотрели до сих пор, результатом будет новая запись в политиках доступа к нашей учетной записи субъекта-службы и разрешения, определенные в файле параметров.
Заполнение нового Key Vault из конвейера выпуска
У нас есть все необходимое, чтобы перейти к следующему шагу: заполнить Key Vault ключами, секретами и сертификатами в рамках конвейера Azure DevOps!
Мы создадим два файла для поддержки этой инициативы (keyvault.csv и keyvault.ps1). Файл CSV будет иметь два столбца (имя и секрет). Мы заполним его информацией, которую можно добавить в репозиторий, или статическими значениями, но мы также будем использовать случайную строку для создания надежной строки во время выполнения и добавления ее в Azure Key Vault.
Сценарий PowerShell, созданный для этого упражнения, прост: мы получаем один аргумент (среду), который поможет нам создать имя Key Vault в сценарии. Второй шаг — загрузить модули Azure Key Vault, CSV-файл и проверить каждый из секретов, существующих в хранилище. Если их нет, мы создадим их соответствующим образом.
Мы используем функцию для создания случайного пароля. (Я нашел его в Интернете и немного подправил, чтобы он соответствовал моим требованиям.)
В конвейере текущего релиза нам нужно добавить новые задачи из типа Azure PowerShell и указать подписку, файл скрипта и среду. Использование переменной, совпадающей с именем стадии, полезно при копировании стадий. Пока мы помечаем их правильным именем среды, сценарий будет получать правильное значение.
После запуска нашего обновленного пайплайна релизов результатом является набор секретов, которые мы определили в нашем CSV-файле. Некоторые из них имеют статические значения, некоторые имеют случайно сгенерированные строки, используемые другими компонентами конвейера, о данных которых никто не знает.
Ключи к хранилищу ключей Azure
В этой статье мы описали несколько основных шагов, которые в совокупности позволяют нам углубиться в реализацию Azure DevOps и даже загрузить Azure Key Vault со значениями, необходимыми для будущих развертываний по всему конвейеру. Сценарий PowerShell прост, но проверяет, есть ли уже секреты. Если они есть, никаких действий не предпринимается. Мы можем применить ту же идею и импортировать сертификаты и даже использовать Key Vault для получения пароля сертификата в процессе импорта.