多租户

在其中一个命名空间中创建 Argo CD 自定义资源(CR)后，GitOps Operator 在此命名空间中启动 Argo CD，可用于应用程序交付。在其初始状态下，此实例有权仅在安装它的同一命名空间中部署资源。但是，您可能需要配置实例来满足您的特定要求。

使用 GitOps Operator，您可以扩展 Argo CD 实例的权限，使 Argo CD Application Controller 在安装的位置外将资源部署到其他命名空间中。

对于 Argo CD Application Controller 将资源部署到任何其他命名空间中，您需要 Kubernetes 角色和角色绑定来标记这些命名空间，并指示您要管理命名空间范围的实例的命名空间。GitOps Operator 支持使用 argocd.argoproj.io/managed-by 标签来自动创建这些角色和角色绑定。使用此标签并设置值来指示受管命名空间。然后，使用 argocd.argoproj.io/managed-by 标签，当您以命名空间范围的实例模式部署 GitOps Operator 时，它会在实例管理的每个命名空间中创建一组角色和角色绑定。

默认情况下，当使用 managed-by 标签标记命名空间时，GitOps Operator 提供了与标记命名空间的 Kubernetes 默认 admin 集群角色等效的 Argo CD Application Controller 权限。但是，您可以选择在 Operator 的 Subscription 资源中使用 CONTROLLER_CLUSTER_ROLE 和 CONTROLLER_SERVER_ROLE 环境变量来定义用于控制器和服务器组件的备用集群角色。当您提供这些变量时，Operator 不会在命名空间中创建默认角色，而是仅在对应集群角色的命名空间中创建角色绑定。管理员最多需要创建集群角色，对权限具有完全控制权限。

集群范围的实例旨在在集群中部署和管理资源。

集群范围的实例可以访问集群级别的资源，因此通常并不总是用于集群配置。您可以选择提升某些命名空间范围的 Argo CD 实例，以成为集群范围的。要提升实例，您必须修改 GitOps Operator 的 Subscription 资源。

在 Argo CD 中设置多租户配置时，必须小心。例如，如果集群管理员希望设置在多个应用程序交付团队之间共享的 Argo CD 实例，并由集群管理员管理，具有自定义集群范围的实例可能是您需要的。

因为非集群管理员无法访问订阅资源，所以它们无法提升其实例的权限并绕过集群安全性。

当实例指定为集群范围的时，Operator 会自动为该命名空间中的 Argo CD Application Controller 和服务器服务帐户创建一组集群角色和集群角色绑定。此默认角色不应等同于标准 cluster-admin 角色。它被授予一组较小的权限。这些权限可以通过创建额外的集群角色或集群角色绑定来扩展。

安装 GitOps Operator 后，它默认在 openshift-gitops 命名空间中实例化一个集群范围的实例。此实例以非常建议的方式设置，旨在让集群管理员管理某些集群配置资源。

默认实例没有完整的 cluster-admin 权限。它对集群的所有资源具有读取访问权限，但只能部署有限的资源集合。

Red Hat OpenShift GitOps 中的访问控制以两个不同的级别管理，如下所示：

由于这两个访问控制和组件之间的交互是不同的和独立的，因此在使用 Argo CD 设计多租户解决方案时，权限升级会成为问题。当租户利用应用控制器的服务帐户的权限增加时，特权升级是执行通常不允许执行的操作。您可以使用 Argo CD RBAC 或单独的 Argo CD 实例缓解 Argo CD 实例中特权升级。

Argo CD 项目（而不是与 OpenShift Container Platform 项目混淆）提供了一种将应用程序分组到一起的方法。使用 Argo CD 项目，您可以指定 Applications 对可部署哪些资源以及可以部署哪些资源的限制。另外，您可以通过在项目级别和 Argo CD 自定义资源(CR)中的全局级别定义它们来启用 Argo CD 基于角色的访问控制(RBAC)规则和权限。

虽然您可以在 Operator 的 Argo CD CR 中全局定义租户 RBAC，但您应该在 AppProject CR 中定义租户 RBAC 和限制。

如果您有大量租户，尝试管理带有全局 RBAC 的所有租户可能会导致大量重复。

如果您有许多租户实例，则一些项目配置可能在租户项目之间很常见。要减少重复操作并最小化维护，请将全局项目用于常见配置，并在租户项目中继承它们。