使用 Anthos Config Management 和 GitLab 管理政策的最佳做法

本文档重点介绍了如何使用 Anthos Config Management 和 GitLab 管理生产环境中的多个 Kubernetes 集群。确保 Anthos Config Management 代码库安全是一个重要的部署步骤,本文档可帮助您完成此过程。如果您正在部署 Anthos Config Management 用于生产环境,则本文档会很有帮助。本文档假设您熟悉 Kubernetes 和 Git。

如果您运行的平台为您的组织托管应用,则制定相关政策来保护该平台是很重要的一项工作。政策是一些旨在保护平台以及平台上的应用和数据的规则。平台会根据描述政策的配置来实施这些政策。政策实施有助于提高平台的安全性和稳定性。

Anthos Config Management 可帮助您为基于 Google Kubernetes Engine (GKE)Anthos GKE 或其他 Kubernetes 发行版构建的平台规模化地管理政策。借助 Anthos Config Management,您可以同时跨多个集群创建和管理 Kubernetes 对象。您可以用 Anthos Config Management 管理任何 Kubernetes 对象,不过,它在强制执行以下政策时尤为有用:

  • PodSecurityPolicies:阻止 Pod 使用 Linux 根用户。
  • NetworkPolicies:控制集群内的网络流量。
  • ClusterRolesClusterRoleBindings:控制集群内的权限。

如下图所示,Anthos Config Management 是一种 GitOps 式工具;它将 Git 代码库用作其存储机制和可靠来源。

Git 中 Kubernetes 配置的架构。

借助 Anthos Config Management,您可以通过与此 Git 代码库交互来部署和管理 Kubernetes 对象。获取对 Anthos Config Management Git 代码库的主分支的写入权限意味着成为 Anthos Config Management 所管理的集群的管理员。Anthos Config Management 代码库包含对潜在攻击者有用的信息,因此确保 Anthos Config Management 代码库安全这一点非常重要。

本文档将 GitLab Source Code Management (SCM) 用作 Git 代码库托管服务,概述了同时使用 Anthos Config Management 和 GitLab 管理多个 Kubernetes 集群的最佳做法。

Anthos Config Management 和 GitLab 架构

下图展示了用于管理以下三个 Kubernetes 集群的 Anthos Config Management 和 GitLab 的部署架构:一个位于 GKE、一个位于 GKE On-Prem,另一个位于其他云服务提供商。

Anthos Config Management 和 GitLab 的部署架构。

上图展示了流水线中的以下步骤:

  1. 如需对这些集群中的一个或所有集群进行配置更改,用户需要提交一个名为合并请求 (MR) 的修改,该修改必须在 GitLab 中进行验证。
  2. MR 会通过 GitLab 内置的持续集成和交付系统 GitLab CI/CD 触发自动流水线,以测试和验证配置。
  3. MR 由管理员批准或拒绝。批准后,更改会合并到 Git 代码库中。
  4. 批准后,在每个集群中运行的 Anthos Config Management 代理会从 GitLab 中读取此修改并将其应用于这些代理的集群。

Anthos Config Management 场景中 GitLab 托管的最佳做法

在本部分中,我们推荐了在使用 GitLab SCM 托管和管理 Anthos Config Management 代码库时应遵循的最佳做法。有关托管 GitLab 的一般最佳做法(例如设置高可用性架构和定期备份)同样也适用,但这些做法不在本文档的讨论范围内。

限制管理员权限

任何拥有对托管 GitLab 的虚拟机(或 Kubernetes 集群)的根访问权限的人员都可以绕过 GitLab 安全功能,因此应被视为 Anthos Config Management 的管理员。对于作为 GitLab 管理员的任何人或拥有对 GitLab 数据库的写入权限的任何人,该假设同样也成立。如果您授予人员 GitLab 管理员权限、对托管 GitLab 的虚拟机(或 Kubernetes 集群)的根访问权限,或对 GitLab 数据库的访问权限,则这些人员也可以在 Anthos Config Management 中进行更改。如需了解详情,请参阅 GitLab 的权限文档

如果您使用的是 Compute Engine,请使用 Identity and Access Management (IAM) 和 OS Login 服务来控制谁有权访问实例。具体来说,Compute OS Admin Login 角色会授予对实例的根访问权限。

如果您使用的是 GKE,请使用 IAM 和 RBAC 来控制谁可以访问集群。

不断更新

GitLab 每月都有一个发行版本,并且各发行版本之间有多个补丁程序版本。与任何软件一样,GitLab 会在某些发行版本中提供安全补丁程序。因此,您应尽可能使 GitLab 实例保持最新版本。如需了解详情,请参阅更新 GitLab

遵循针对 Google Cloud 的最佳做法在 Google Cloud 上托管 GitLab

