Развертывание на виртуальной машине группы ресурсов Azure

Если бы вы использовали кластер Azure Kubernetes, было бы очень легко установить подключение службы в Azure DevOps к службе AKS. При такой настройке запуск ваших сценариев будет выполняться безопасно с помощью автоматизации Azure в центрах обработки данных Microsoft.

Однако, поскольку вы используете свой собственный кластер Kubernetes, это в основном похоже на запуск набора виртуальных машин которые просто оказались в Azure. Чтобы Azure DevOps мог выполнять команды для вашего кластера, вам нужно указать IP-адрес, до которого он может добраться, и, поскольку эти машины находятся в разных сетях, вам кажется, что вам нужно предоставить доступ к вашему кластеру на общедоступном IP-адресе. Это действительно похоже на уязвимость.

Я могу думать о двух вариантах:

1. Правило сетевой безопасности для агентов Azure DevOps — когда вы создавали виртуальную машину, вам нужно было поместить ее в виртуальную сеть. Вы можете создать группу безопасности сети (NSG) для этой виртуальной сети и добавить правило для входящих подключений, чтобы разрешить подключения из Azure DevOps. Итак, да, это будет общедоступный IP-адрес, но вы запретите весь входящий трафик, кроме указанных вами IP-адресов.

   Теперь проблема заключается в том, что если вы используете размещенный агент сборки для Azure DevOps (агент, предоставленный вам Microsoft), важно отметить, что каждый раз, когда вы запускаете сборку или выпуск, вы получаете совершенно новую виртуальную машину, поэтому будет сложно создать правило брандмауэра для одного IP-адреса. Вам нужно настроить диапазон IP-адресов.

   Microsoft публикует список диапазонов IP-адресов для своих агентов сборки каждый понедельник, поэтому теоретически вы можете настроить правило брандмауэра, чтобы ограничить доступ к этим конкретным диапазонам IP-адресов. Я понятия не имею, насколько изменчив этот список, и нужно ли вам еженедельно менять диапазоны IP-адресов. Это похоже на работу.

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

   Использование собственного агента сборки означает, что вам придется взять на себя ответственность за обслуживание этой машины, но она может находиться в вашей внутренней сети, где вы можете контролировать IP-адрес. Вы также можете настроить выделенную виртуальную машину в той же виртуальной сети, что и кластер. И мой личный фаворит, вы также можете настройте агент сборки как контейнер докеров внутри вашего кластера. Образ докера для агента vsts находится здесь: https://hub.docker.com/_/microsoft-azure-pipelines-vsts-agent

Примечание об агентах сборки: для них не требуются правила брандмауэра, поскольку они обмениваются данными с Azure DevOps. Все триггеры и взаимодействия происходят на веб-сайте Azure DevOps, но фактическая работа делегируется агенту.