【问题标题】:Azure Devops: securing deployments to on-premise servers at webapp levelAzure Devops:在 webapp 级别保护对本地服务器的部署
【发布时间】:2020-06-04 14:36:29
【问题描述】:

很明显,由于部署组和代理池中的安全设置,您可以设置哪些角色可以部署到某个本地服务器。但是,有什么方法可以在 webapp 级别限制访问?

我找到的唯一方法是:

  1. 创建一个特定帐户,授予它在目标服务器的 IIS 中仅在所需的 webapps 中部署权限,并将此凭据提供给负责创建用于部署这些 webapps 的管道的开发人员(他们将把它们作为自定义环境变量或类似的在管道中)

  2. 与 1 相同,但使用创建的帐户作为代理的服务帐户。此代理的访问权限将仅限于负责创建用于部署这些 web 应用程序的管道的开发人员。

这两种情况都需要创建新帐户并授予服务器 IIS 的权限。无法从 Azure DevOps 执行此操作,就像限制对整个服务器的访问一样?

问候。

【问题讨论】:

    标签: iis azure-devops azure-devops-deploymentgroups


    【解决方案1】:

    很明显你可以设置哪些角色可以部署到某个 由于部署组中的安全设置,本地服务器 和代理池。但是,有什么方法可以在 webapp 级别限制访问?

    抱歉,据我所知 Azure Devops Service 不支持这种开箱即用的功能。

    我们可以管理Organization level(Organization settings)Project Level(Project settings)Feature Level(Security of Pipelines/Deployment Groups feature...)甚至'instance Level' (Set security for one specific pipeline/deployment group/one specific git repo)中的访问权限。

    'instance level'是最低级别,我们可以管理特定管道或特定部署组中的访问,但不能管理pipeline/deploymentGroup将部署的一个webapp。

    Web 应用程序不是由 Azure Devops Service 托管的选项,它只是由管道(由 Azure Devops Service 托管)部署的东西。所以 Azure Devops 服务实际上对 webapp 一无所知(它也不会有代表一个 webapp 的 UI),这就是为什么我们可以管理管道中的访问但不能管理该管道中的 webapp...

    更新 1

    一旦特定目标服务器只有一个部署组,您可以在此处确定谁可以访问该部署组:

    被分配了读者权限的人不能使用部署组进行部署。

    【讨论】:

    • 感谢您的回答 :) 您如何看待我提出的解决问题的两个选项,还有其他(更好或更简单)的方法来实现它吗?问候
    • @Josto 对于以上两个选项,我更喜欢option1。 (只是个人想法)我没有更简单的方法,我对你为什么要限制 webapp 级别的访问感到有点困惑?我的意思是,我们可以设置 repos 访问级别来保护你的代码,设置管道访问来控制你的 CI/CD 的步骤,设置部署组来保护你的目标服务器....但是在限制访问时你想保护什么? app,也许是 x-y 问题?(无论如何,为你的问题投票吧~)
    • 因为在我们的每台 IIS 服务器中都有几个团队开发的几个 webapp。每个团队都负责创建自己的 CD 管道。事故(或攻击)可能会破坏应用程序(或整个服务器)。我只是应用最小权限原则。
    • 这个需求好像没有合适的官方服务连接,所以暂时不可能。此外,如果您有兴趣创建自定义服务连接,this 会很有帮助。
    • IIS Web App Deploy task 不接受服务连接作为输入,因此它不会占用您的服务连接。根据我的经验,第三方公司总是与自定义任务一起开发自定义服务连接。像这样custom extension... 这需要大量的工作。
    【解决方案2】:

    好的,遵循@Lance 的suggestion 并经过一些研究,这就是我打算做的:

    1. 创建一个custom service connection,其中可以设置以下字段:IIS 服务器 WebApp 所在的位置、Webapp 名称用户(具有权限部署)和密码
    2. 与自定义服务连接一起,我将提供一个自定义任务,开发人员团队可以在其中选择他们想要进行部署的服务连接(显然,服务器管理员只会配置到允许该团队部署的 web 应用程序的服务连接) .
    3. 代理将使用低权限帐户运行(不会影响任何应用程序),并且自定义任务将在内部使用服务连接上提供的凭据来执行部署。

    我认为这种方法是解决初始问题的最佳解决方法,并且可以扩展以解决其他类型资源(如数据库、共享文件夹等)中的粒度问题,只需简单地添加另一个特定的自定义服务连接(以指定资源和部署凭据)和一个链接的自定义任务,该任务仅允许针对该资源进行部署。

    唯一的缺点是,如果您想设置部署批准,则必须在资源级别(对于每个 webapp、每个 DB,...)进行,这意味着批准者必须批准在部署时也逐个资源地进行部署(而不是像我理解的那样对整个应用程序部署进行一次批准)

    你们觉得呢?在开始编码之前有什么说明吗?

    问候。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-10-22
      • 2021-07-30
      • 1970-01-01
      • 2021-12-30
      相关资源
      最近更新 更多