如果您在 Google Cloud 上托管 GitLab,则应将一个 Cloud 项目专用于 GitLab。您应将此 Cloud 项目直接放在组织节点下,而不是放在文件夹中。这些建议可以降低出现以下 IAM 配置错误的可能性:

  • 如果 GitLab 与其他应用共享一个 Cloud 项目,则在授予对其他应用的访问权限时,您可能会有无意中授予对 GitLab 的管理员权限的风险。
  • 如果您将该 Cloud 项目放在文件夹中,则可能会因授予对该文件夹的访问权限而有无意中授予对该 Cloud 项目的访问权限的风险。

如果您要在 Google Cloud 上部署 GitLab,我们还建议您利用以下代管式服务:

如需了解详情,请参阅在 Google Kubernetes Engine 上部署可正式投入使用的 GitLab

GitLab 的身份验证和访问权限控制

为便于审核和调试,您必须能够确定谁更改了政策,而且您的 IT 人员也使用这些身份来管理各种资源。

使用统一的身份

根据设计,您通过在其中创建、更新和删除资源的 Git 代码库与 Anthos Config Management 进行交互。您可以在 Git 代码库控制哪些用户可以执行哪些操作以及审核所有活动。如果您的员工在任何位置都使用相同的身份(在 Google Cloud、GitLab 和本地系统中),则更便于实现访问权限控制和审核。统一的身份可让您跨不同系统交叉引用权限和审核日志。

在 GitLab 中,您可以跨群组、项目和实例审核事件,并查询系统日志以获得 GitLab 服务等级事件。GitLab 审核事件功能涵盖企业许可的层级。

如果您没有将 Google 用作身份提供商

您可以将 Google Cloud 与许多常用的 IdP(如 Active DirectoryAzure Active DirectoryOkta)联合。可以将 GitLab 配置为使用 Active DirectoryOkta

在将 Google 用作身份提供商的情况下

如果您将 Google 用作身份提供商,则可以使用 Google OAuth 2.0 OmniAuth 提供程序安全 LDAP。但是,如果您希望按照下一部分的建议将群组与 GitLab 同步,则需要使用安全 LDAP。安全 LDAP 适用于 Cloud Identity 专业版和 Google Workspace 企业版。如需了解详情,请参阅关于安全 LDAP 服务

将群组与 GitLab 同步

无论用于识别用户的技术为何,对用户进行分组来配置其访问权限都是很有用的。群组让您可以在授予权限时在更高级层考虑这些用户:“我向我的运营组授予对生产环境的管理员权限”,而不是“我向 Alice、Bob、Claudia 和 Dinesh 授予对生产环境的管理员权限”。如果您的人力资源流程与您的 IT 系统完美集成,则系统会在员工入职、离职或变更角色时自动管理群组成员资格。如果您使用群组,则此集成意味着您通常不必更新访问权限控制设置。

由于 Anthos Config Management 是一个敏感系统,因此依赖用户群组来控制对 Anthos Config Management 的访问权限非常重要。在 GitLab 中,您可以与一组用户共享项目,并指定该组成员获得的访问权限级别。

强制执行双重身份验证

您应使用双重身份验证 (2FA)(也称为两步验证),以提高您组织的安全性。凭据被盗和网上诱骗攻击是两种常见的攻击途径,2FA 有助于防止这两种攻击。由于 Anthos Config Management Git 代码库的敏感性,您应尽可能保护与 Anthos Config Management 交互的用户帐号,即为这些用户启用 2FA。

如果您为 GitLab 配置了单点登录 (SSO),则应通过 SSO 提供商强制执行 2FA。如果您将 Google 用作 SSO 提供商,则可以启用 2FA

如果您没有为 GitLab 配置 SSO,则可以直接在 GitLab 上强制执行 2FA

使用部署密钥或部署令牌将 Anthos Config Management 代理连接到 GitLab

安装 Anthos Config Management 文档所述,您可以使用常用 Git 方法 HTTP 或 SSH 将 Anthos Config Management 代理连接到代码库。如果您使用 HTTP(s) 访问托管在 GitLab 上的代码库,请不要使用用户帐号,否则可能会带来许可以及用户使用自己的帐号来配置 Anthos Config Management 等问题。从 GitLab 中获取部署密钥部署令牌是更好的替代方案。部署密钥是一种未与特定用户关联但自动化系统可用来执行 Git 操作的 SSH 密钥,这是 Anthos Config Management 所需的安全访问权限类型。部署令牌的用法与部署密钥相同,但您可以使用部署令牌通过 HTTP(s)(而非 SSH)进行身份验证。

唯一部署密钥和部署令牌让您可以按集群控制和撤消 Anthos Config Management 代理对 Git 代码库的访问权限。避免对 Anthos Config Management 和组部署令牌使用全局部署密钥。您可以将它们用于 Anthos Config Management 之外的其他用途;如果用于 Anthos Config Management,则会在配置发生更改时产生意外的负面效果。

管理谁可以批准合并请求

