Если бы вы работали в кластере Azure Kubernetes, было бы действительно легко установить подключение службы в DevOps Azure к службе AKS. В соответствии с этой настройкой выполнение ваших сценариев будет осуществляться безопасно с помощью автоматизации Azure в дата-центрах Microsoft.
Однако, поскольку вы работаете в своем собственном кластере Kubernetes, это в основном похоже на запуск набора виртуальных машин , которые просто оказались в Azure . Чтобы AzO DevOps мог выполнять команды для вашего кластера, вам нужно указать IP-адрес, который он может получить, и, поскольку эти машины находятся в разных сетях, вам нужно выставить свой кластер на общедоступный IP-адрес. Это действительно похоже на уязвимость.
Я могу придумать два варианта:
Правило сетевой безопасности для агентов DevOps Azure - При создании виртуальной машины ее необходимо было поместить в виртуальную сеть. Вы можете создать группу безопасности сети (NSG) для этой виртуальной сети и добавить правило входящих, чтобы разрешить подключения из DevOps Azure. Итак, да, это будет публичный IP-адрес, но вы запретите весь входящий трафик, кроме указанных IP-адресов.
Теперь проблема заключается в том, что если вы используете размещенный агент сборки для DevOps Azure (агент, предоставленный вам Microsoft), важно отметить, что каждый раз, когда вы запускаете сборку или выпуск, вы получаете совершенно новый виртуальный машина, поэтому будет сложно создать правило брандмауэра для одного IP-адреса. Вам нужно будет настроить диапазон IP-адресов.
Microsoft публикует список диапазонов IP-адресов для их агентов сборки каждый понедельник, чтобы теоретически можно было настроить правило брандмауэра для ограничения доступа к этим конкретным диапазонам IP-адресов. Я понятия не имею, насколько изменчив этот список, или вам нужно еженедельно менять диапазоны IP-адресов. Это звучит как работа.
Self-Hosted Build Agent - Если вы хотите полностью избежать общедоступного IP-адреса, вам нужно использовать «Self-Hosted Build Agent» (компьютер, предоставленный вы), чтобы агент сборки мог общаться в той же частной сети, что и кластер.
Использование автономного агента сборки означает, что вам придется нести ответственность за обслуживание этого компьютера, но он может находиться во внутренней сети, где вы можете контролировать IP-адрес. Вы также можете настроить выделенную виртуальную машину в той же виртуальной сети, что и кластер. И мой личный фаворит, вы также можете настроить агент сборки как докер-контейнер внутри вашего кластера . Образ докера для агента vsts находится здесь: https://hub.docker.com/_/microsoft-azure-pipelines-vsts-agent
Примечание об агентах сборки - им не требуются правила брандмауэра, поскольку они взаимодействуют с исходящими операциями Azure. Все триггеры и взаимодействия происходят на веб-сайте Azure DevOps, но фактическая работа делегируется агенту.