Argo CD在多租户环境中的安全设置与应用项目管理

Argo CD的一大亮点是其强大的用户界面（UI），可以实时显示所有应用及其相关Kubernetes资源的状态。无论是开发人员还是运维人员，都可以通过查看UI并深入各个视图来快速了解其应用部署的状态。一些团队甚至将Argo CD UI用作通用的Kubernetes仪表板和管理界面，尤其是自带有基于Web的终端功能后。

随着组织规模扩大和使用 Argo CD 范围的增加，他们意识到要在不同的团队之间使用单个 Argo CD 实例，必须具备适当的安全部控措施。Argo CD 被设计支持多租户环境，并提供了全面的控制措施，以限制和隔离不同开发团队的应用程序。这使得操作员可以定义谁可以访问哪些应用程序及其访问权限。

在本文中，我们将分析各个构建模块（应用项目（详情）、安全策略（详情）、用户组以及角色），并向您展示如何为您的组织设置一个多租户 Argo CD 安装。

每个组织在风险管理和管理便捷性方面有不同的要求。我们见过团队在多租户或多用途环境中使用Argo CD的各种偏好，包括使用和不使用。

首先，我们有开发者可以完全访问 Argo CD UI 的用例，他们可以使用全部权限调试、同步和编辑他们的部署。在这种情况下很好，如果您的开发者已经具备一些 Kubernetes 的知识，并且已经了解 GitOps 的原则。

当您的团队变大到一定程度时，您就需要设定一些限制，尤其是在较大的开发团队来说，这是非常必要的。比如，开发人员通常可以完全访问非生产环境，但只能只读访问生产环境。他们可以查看生产环境的状态，还可以检索日志，但不能更改部署中的任何设置。

可以对开发人员施加非常严格的限制。Argo CD支持将开发人员隔离到特定的命名空间和集群中，从UI中隐藏不相关的应用程序，甚至为不同的应用操作设置不同的访问权限。例如，一个开发人员可能可以提取Argo CD应用程序的日志，但他们不能触发应用程序的重新同步。

在光谱的另一端，有些组织选择完全不让开发人员接触到 Argo CD。Argo CD 仅限于运营人员使用。开发人员通过一个外部系统与他们的应用程序交互，该系统通常在 Argo CD 之上，并抽象了多个 Kubernetes 相关的概念（例如内部的开发人员平台或门户）。

在所有情况下，重要的是决定是否允许开发人员自行开发新的应用程序，还是只允许他们对现有应用程序进行修改。你还需要考虑，如何处理临时环境（如预览环境）。

这里有三个重要的点要记住：

1. Argo CD 自带基于角色的访问控制（RBAC）机制，这些机制与 Kubernetes 的 RBAC 无关。
2. 有几个组成部分相互协调（单点登录（SSO）、角色、应用项目（app 项目））。
3. 本指南针对的是内部用户。如果您希望为外部用户和客户提供多租户支持，您可以参考其他方法（观看此视频）。

当然，并不存在一刀切的解决办法。也不可能在一个指南中涵盖所有的变化。现实中，你会看到几种不同的设计样式。

将本指南视为 Argo CD 安全控制的轻松入门。我们将为您解释这些安全控制背后的理论，并分享一个接近真实的示例，以帮助您了解如何在自己的组织中实现多租户。

在讨论多租户环境下的 Argo CD 安装时，会有两个不同的方面。

1. 限制应用部署的范围。哪些 Kubernetes 资源可以被部署，以及可以从哪些 Git 仓库进行部署。
2. Argo CD 资源的安全控制。谁可以查看、同步和删除应用等。

这两个方面是独立的，通过应用项目资源相互联系。

拼图的其他部分如下：

1. 用户、组以及 SSO 配置（单点登录）
2. 本地用户（可选）
3. 全局安全规则和 每个项目的安全策略
4. 将策略按角色分组
5. Argo CD 资源操作权限
6. 其他相关应用资源，例如集群、命名空间和 Git 仓库

在接下来的部分，我们会简单介绍一下所有这些组成部分。

我们从 Argo CD 的资源（即应用程序）开始吧。Argo CD 资源背后的 RBAC 模型遵循“谁-什么-如何”这一模式。资源通过 RBAC 策略来保护安全。基本上，你可以定义谁可以访问哪些应用以及他们能以什么方式访问。

虽然 Argo CD 可以针对单个对象定义安全控制（例如“允许 David 编辑应用计费”），但实际上，更实用的方法是将类似对象分组。策略中的各个部分大多是在组之间应用，而不是针对单个对象。

