マルチテナンシー

namespace の 1 つに Argo CD カスタムリソース (CR) を作成すると、GitOps Operator はこの namespace で Argo CD を起動し、アプリケーション配信に使用できるようになります。初期状態では、インストールされているのと同じ namespace にのみリソースをデプロイする権限がこのインスタンスにあります。ただし、特定の要件を満たすようにインスタンスを設定する必要がある場合があります。

GitOps Operator を使用すると、Argo CD インスタンスの権限を拡張して、Argo CD Application Controller がインストールされている場所とは別の namespace にリソースをデプロイできるようになります。

Argo CD アプリケーションコントローラーがリソースを他の namespace にデプロイするには、namespace スコープのインスタンスで管理するこれらの namespace にラベルを付けて示すための Kubernetes ロールとロールバインディングが必要です。GitOps Operator は、argocd.argoproj.io/managed-by ラベルを使用して、これらのロールとロールバインディングを自動的に作成します。このラベルを使用して値を設定し、管理対象の namespace を指定します。次に、argocd.argoproj.io/managed-by ラベルを使用して、namespace スコープのインスタンスモードで GitOps Operator をデプロイすると、インスタンスが管理するすべての namespace にロールとロールバインディングのセットが作成されます。

デフォルトでは、managed-by ラベルを使用して namespace にラベルを付けると、GitOps Operator は、ラベル付けされた namespace の Kubernetes デフォルトの admin クラスターロールと同等の権限を Argo CD Application Controller に付与します。ただし、Operator の Subscription リソースでそれぞれ CONTROLLER_CLUSTER_ROLE および CONTROLLER_SERVER_ROLE 環境変数を使用して、コントローラーおよびサーバーコンポーネントに使用される代替クラスターロールを定義することもできます。これらの変数を指定すると、Operator は namespace にデフォルトのロールを作成せず、対応するクラスターロールの namespace にロールバインディングのみを作成します。管理者が責任を持って、クラスターロールを作成し、権限を完全に制御するようにしてください。

クラスタースコープインスタンスは、クラスター全体にリソースをデプロイおよび管理することを目的としています。

クラスタースコープのインスタンスはクラスターレベルのリソースにアクセスできるため、通常はクラスター設定に使用されますが、常に使用されるわけではありません。特定の namespace スコープの Argo CD インスタンスをクラスタースコープに昇格させることができます。インスタンスを昇格するには、GitOps Operator の Subscription リソースを変更する必要があります。

Argo CD 内でマルチテナント設定を指定する場合は、細心の注意を払う必要があります。たとえば、クラスター管理者が複数のアプリケーションデリバリーチーム間で共有され、クラスター管理者が管理する Argo CD インスタンスを設定するユースケースでは、カスタムのクラスタースコープインスタンスが必要になる場合があります。

クラスター管理者以外のユーザーは Subscription リソースにアクセスできないため、インスタンスの権限を昇格してクラスターセキュリティーを回避できません。

インスタンスをクラスタースコープとして指定すると、Operator は、その namespace 内の Argo CD Application Controller とサーバーサービスアカウントに対して、一連のクラスターロールとクラスターロールバインディングを自動的に作成します。このデフォルトのロールは、標準の cluster-admin ロールと同等のものではありません。割り当てられる権限のセットがはるかに少なくなります。これらの権限は、必要に応じて追加のクラスターロールまたはクラスターロールバインディングを作成することで拡張できます。

GitOps Operator をインストールすると、デフォルトでは、openshift-gitops namespace にクラスタースコープのインスタンスが作成されます。このインスタンスは、独自性の高い方法で設定されています。その主な目的は、クラスター管理者が特定のクラスター設定リソースを効率的に管理できるようにすることです。

デフォルトのインスタンスには完全な cluster-admin 権限がありません。クラスター内のすべてのリソースに対する読み取りアクセス権がありますが、デプロイできるのは限られたリソースセットのみです。

Red Hat OpenShift GitOps のアクセス制御は、次の 2 つの異なるレベルで管理されます。

これら 2 つのアクセス制御とコンポーネント間の相互作用は明確に区別されているため、Argo CD を使用してマルチテナントソリューションを設計するときには、権限の昇格が懸念事項になります。権限の昇格とは、テナントがアプリケーションコントローラーのサービスアカウントの権限昇格を利用して、通常は実行が許可されないアクションを実行することです。Argo CD RBAC または 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 を使用してすべてのテナントを管理しようとすると、繰り返しが多く発生する可能性があります。

テナントのインスタンス数が多い場合は、プロジェクト設定の一部がテナントプロジェクト間で同じに可能性があります。重複を減らし、メンテナンスを最小限に抑えるには、共通の設定にグローバルプロジェクトを使用し、それをテナントプロジェクトに継承します。