Предоставить Terraform Service Основной вкладчик, но удалить из хранилища ключей - PullRequest
Новая
       6

Предоставить Terraform Service Основной вкладчик, но удалить из хранилища ключей

0 голосов
/ 01 мая 2018

Мы создаем решение в правительстве Azure и будем использовать Terraform для его развертывания. Предполагается, что предпочтительным способом является создание принципала службы для Terraform с принципалом службы с ролью «Участник» в рамках подписки.

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

Мы пытались установить блокировку ReadOnly в хранилище ключей перед созданием субъекта службы, но блокировка не мешает участнику службы получать разрешения участника для хранилища ключей.

Помимо создания новой роли, в которой есть Участник всего, кроме КЛЮЧЕВОГО хранилища, есть ли у кого-нибудь творческие идеи, которые могли бы помочь достичь этого?

1 Ответ

0 голосов
/ 03 июня 2018

Да, основная причина всех проблем безопасности заключается в том, что назначение роли участника-участника службы находится на уровне / уровне подписки, что позволяет ему нанести существенный ущерб, особенно если несколько приложений развернуты в одной и той же подписке (например, удалить любой ресурс). группа).

Один из подходов будет:

  1. Предоставление одна группа ресурсов для хранилища ключей Azure, специфичного для приложения и региона (последнее в случае географически распределенных приложений).
  2. Подготовьте хранилище ключей Azure в группе ресурсов, созданной на предыдущем шаге.

В нашем случае Управление безопасности отвечало за первые 2 шага, где они отслеживали (например, электронную почту, текстовые сообщения и т. Д.) Любые изменения в хранилище ключей Azure (например, добавляли новые ключи / секреты / сертификаты). / удалено / изменено, изменения разрешений и т. д.).

  1. Предоставление второй группы ресурсов , которая будет служить контейнером для компонентов приложения (например, функции Azure, SQL Server / базы данных Azure, пространства имен / очередей служебной шины Azure и т. Д.).
  2. Создайте участника службы и назначьте роль участника для только группа ресурсов приложения , например: scope = /subscriptions/{Subscription Id}/resourceGroups/{Resource Group Name}

Найдите пример сценария PS для предоставления субъекту службы настраиваемой области в https://github.com/evandropaula/Azure/blob/master/ServicePrincipal/PS/Create-ServicePrincipal.ps1.

  1. Предоставьте соответствующие разрешения для участника службы в Azure. Ключ Vault. В нашем случае мы решили иметь отдельный Сервис Основные учетные записи для развертывания ( разрешения на чтение / запись для ключей / секретов / сертификатов) и времени выполнения ( только для чтения разрешения для ключей / секретов / сертификатов);

Найдите пример сценария PS для установки разрешения участника службы для хранилища ключей Azure на https://github.com/evandropaula/Azure/blob/master/KeyVault/PS/Set-ServicePrincipalPermissions.ps1.

С учетом вышесказанного, при таком подходе есть много неудобств, таких как:

  • Процесс (например, через runbook) для предоставления хранилища ключей Azure (включая его группу ресурсов) и группы ресурсов приложения будет находиться вне основного шаблона Terraform, отвечающего за компоненты приложения, что требует координации с различными командами / процессами / инструменты / и т.д.
  • Живой сайт с подключением часто включает координацию между несколькими командами для обеспечения достижения целей RTO и MTTM (Среднее время для смягчения).
  • Принципал службы сможет удалить группу ресурсов приложения, когда будет выполнено terraform destroy , но не сможет воссоздать при работе терраформ применяется после этого из-за отсутствия разрешения на уровне подписки / области действия. Вот ошибка:

provider.azurerm: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: resources.ProvidersClient#List: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client '' with object id '' does not have authorization to perform action 'Microsoft.Resources/subscriptions/providers/read' over scope '/subscriptions/{Subscription Id}'.".

Да, я знаю, это длинный ответ, но эта тема обычно требует множества межгрупповых обсуждений / мозгового штурма, чтобы убедиться, что меры безопасности, установленные Службой безопасности, выполнены, производительность разработчика не пострадала до такой степени, что это повлияет на графики выпуска и достижения целей RTO / MTTM. Надеюсь, это немного поможет!

...