部署到Azure资源组的VM

时间:2019-04-10 14:32:27

标签: azure-devops

我正在azure上运行kubernetes集群,没有任何公共访问权限(不是AKS)。

我想使用kubernetes服务连接从azure devops运行kubctl命令。我用它导入证书并指向公共IP,并且部署成功。

但是我想知道是否有可能在不公开使用计算机的情况下访问资源组的虚拟机(也许使用vnet或网关)?

1 个答案:

答案 0 :(得分:1)

如果您正在运行Azure Kubernetes群集,那么在Azure DevOps中建立到AKS服务的服务连接真的很容易。在这种设置下,可以通过Microsoft数据中心内的Azure自动化安全地运行脚本。

但是,由于您正在运行自己的Kubernetes集群,因此基本上就像运行一组恰好在Azure中的虚拟机 一样。为了使Azure DevOps对您的群集执行命令,您需要提供一个可以访问的IP地址,并且由于这些计算机位于不同的网络中,因此您需要将群集公开在公共IP地址上。这确实确实像一个漏洞。

我可以想到两种选择:

  1. Azure DevOps代理的网络安全规则-创建虚拟机时,必须将其放入虚拟网络中。您可以为该虚拟网络创建网络安全组(NSG),并且可以添加入站规则以允许来自Azure DevOps的连接。因此,是的,这将是一个公共IP,但是您将拒绝除指定IP地址之外的所有入站流量。

    现在,这里的挑战是,如果您正在使用Azure DevOps的托管生成代理(Microsoft提供给您的代理),请务必注意,每次您运行生成或发行版本时,您都会获得一个全新的虚拟主机。机器,因此很难为单个IP地址创建防火墙规则。您需要配置一系列IP地址。

    Microsoft publishes a list of IP Address ranges for their build agents每个星期一,因此理论上您可以设置防火墙规则以限制对那些特定IP地址范围的访问。我不知道这个列表有多不稳定,或者您是否需要每周更改IP地址范围。听起来像工作。

  2. 自托管构建代理-如果要完全避免使用公共IP地址,则需要使用“自托管构建代理”(提供的机器),以便构建代理可以在与群集相同的专用网络上进行通信。

    使用自承载的构建代理意味着您必须负责维护该计算机,但是它可以驻留在内部网络中,您可以在其中控制IP地址。您还可以在与群集相同的虚拟网络中设置专用虚拟机。而我个人最爱,您也可以configure the build agent as a docker container inside your cluster。 vsts代理的docker映像位于以下位置:https://hub.docker.com/_/microsoft-azure-pipelines-vsts-agent

关于生成代理的说明-它们在与Azure DevOps进行出站通信时不需要防火墙规则。所有触发器和交互都在Azure DevOps网站上进行,但实际工作将委托给代理。