在CircleCI中的CI/CD管线中实施访问控制策略

本教程包括。

1. GitHub中的受保护分支和安全组
2. 在CircleCI中使用上下文
3. 在CircleCI中设置审批工作

想象一下你在这种情况下。你是一个积极的、熟练的DevOps或DevEx工程师。你有一个计划来实现自动化的、完整的CI/CD管道。你知道如何去做，你也知道额外的生产力和自动化将使你的团队和整个公司受益。但由于安全问题，该项目从未被批准。

许多组织，特别是那些受管制的行业，对发布他们的软件有严格的要求，这也是理所当然的。谁可以触发发布，什么时候，在什么条件下，以及在发布前需要哪些具体的检查，都必须严格控制，可审计，可逆转。

这类复杂的过程通常需要一个专门的交付经理来收集并向公司的决策者委员会提交所有相关的功能简介、测试数据、安全评估和回滚计划。该小组可以给交付经理开绿灯，让他进行部署，通常也是在一个特定的时间表上。

还有一种方法。你可以建立有效的、完全自动化的CI/CD管道，包括人类交付经理和审批委员会可以完成的所有检查。本教程将向你展示为你的管道创建细化的访问控制的方法。你可以将这些方法用于严格监管的企业内部项目，也可以用于流行的开源项目。

前提条件

本教程假定您有CI/CD管道的经验，最好是有CircleCI的经验。 为了实现所涉及的步骤，您还需要有GitHub和CircleCI组织的管理员权限（以及这两个服务的账户）。

如果您没有GitHub组织的管理员权限，您可以在GitHub上创建一个免费的组织，并与免费的CircleCI账户一起使用它。

企业项目中CI/CD管线的访问控制

对于一个企业组织来说，遵循现有的检查并进行良好的沟通是至关重要的。这个过程通常包括在继续发布前对证明文件和对业务的潜在影响进行手动检查。 我将指导你实现一个管道，自动执行一些验证步骤，并在专门的交付经理手动批准后继续部署到生产。

为了实现访问控制，你需要设置一些东西。

• GitHub 中的受保护分支
• GitHub中的安全组
• CircleCI中的上下文
• CircleCI中的审批工作

受保护的分支

设置一个受保护的分支是设置访问控制的第一步。一个受保护的分支禁止团队成员直接向该分支推送代码，而是强制所有的修改都要通过拉取请求（PR）流程。通常情况下，你会保护你用来创建发布版本的分支；例如，main 。你可以在你的 repo 的设置中切换受保护的分支。

你还可以指定规则和例外情况，例如审查要求、合并前需要通过的检查、历史规则等等。

在我的例子中，我把main 分支设置为受保护分支，需要通过审核和 PR。

设置安全组

如果一个没有正确上下文权限的用户触发了CircleCI管道（例如，提交），那么需要该上下文的工作将被标记为403（未经授权）。

在我们的组织中，我们将设置两个安全组：development-leads 和delivery-managers

你组织中的所有开发人员都可以推送到他们自己的分支并发布拉动请求，但只有团队领导应该被要求审查任何新的拉动请求。只有在团队领导批准后，才能将修改合并到受保护的main 分支。然后，当交付经理得到发货的绿灯时，由他们来触发软件的发布。在本教程中，我们将为他们创建一个单独的安全组。

CircleCI将使用这些安全组与上下文来限制哪些工作可以由谁来执行，因此只有交付经理可以手动触发它们。

使用CircleCI的上下文

CircleCI的上下文有双重作用。一个作用是限制与作业共享的秘密的范围，而另一个作用是控制访问。

只有在工作流程中为其指定了上下文的工作才能使用上下文的秘密作为环境变量。在CircleCI中，上下文是在整个组织中共享的，因此它们可以在多个项目中重复使用。您可以使用CircleCI仪表板左侧的组织设置菜单来设置它们。

对于访问控制，您可以为任何上下文指定安全组。在本教程中，
，我们将创建一个名为release 的上下文，并为其指定delivery-mgrs 安全组。

现在你可以设置你的管道了。这个样本项目使用以下流程。

1. 测试
2. 安全扫描
3. 开发环境部署
4. 交付经理的审批工作
5. 生产部署

