在 CI 流水线中使用政策控制器

本页面介绍如何通过创建持续集成(CI)流水线来集成政策控制器与 Cloud Build,该流水线可以检查与 Git 代码库同步的政策验证。

如果您是开发者,并且希望根据公司政策验证您的应用,请参阅在持续集成流水线中根据公司政策验证您的应用

简介

使用政策控制器创建 CI 流水线可以使您:

  • 强制执行已定义的政策配置,并尽快向开发者提供反馈。政策允许平台管理员锁定访问。然后,开发团队必须遵守这些政策,而不是删除或规避它们。

  • 在 Kubernetes 对象上设置应始终存在的默认字段。例如,您可以自动为所有者或成本中心添加标签。

本文档重点介绍使用 GitHub 配置代码库的 Cloud Build CI 流水线。您可以使用相同的模式来设置 Anthos Config Management 支持的其他 CI 工具或版本控制系统。

该流水线使用 KPT 函数构建。KPT 函数使您能够开发客户端容器映像来验证、转换或生成 Kubernetes 配置。

本主题使用 KPT 函数目录中的预构建 KPT 函数。目录中的部分函数已镜像到 Google 支持的 Container Registry,并且可用于所有项目。

准备工作

  • 您必须具有 Anthos 授权才能使用 Anthos Config Management 安装政策控制器。

  • 您需要一个已安装 Anthos Config Management 的集群。

  • 设置政策控制器

  • 您的 Google Cloud 项目具有 serviceusage.services.enable 权限,并且 Cloud Build API 具有 servicemanagement.services.bind 权限。这些权限是启用 Cloud Build 服务帐号所必需的,请参阅启用 API 上的更多详细信息。

  • 在您的项目中启用 Cloud Build。这可以通过 Google Cloud Console 完成。

使用非结构化代码库

本教程包括使用非结构化代码库的选项。非结构化代码库不需要默认的 Anthos Config Management 目录结构

配置 Cloud Build

您必须将“Kubernetes Engine 开发者”角色授予配置流水线的每个项目中的 Cloud Build 服务帐号。

  1. 打开 Cloud Build 的“设置”页面

    出现服务帐号权限页面。

  2. 找到包含 Kubernetes Engine 的行,并将状态设置为 Enabled

如需了解更多信息,请参阅设置服务帐号权限

设置环境

要将政策控制器配置为可与 Cloud Build 一起使用,请参阅示例 Git 代码库

使用 git 克隆仓库。

git clone git@github.com:GoogleCloudPlatform/csp-config-management.git

如果您使用的是分层代码库,则必须在设置 Cloud Build 之后编辑此代码库中的配置文件。

目录结构

在代码库 csp-config-management 中,有两个目录,其中包含用于分层代码库(ci-pipeline/)和非结构化代码库(ci-pipeline-unstructured/)的配置。选择适合您的集群类型的目录。