在您定义了所有组、角色和应用后，您可以在全局或项目级别应用策略和政策。
您可以通过casbin格式定义策略，并遵循该格式的语法规则。

p, <角色/用户/组><资源><操作><目标><结果>

这里的p代表政策。

这里有几个政策的例子：

    “p, 只读: 基础设施, 应用, 读取, */基础设施, 允许读取”

这项政策说：“所有属于infra只读组的用户都可以查看或获取infra应用程序项目中的所有应用程序。”

再举一个例子：

p, 全权限:开发者, 生产/* 删除, 拒绝

此政策规定，属于开发人员full-access组的所有用户不允许删除prod应用项目中的应用程序。

可以在这里找到有关可用操作动作和资源类型的详细信息，请参阅官方 Argo CD 文档。

重要的是，你需要做一些分析并将所有的 Argo CD 应用分成不同的项目。不同的组织可能会给项目赋予不同的含义。一个项目可以是特定的团队、部门、环境，或任何在你们的组织中对应用组有意义的东西。我们建议为每个团队（无论是开发团队还是基础设施团队）创建一个项目。

在你定义完所有策略后，你应该将它们（声明式地地）存储在你的应用项目 .spec.roles 中。

第二个重要点是，与其它安全设计不同的是，在 Argo CD 中，“角色”指的是一个策略资源集合。首先创建应用项目，接着给这个项目应用策略，最后将策略与用户关联。

这意味着你需要预测和规划应用程序将如何被使用，并设计相应的角色。例如，这种情况下，一组开发人员只能查看 Argo CD 中的所有应用程序，但仅限于“只读”模式，那么你需要在所有相应的应用程序项目中创建一个“只读”权限策略。

RBAC 策略定义了用户如何与 Argo CD 的主要资源（即应用程序）进行交互。应用项目还具有额外的安全性功能来保护 Kubernetes 资源的安全。

记住，Argo CD应用程序本质上只是一个Git仓库和Kubernetes集群/命名空间之间的连接。在多租户环境中，你几乎总是需要限制某些方面，例如相应的权限。

1. 开发者可以部署到哪些集群和命名空间
2. 哪些 Git 仓库和路径可以用来部署应用
3. 哪些 Kubernetes 资源可以被部署影响
4. 可选地，部署可以在什么时间进行

默认的项目是一个什么都能通过的项目，没有任何限制条件。

spec:  
  sourceRepos:  
  - '*'  # 源仓库  
  destinations:  
  - namespace: '*'  # 命名空间  
    server: '*'  # 服务器  
  clusterResourceWhitelist:  
  - group: '*'  # 组  
    kind: '*'  # 类型

使用默认项目来试验 Argo CD 很棒，但我们建议不要在生产环境中使用它，并且只定义自己的项目，而不是使用默认项目。

应用程序项目在处理集群资源时非常灵活。您可以将开发人员限制在特定的命名空间和特定类型的资源，并通过使用sync windows来指定特定的部署日期。

这里有一个应用项目的例子：

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-revenue
  namespace: argocd

spec:
  description: 收入团队的开发人员组成的小组

  sourceRepos:
  - "https://github.com/acme/revenue/*"

  destinations:
  - namespace: "revenue"
    server: https://kubernetes.default.svc

clusterResourceBlacklist:
- group: ""
  kind: "Namespace"

namespaceResourceBlacklist:
- group: ""
  kind: "ResourceQuota"
- group: "networking.k8s.io"
  kind: "NetworkPolicy"

这个项目定义了“收入团队”能做些什么。

1. 他们只能从 acme/revenue 下的 Git 仓库进行部署。
2. 他们只能在本地集群中使用 “revenue” 命名空间。
3. 他们不能创建新的命名空间、资源配额和网络策略。

尽管 argocd CLI 包含多个用于管理项目的命令，但我们建议你在 Project CRD 中声明所有内容，并在生产环境中采用声明式的配置。

我们已经看到，在多租户环境中，应用项目是Argo CD安全的核心。

让我们来看一个完整的例子。在我们虚构的公司里，有两个开发团队（A 和 B）不断部署应用程序。还有一个由运维团队负责的基础设施应用（比如 cert-manager）。

我们的要求如下：

• 管理员/操作员可以查看/编辑所有应用程序（包括基础设施应用程序）。
• 团队 B 只能查看/编辑他们自己的应用程序，不能查看或编辑其他团队的应用程序。
• 团队 A 可以查看和编辑他们自己的应用程序，并且只能查看团队 B 的应用程序，但不能编辑。
• 两个团队的开发人员都不能查看基础设施应用程序。
• 任何开发人员都不能删除任何应用程序（即使是他们自己的）。
• 所有应用程序（包括基础设施应用程序）只能从特定的 GitHub 组织或用户的仓库同步。

您可以在https://github.com/kostis-codefresh/intro-argocd-rbac 找到所有 Argo CD 的设置。请留意，为了简便，我们使用了本地用户而不是单点登录。

我们总共有4个应用——每个团队一个，另外还有两个基础设施相关的应用。Argo CD的管理员可以看到所有的应用，并可以对它们进行任何操作。

团队B的开发者是最受限制的那群人。他们只能看看自己的应用，其他任何东西都看不见。

他们可以随时同步，但就是删不掉这个应用。点击删除按钮会弹出错误提示。

团队A的开发者可以查看两个团队的应用程序，但看不到这些基础架构应用程序。

即使他们可以同步和编辑他们自己的应用程序，也无法影响团队B的应用程序。如果他们尝试同步团队B的应用程序，又会收到错误信息。

有了这个设置，我们已经满足了最初的条件。让我们来看看背后，看看这一切是如何做到的。

注释:每个团队都用一个应用

在介绍中，我们提到用应用项目来代表团队。在我们的例子中，定义了三个项目，每个团队一个项目（A、B和infra（基础设施））。在这里可以查看这些项目的定义。

最有趣的项目是由团队B提出的。

apiVersion: argoproj.io/v1alpha1  
kind: AppProject  
metadata:  
  name: team-b  
  namespace: argocd  
  finalizers:  
    - 最终处理程序: resources-finalizer.argocd.argoproj.io    
spec:  
  描述: Team B  
  目标:  
  - name: '*'  
    namespace: '*'  
    server: '*'    
  roles:  
  - 描述: 只读  
    name: read-only  
    策略:  
    - p, proj:team-b:read-only, applications, 获取, team-b/*, 允许  
  - 描述: 读写  
    name: read-write  
    策略:  
    - p, proj:team-b:read-write, applications, 获取, team-b/*, 允许  
    - p, proj:team-b:read-write, applications, 同步, team-b/*, 允许  
    - p, proj:team-b:read-write, applications, 更新, team-b/*, 允许          
  sourceRepos:  
  - https://github.com/kostis-codefresh/intro-argocd-rbac.git

我们在这里定义了两个角色（一组策略），请注意，一个是团队B的“读写”权限，另一个是团队A的“只读”权限。这两个角色都不包含“删除”的权限，这意味着任何开发人员都无法删除项目中的应用程序。最后，我们还限制应用程序源代码库只能访问特定的GitHub项目。

一旦我们有了AppProjects，我们会通过一个应用集来部署全部4个应用。如果你还不了解应用集，请阅读我们的应用集指南。

这个applicationset会自动将每个应用与其父文件夹相同的AppProject关联起来。

这算是首次应用部署结束了。

为了简化，例如我们使用本地用户。在实际系统中，你会用SSO将用户分配到相关的Argo CD组。

在我们的情况下，我们在 argocd-cm 中分别添加了两个用户，一个用于团队 A，另一个用于团队 B。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
  labels:
    app.kubernetes.io/name: argocd-cm
    app.kubernetes.io/part-of: argocd
data:
  accounts.jane: apiKey, login
  accounts.jane.enabled: "true"
  accounts.david: apiKey, login
  accounts.david.enabled: "true"

你可以为本地用户设置密码，使用 argocd account update-password 命令，或者通过声明性配置来完成。

最后，我们将每个用户分配到相应的角色。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
  labels:
    app.kubernetes.io/name: argocd-rbac-cm
    app.kubernetes.io/part-of: argocd
data:
  policy.csv: |
    g, jane, proj:team-a:读写权限
    g, jane, proj:team-b:只读权限
    g, david, proj:team-b:读写权限

在这里你可以看到，简（Jane）属于团队A。她可以读写团队A的所有应用，而只能读取团队B的项目。大卫则在团队B，只能看到自己的项目。

简和戴维都不能看到“基础设施”项目的任何申请案，这原本是最初的要求之一。

这标志着设置结束。你现在可以用Admin、Jane或David的账号登录Argo CD用户界面，只能看到各自被允许查看和编辑的内容。

本指南是对 Argo CD RBAC 的入门介绍，以及如何在多用户场景中使用 Argo CD。还有许多其他内容可以探索，例如 appProject 层级结构、特定的 SSO 设置、复杂的策略等。现在你可能已经对你的组织有了很多好主意，并且理解了所有这些组件是如何协同工作实现多租户的。

安全是一个复杂的领域。请将本指南作为你组织安全旅程的起点。你应该始终按照你安全团队的建议和最佳实践以及相应的安全要求行事。