workflows:
 build-test-deploy:
   jobs:
     - test
     - security-scan:
         context: security
     - deploy-app:
         name: deploy-app-dev
         env: dev
         context: deployment-dev
         requires:
           - test
           - security-scan
         filters:
           branches:
             only:
               - main
     - approve-for-prod:
         type: approval
         requires:
           - deploy-app-dev
     - deploy-app:
         name: deploy-app-prod
         env: prod
         requires:
           - approve-for-prod
         context: release-prod
 

该管道使用环境变量的上下文，如我们的API密钥，但也使用release-prod 上下文。release-prod 上下文是有门槛的，所以它只能由交付经理使用。

设置审批工作

拼图的最后一块是审批工作：approve-for-prod 。从技术上讲，任何人都可以登录并批准这项工作。然而，紧随其后的deploy-app-prod 工作使用release-prod 上下文，它只接受交付经理的凭证。如果没有这些证书的人批准了它，发布作业就会失败，并出现unauthorized 的错误，整个管道将不成功地终止。

其他有用的部分

我们在工作流程中设置的一个额外控制是分支过滤器。由于这个过滤器，开发部署将只发生在main 分支上。main 分支被标记为受保护，因此将代码放到main 分支上的唯一方法是通过自动检查和代码审查，可能是由首席工程师进行。

你也可以使用专门的QA或安全审查步骤，需要手动批准。把它们作为链条的一部分以同样的方式构建。

开源项目的考虑因素

到目前为止，我们涵盖了访问控制的企业用例。大多数开放源码项目没有像企业那样严格的合规要求。相比之下，这些项目需要让他们的贡献向更多的人开放。这意味着允许更多的人去触发管道。

通常，发起并拥有一个受欢迎的开放源码软件项目的公司会继续雇用核心贡献者。他们可能会被其他不属于该公司的常规贡献者和维护者所加入。还有其他的人--任何偶尔会贡献一个修复或功能的人。

对于这种情况，你可以设置三个流程。

1. 公司内部流程。成员贡献，也管理一切。公司员工可能是唯一被允许发布新版本软件的人。我们可以称他们为 "内部核心贡献者"。
2. 半内部流。这些成员是组织的一部分，将能够直接推送到主要的开放源码库。他们将能够使用CircleCI的一切，包括用SSH调试作业和触发流水线。称他们为 "外部核心贡献者"。
3. 标准流程。社区中的其他贡献者，他们可以发布PR，否则就自己工作。我们将称他们为 "社区贡献者"。

对于社区贡献者来说，流程是标准的：建立一个分叉，然后打开一个拉动请求。你可以将CircleCI切换到建立拉动请求，自动验证他们的修改。

你仍然应该有一个受保护的分支，以及必要的检查。

对于核心贡献者群体，你可能还想包括一些秘密。秘密需要一些更多的工作。另外，通过分叉传递秘密本质上是不安全的。任何人都可以通过修改他们PR中的管道来提取你允许传递的任何秘密。这可能包括某些服务的API密钥，或者你的项目分布在哪里的凭证。

一个选择是完全避免向分叉传递秘密。你必须在审查后将任何代码推送到你自己的org，在那里它可以被执行，然后合并到你的默认分支。有一篇文章解释了这个过程，很有帮助。

另一个选择是允许向分叉传递秘密，但要防止这些秘密被分享，除非这些代码已经被团队成员彻底审查和批准。你可以在CircleCI项目设置中进行设置。

如果你切换了秘密，你将需要设置一个审批工作。把任何秘密放在一个上下文中，只有属于该上下文的人才能访问。

注意。 如果你使用这种方法，请确保你的组织中的所有上下文都指定安全组。如果你不这样做，恶意行为者可以在被执行的PR中猜出你的上下文名称并从中提取环境变量。

通过你的内部和外部贡献者的核心，你可以用非常相同的方式设置访问控制。也许只有内部核心可以发布新版本，但外部核心的任何人都可以合并任何拉动请求。或者你只是有一组核心维护者，他们可以做所有的事情。细节由你决定。

总结

在这篇文章中，我们探讨了如何通过设置访问控制来进一步保护你的CI/CD管线，将管线的一部分（以及相关的证书）封锁在有限的范围内。这是一种通用的方法，既适用于企业组织，也适用于开源软件项目。

我们在CircleCI中使用安全组、受保护的分支、上下文和审批工作来实现这一效果，既适用于OSS项目，也适用于专有项目。实验一下你的组织的最佳配置，并安全地发布你的应用程序。