代码库中的 ci-pipeline/ci-pipeline-unstructured/ 目录使用以下层次结构:

  • config-root/ 是代码库的根,并且包含此示例的所有配置。

  • config-root/.../*-constraint.yaml*-template.yaml 定义政策控制器限制条件和模板,config-root/ 中的所有配置都必须通过这些限制条件和模板。

    例如:

    • 文件 ci-pipeline/config-root/cluster/required-labels-constraint.yaml 要求每个命名空间必须具有 cost-center 标签。

    • 文件 ci-pipeline-unstructured/config-root/constraints/banned-key-constraint.yaml 强制 ConfigMap 对象不包含名为 private-key 的字段。

    如需了解更多信息,请参阅创建限制条件

  • cloudbuild.yaml 是定义构建步骤的 Cloud Build 配置文件。这些构建步骤是由对代码库的提交触发的。

    使用分层代码库,流水线使用 nomos hydrate 构建代码库的内容,将它们连接起来,并使用政策控制器对其进行验证。

    在非结构化代码库中,政策控制器无需使用 nomos 或连接到集群即可构建您的配置。

    如需了解有关配置文件内容的更多信息,请参阅创建基本配置

配置 Cloud Build

在本部分中,您将 Cloud Build 连接到您的源代码库,以便 Cloud Build 可以在该代码库中构建代码。

创建构建触发器

当提交被推送到分支时,Cloud Build 将执行构建触发器。要在 Google Cloud Console 中配置构建触发器,请执行以下步骤。

  1. 打开 Google Cloud Console 中的触发器页面。

    打开“触发器”页面

  2. 从页面顶部的项目选择器下拉菜单中选择您的项目。

  3. 点击打开

  4. 点击创建触发器

  5. 为触发器创建一个名称

  6. 对于事件,选择推送到分支

  7. 选择您的代码库。如果尚未连接存储库,请完成以下步骤:

    1. 点击连接代码库

    2. 选择您已在其中存储源代码的代码库。

      如果您选择 GitHub(已镜像)Bitbucket(已镜像)作为源代码库,则 Cloud Build 会镜像 Cloud Source Repositories 中的代码库,并使用已镜像的代码库。

    3. 点击继续

    4. 使用您的用户名和密码向您的源代码库进行身份验证。

    5. 从可用代码库列表中,选择所需的代码库,然后点击关联代码库

  8. 从可用代码库列表中,选择代码库 csp-config-management

  9. 选择您的分支master

  10. 构建配置下,将 Cloud Build 配置文件设置为 ci-pipeline/cloudbuild.yamlci-pipeline-unstructured/cloudbuild.yaml

  11. 点击创建以保存您的构建触发器。

您也可以使用 gcloud 创建构建触发器。如需了解更多信息,请参阅创建和管理构建触发器

配置您的代码库

将 Cloud Build 配置为连接到您的代码库后,完成对 Anthos Config Management 的配置。

  1. 修改文件 csp-config-management/CODEOWNERS,并将@OWNER替换为您的 GitHub 用户名或平台管理员团队的电子邮件别名。如需了解有关 CODEOWNERS 语法的更多信息,请参阅关于代码所有者

如果您正在使用下面的分层(默认)代码库或非结构化代码库,请选择。

  1. 修改配置文件

    分层

    修改文件 csp-config-management/ci-pipeline/cloudbuild.yaml

    CLUSTER_NAMEZONE 替换为安装了 Anthos Config Management 和政策控制器的 GKE 集群的集群名称和区域。

    非结构化

    在此示例中,对于非结构化代码库,无需更改配置。Anthos Config Management 和政策控制器无需连接到集群即可验证您的代码库。

  2. 添加更改并将其提交到代码库。

    分层

    cd ci-pipeline
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    非结构化

    cd ci-pipeline-unstructured
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    提交后,Cloud Build 在代码库上运行政策验证。

  3. 打开 Cloud Build 历史记录,然后单击最近一次构建

    出现构建详情页面。

  4. csp-config-management 代码库中的样本包含一个错误。

    从列表顶部选择包含 图标的最近一次构建。

  5. Cloud Build 运行的最后一步会因错误而终止。随之出现错误。

    分层

    Error: Found 1 violations:
    [1] All namespaces must have a cost-center label that points to your division
    name: "shipping-prod"
    path: namespace_shipping-prod.yaml

    非结构化

    Step #2: Error: Found 1 violations:
    [1] The following banned keys are being used in the config map: {"private_key"}
    name: "super-secret"
    path: configmap.yaml

  6. 接下来,通过编辑代码库中的文件来修复错误。

    分层

    编辑文件 /ci-pipeline/config-root/namespaces/online/shipping-app-backend/shipping-prod/namespace.yaml,并为 metadata.labels.cost-center 设置一个值。您的 namespace.yaml 应该如下所示:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: shipping-prod
      labels:
        env: prod
        cost-center: "shipping.foo-corp.com"
      annotations:
        audit: "true"
    

    非结构化

    修改文件 /ci-pipeline-unstructured/config-root/configmap.yaml。 将名为 data.private_key 的字段更改为 data.public_key。您编辑的 YAML 如下所示。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: super-secret
      namespace: default
    data:
      public_key: no secrets here
    

    接下来,提交并推送您的更改。

    git add .
    git commit -m "[COMMIT_MESSAGE]"
    git push origin [BRANCH]
  7. 打开 Cloud Build 历史记录,然后单击最近一次构建

    出现构建详情页面。

  8. 您的新构建应该成功

问题排查

问题:我的 Cloud Build 构建失败,并且历史记录包含以下错误。

  [1] KNV1021: No CustomResourceDefinition is defined for the type "ConstraintTemplate.templates.gatekeeper.sh" in the cluster.
  Resource types that are not native Kubernetes objects must have a CustomResourceDefinition.

解决方案:确认安装政策控制器

后续步骤