GitOps 中的多租户支持
多租户是一种软件架构，其中单个软件实例为多个不同的用户组或租户提供服务。使用多租户，您可以共享单个 Argo CD 实例来部署资源，同时保持用户之间的隔离。本节帮助集群管理员了解 Argo CD 实例范围以及何时选择特定模式。
在 OpenShift 容器平台上使用 Red Hat OpenShift GitOps Operator，作为集群管理员，您可以为应用程序交付团队（租户）提供对集群的多租户访问。您可以允许租户在其用户定义的命名空间中创建和管理专用的 Argo CD 实例，而无需具有管理员权限。租户拥有完全自主权，可以根据自己的需求和要求定制此实例，而不会干扰其他租户。
|
对于多租户集群，管理 Argo CD 实例的人员可能不是管理集群及其用户的人员。因此，您不能将 Argo CD Application Controller（ |
Argo CD Application Controller 会协调托管集群中的资源。因此，要在 GitOps Operator 中使用多租户，根据您的用例、租户和需求，必须明确配置、授予、扩展或限制 Argo CD 实例、应用程序和远程集群上的特定权限才能执行某些操作。
Argo CD 实例范围
Red Hat OpenShift GitOps Operator 创建的实例可以大致分为以下模式，所有模式都支持多租户
-
命名空间范围实例（应用程序交付实例）
-
集群范围实例
-
默认集群范围实例
命名空间范围实例（应用程序交付实例）
在您的一个命名空间中创建 Argo CD 自定义资源 (CR) 后，GitOps Operator 将在此命名空间中启动一个 Argo CD，您可以将其用于应用程序交付。在其初始状态下，此实例仅具有在安装它的同一命名空间中部署资源的权限。但是，您可能需要配置实例以满足您的特定需求。
使用 GitOps Operator，您可以扩展 Argo CD 实例的权限，使 Argo CD 应用控制器能够将资源部署到其安装位置以外的其他命名空间。
|
GitOps Operator 在命名空间中创建的角色是命名空间范围的，并且只有访问命名空间资源的权限。Operator 无法在其管理的命名空间之外执行任何操作。 |
GitOps Operator 允许 OpenShift 用户在其命名空间中实例化 Argo CD 实例，只要他们有权在其命名空间的argoproj.io/v1alpha1 或 argoproj.io/v1beta1 API 中创建 Argo CD 资源即可。目前，命名空间范围的实例对其管理的一个或多个命名空间拥有完全的管理权限，类似于允许对该命名空间内所有资源执行所有动词。
为了使 Argo CD 应用控制器能够将资源部署到任何其他命名空间，您需要 Kubernetes 角色和角色绑定来标记和指示您希望命名空间范围的实例管理这些命名空间。GitOps Operator 支持使用argocd.argoproj.io/managed-by 标签来自动创建这些角色和角色绑定。使用此标签并将值设置为指示受管理的命名空间。然后，使用argocd.argoproj.io/managed-by 标签，当您以命名空间范围实例模式部署 GitOps Operator 时，它会在实例管理的每个命名空间中创建一组角色和角色绑定。
|
|
默认情况下，当使用managed-by 标签标记命名空间时，GitOps Operator 会为 Argo CD 应用控制器提供等效于 Kubernetes 默认admin 集群角色的权限，用于标记的命名空间。但是，您可以选择定义一个备用集群角色，该角色用于控制器和服务器组件，分别使用 Operator 的Subscription 资源中的CONTROLLER_CLUSTER_ROLE 和CONTROLLER_SERVER_ROLE 环境变量。当您提供这些变量时，Operator 不会在命名空间中创建默认角色，而只会创建相应集群角色的命名空间中的角色绑定。管理员负责创建集群角色，并完全控制权限。
|
集群范围实例
集群范围实例旨在跨集群部署和管理资源。
|
如果您打算使用“任何命名空间中的应用程序”功能，请选择 Argo CD 实例范围的模式为集群范围实例。 |
集群范围实例可以访问集群级资源，因此通常（但并非总是）用于集群配置。您可以选择将某些命名空间范围的 Argo CD 实例提升为集群范围实例。要提升实例，您必须修改 GitOps Operator 的Subscription 资源。
|
在 Argo CD 中设置多租户配置时，必须非常小心。例如，在一个用例中，集群管理员想要设置一个由多个应用程序交付团队共享并由集群管理员管理的 Argo CD 实例，这时您可能需要一个自定义的集群范围实例。
为防止用户部署具有cluster-admin 权限的 Argo CD 实例，您必须使用Subscription 资源中的ARGOCD_CLUSTER_CONFIG_NAMESPACES 环境变量来识别具有集群权限的命名空间。
由于非集群管理员无权访问Subscription 资源，因此他们无法提升其实例的权限并绕过集群安全。
当实例被指定为集群范围时，Operator 会自动为该命名空间中的 Argo CD 应用控制器和服务器服务帐户创建一组集群角色和集群角色绑定。此默认角色并非旨在等同于标准的cluster-admin 角色。它被赋予了一组更小的权限。可以根据需要通过创建额外的集群角色或集群角色绑定来扩展这些权限。
默认集群范围实例
安装 GitOps Operator 后，默认情况下，它会在openshift-gitops 命名空间中实例化一个集群范围的实例。此实例的设置方式非常明确，旨在允许集群管理员管理某些集群配置资源。
|
默认实例不具有完全的cluster-admin 权限。它可以访问集群中所有资源的读取权限，但只能部署有限的资源集。
|
将 |
采用多租户模型时的重要注意事项
授予多租户集群管理权限可能会允许租户绕过任何多租户工作和权限限制，因为他们可能会使用 Argo CD 授予应用程序的权限来提升其权限。为防止这种情况，您必须了解通过 Red Hat OpenShift GitOps Operator 安装的 Argo CD 的权限模型，以及如何利用它才能成功使用 OpenShift GitOps 进行应用程序交付。
Argo CD 基于角色的访问控制 (RBAC)
Red Hat OpenShift GitOps 中的访问控制在两个不同的级别进行管理，如下所示
-
在 Kubernetes 层面，GitOps Argo CD 应用控制器与一个或多个集群交互，通过每个集群一个 Kubernetes 服务账号来部署各种资源。此服务账号必须拥有足够的权限来部署此 Argo CD 实例管理的所有租户和用例的资源。
-
在 Argo CD 层面，GitOps Argo CD 应用控制器包含其自身独立于 Kubernetes 的 RBAC 权限模型。为了管理用户级别的访问权限，您可以独立于底层的 Kubernetes 权限使用此 RBAC 模型。您可以使用此功能来提供对 Argo CD 应用的访问权限，而用户从纯粹的 Kubernetes 角度来看是没有访问权限的。
由于这两种访问控制及其组件之间的交互是独立且分开的，因此在使用 Argo CD 设计多租户解决方案时，权限提升成为一个值得关注的问题。权限提升是指租户利用应用控制器的服务账号的更高权限来执行他们通常不被允许执行的操作。您可以通过使用 Argo CD RBAC 或单独的 Argo CD 实例来减轻 Argo CD 实例中的权限提升问题。
Argo CD 项目
Argo CD 项目（不要与 OpenShift Container Platform 项目混淆）提供了一种将应用程序分组的方法。使用 Argo CD 项目，您可以指定关于应用程序可以部署哪些资源以及可以在哪里部署的限制。此外，您可以通过在项目级别而不是在 Argo CD 自定义资源 (CR) 中的全局级别更精细地定义它们来启用 Argo CD 基于角色的访问控制 (RBAC) 规则和权限。
虽然您可以在 Operator 的 Argo CD CR 中全局定义租户 RBAC，但您应该在 AppProject CR 中定义租户 RBAC 以及限制。
如果您有大量租户，尝试使用全局 RBAC 管理所有租户可能会导致大量重复。
如果您有很多租户实例，一些项目配置可能在租户项目之间是通用的。为了减少重复并最大限度地减少维护工作，请对通用配置使用全局项目，并在租户项目中继承它们。
|
始终定义您的项目，切勿使用 Operator 在安装 Argo CD 时创建的默认项目。 |