默认情况下,GitLab 使用角色来授予 GitLab 项目的权限。例如,具有 Developer 角色的用户可以打开合并请求,而具有 Maintainer 角色的用户可以批准该请求。虽然此权限系统最初可以非常适合 Anthos Config Management,但随着 Kubernetes 和 Anthos Config Management 占用空间的增加,您可能会遇到问题。Anthos Config Management 代码库的维护者可能会因必须处理和批准的合并请求数量增加而不堪重负。

您可以利用 GitLab 的高级功能来帮助解决此问题:

  • 您可以使用 Code Owner 基于文件或目录委托批准权限。此功能非常有用,因为 Anthos Config Management 使用目录结构来描述集群和命名空间。例如,使用 Code Owner,您可以授予对所有集群中特定命名空间的批准权限。
  • 您可以使用合并请求批准,要求不同团队中的不同人员在请求合并前先批准请求。例如,您可以要求两位审批人(分别来自运营团队和安全团队)来批准合并请求。

下图展示了组织的技术部门,并演示了批准委托在生产环境中的工作原理。

组织中层次结构的示例架构。

上图中包含一位首席技术官 (CTO),有多个团队向其汇报:安全团队、平台团队和多个应用团队。

该组织的 Anthos Config Management Git 代码库具有以下结构(仅显示目录,不显示文件):

.
├─ system
├─ clusterregistry
├─ cluster
└─ namespaces
   ├─ cicd
   ├─ audit
   └─ applications
      ├─ team-a
      └─ team-b

如需详细了解每个目录,请参阅使用 Anthos Config Management 代码库

通过此结构,组织可以使用前面提到的 GitLab 功能来实现以下过程:

  • 对代码库根目录或 system 目录的任何修改都必须获得 CTO 的批准。
  • clusterregistry 目录的任何修改都必须获得平台团队成员的批准。
  • cluster 目录的任何修改都必须获得平台团队成员和安全团队成员的批准。
  • namespaces 目录的任何修改都必须获得平台团队成员的批准。
  • namespaces 目录中的子目录的任何修改都必须获得以下团队的批准:

    • cicd 子目录代表专用于持续集成和持续交付 (CI/CD) 工具的命名空间。任何更改都必须获得平台团队成员的批准。
    • audit 子目录代表专用于审核工具的命名空间。任何更改都必须获得安全团队成员的批准。
    • applications 子目录包含为每个应用命名空间创建的所有资源。任何更改都必须获得平台团队成员和安全团队成员的批准。
    • team-ateam-b 子目录代表专用于团队 A 和团队 B 的命名空间。任何更改都必须获得该团队负责人的批准。

如果来自身份提供商的群组与 GitLab 同步,则实施此过程会必未同步的情况下更容易。您可以针对合并请求要求获得不同群组的不同批准。如需了解详情,请参阅将群组与 GitLab 同步修改批准

停用共享运行程序

您可以使用 GitLab CI 自动测试 Anthos Config Management 政策,然后再部署该政策。GitLab CI 使用运行程序来运行您所需的作业。这些运行程序可以与整个 GitLab 实例共享,在这种情况下运行程序由与 GitLab 实例本身相同的团队进行维护,也可以专用于 GitLab 组或 GitLab 项目。

由于 Anthos Config Management 代码库的敏感性,您应避免使用共享运行程序来测试 Anthos Config Management 代码。而应使用专用于 Anthos Config Management 项目并由可以批准合并请求的人员进行维护的运行程序。

建议总结

本部分总结了前面几个部分中的建议。如果您使用 GitLab 托管 Anthos Config Management Git 代码库,我们建议以下做法:

  • 控制谁拥有对 GitLab 的管理员权限,因为这些人员还会获得对 Anthos Config Management 的管理员权限。
  • 定期更新 GitLab,每当发布安全补丁程序时就进行更新。
  • 如果您在 Google Cloud 上托管 GitLab,请在组织节点下将 Cloud 项目专用于 GitLab。
  • 将所有系统(包括 GitLab)配置为使用相同的身份提供商。
  • 如果可能,请使用 GitLab 企业版的许可功能 LDAP 群组同步将现有用户群组与 GitLab 同步。
  • 对与 Anthos Config Management 交互的用户强制执行 2FA,以加强防范凭据被盗及网上诱骗问题。
  • 配置 Anthos Config Management 代理时,请采用以下做法:
    • 配置 Anthos Config Management 代理以使用 SSH 和部署密钥或 HTTPS 和部署令牌来连接到 GitLab。
    • 避免使用未加密的 HTTP。
    • 为您的 Anthos Config Management 代码库中的每个 Kubernetes 集群创建唯一的部署密钥或部署令牌。
    • 直接在 Anthos Config Management 代码库中配置部署密钥和部署令牌,并避免对 Anthos Config Management 使用全局部署密钥和组部署令牌。
  • 注意批准 Anthos Config Management 代码库中的合并请求时出现的延迟。如果您发现这些延迟出现不合理的增加,请使用 Code Owner 或高级合并请求批准,将批准权限委托给您组织中的更多人员。
  • 对 Anthos Config Management 项目停用共享运行程序,并仅使用专用于此项目的运行程序。

后续步骤