--- title: "OpenShift GitOpsとは：Operatorのインストール手順とupstream Argo CDとの違い【1.21系】" url: "https://www.issoh.co.jp/tech/details/18603/" published: 2026-10-20 updated: 2026-10-20 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # OpenShift GitOpsとは：Operatorのインストール手順とupstream Argo CDとの違い【1.21系】 OpenShift GitOpsは、Red HatがサポートするArgo CDのディストリビューションです。OpenShiftのOperatorとして入り、インストールすると `openshift-gitops` 名前空間にArgo CDが1式立ち上がります。この記事では、2026年10月時点の最新である1.21系を前提に、同梱されるArgo CDの版、oc CLIでのインストールとログイン、ArgoCDカスタムリソースでのインスタンス作成を、公式ドキュメントのYAMLに沿って示します。後半で比較するのは、upstreamのArgo CDとの相違点と、どちらを選ぶべきかという判断基準です。判断の軸となるのは、それぞれのインスタンスが持つ権限の範囲です。 ## まとめ：OpenShift GitOpsを選ぶ条件と導入時に最初に決める3つの設定 OpenShiftのサブスクリプションを持ち、Argo CDの障害や脆弱性をRed Hatのサポート窓口に持ち込みたいなら、OpenShift GitOpsを選びます。代わりに、Argo CDの版はupstreamより1つ遅れます。1.21.0が同梱するのはArgo CD 3.4.3で、upstreamの最新安定版は3.5.5です。 導入時に決めるのは3点です。既定インスタンスをクラスター設定用に残すかどうか。アプリ用のインスタンスを名前空間ごとに分けるかどうか。そして、どのインスタンスにもクラスタースコープの権限を渡さない方針を守れるかどうかです。最後の1点を崩すと、Argo CDの名前空間に触れる人がクラスター管理者に昇格できてしまいます。 ## OpenShift GitOpsの構成とArgo CD同梱版・対応環境の範囲 Argo CD自体の仕組みと、upstream版を素のKubernetesへ入れる手順は[ArgoCDとは？GitOpsの仕組みとインストール・Sync設定をコード付きで解説](https://www.issoh.co.jp/tech/details/15438/)で扱いました。ここではOpenShift GitOpsに固有の部分だけを見ます。 ### Red HatがサポートするArgo CDとOperatorが作る既定インスタンス OpenShift GitOpsの実体は、Argo CDを管理するOperatorです。Operatorは `argoproj.io/v1beta1` の `ArgoCD` カスタムリソースを見て、application-controller、repo-server、server、Redis、Dexなどを作ります。インストール直後に `openshift-gitops` 名前空間へ既定のインスタンスが1つ作られる点が、upstream版との最初の違いです。 既定インスタンスの中身はOperatorのソースで確かめられます。GitHubの[gitops-operatorのargocd.go](https://github.com/redhat-developer/gitops-operator/blob/master/controllers/argocd/argocd.go)では、Routeが有効、SSOはDexでOpenShift OAuthと連携、RBACは `cluster-admins` グループを `role:admin` に割り当て、それ以外の既定ロールは空です。グループに入っていないユーザーは、ログインできても何も見えません。 ### 1.21系の互換表：Argo CD 3.4.3とOpenShift 4.18〜4.22 Red Hatの[OpenShift GitOps 1.21のリリースノート](https://docs.redhat.com/en/documentation/red%5Fhat%5Fopenshift%5Fgitops/1.21/html-single/release%5Fnotes/index)には、版ごとの同梱コンポーネントが表で載っています。主な行を抜き出すと次のとおりです。 | OpenShift GitOps | Argo CD | Argo Rollouts | Image Updater | 対応OpenShift | | ---------------- | ------- | ------------- | ------------- | -------------- | | 1.21.0 | 3.4.3 | 1.9.0 | 1.2.1（GA） | 4.18〜4.22 | | 1.20.0 | 3.3.2 | 1.8.4 | 1.1.2（TP） | 4.14、4.16〜4.21 | | 1.19.0 | 3.1.9 | 1.8.3 | 1.0.4（TP） | 4.14、4.16〜4.21 | 1.21系の最新は2026年10月7日に出た1.21.5です。OpenShift 4.17以前のクラスターでは1.21系を入れられないため、先にOpenShiftを上げるか、1.20系にとどまるかを決めます。1.21ではImage UpdaterとArgo CD CLIがGAになった一方、ApplicationSetの `tokenRef` がstrictモード既定になりました。SCM用のSecretに `argocd.argoproj.io/secret-type: scm-creds` ラベルが無いと、Pull Requestジェネレーターなどが止まります。 ## OpenShift GitOpsのoc CLI導入と既定インスタンスへのログイン手順 Webコンソールからも入れられますが、手順を再現できるようにCLIで示します。cluster-admin権限でログインしたうえで作業してください。 ### OperatorGroup・SubscriptionのYAMLとチャネル選択 [OpenShift GitOpsのインストール手順](https://docs.redhat.com/en/documentation/red%5Fhat%5Fopenshift%5Fgitops/1.21/html-single/installing%5Fgitops/index)では、Operatorを `openshift-gitops-operator` 名前空間に置きます。1.10より前は `openshift-operators` だったので、古い社内手順書を流用するときは書き換えが必要です。 ``` apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-gitops-operator namespace: openshift-gitops-operator spec: upgradeStrategy: Default --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator namespace: openshift-gitops-operator spec: channel: gitops-1.21 installPlanApproval: Manual name: openshift-gitops-operator source: redhat-operators sourceNamespace: openshift-marketplace ``` ``` oc create ns openshift-gitops-operator oc apply -f gitops-operator.yaml oc get installplan -n openshift-gitops-operator oc patch installplan -n openshift-gitops-operator --type merge -p '{"spec":{"approved":true}}' ``` 公式の例は `channel: latest` と `installPlanApproval: Automatic` です。検証環境ならそれで足ります。本番では `gitops-1.21` のような版付きチャネルと手動承認にして、Argo CDのマイナー版が勝手に上がらないようにします。上のYAMLはこの本番向けの形で、更新のたびにInstallPlanの承認が要る点に注意してください。コミュニティ版のArgo CD Operatorが入っているクラスターでは、先に削除しておくよう公式は求めています。 ### openshift-gitopsのPod確認とadmin認証情報・Route取得 InstallPlanを承認して数分たつと、2つの名前空間でPodが動き出します。 ``` oc get pods -n openshift-gitops-operator oc get pods -n openshift-gitops oc get route openshift-gitops-server -n openshift-gitops -o jsonpath='{.spec.host}' oc extract secret/openshift-gitops-cluster -n openshift-gitops --keys=admin.password --to=- ``` `openshift-gitops` 側には application-controller、applicationset-controller、dex-server、redis、repo-server、server などが並びます。[Argo CDインスタンスの設定ページ](https://docs.redhat.com/en/documentation/red%5Fhat%5Fopenshift%5Fgitops/1.21/html-single/argo%5Fcd%5Finstance/index)のとおり、adminのパスワードは「インスタンス名-cluster」というSecretの `admin.password` に入っています。RouteのTLS終端は1.13から既定が `reencrypt` です。 リソースの既定値にも注意が要ります。application-controllerだけでrequestが250mと1024Miあり、ResourceQuotaのある名前空間ではインストールが失敗することがあります。 ### OpenShift認証でのログイン条件とcluster-adminsの設定 Argo CDのログイン画面には「LOG IN VIA OPENSHIFT」のボタンが出ます。ただ、OpenShiftのcluster-adminロールを個人に直接付けているだけでは、Argo CDの管理者にはなれません。Argo CDのRBACはグループ名で判定するためです。[アクセス制御のページ](https://docs.redhat.com/en/documentation/red%5Fhat%5Fopenshift%5Fgitops/1.21/html-single/access%5Fcontrol%5Fand%5Fuser%5Fmanagement/index)の手順でグループを作ります。 ``` oc adm groups new cluster-admins oc adm groups add-users cluster-admins alice oc adm policy add-cluster-role-to-group cluster-admin cluster-admins ``` この3行で、alice はOpenShiftでもArgo CDでも管理者になります。開発者にArgo CDの画面だけ見せたいなら、cluster-adminsに入れるのではなく、次の章で作るアプリ用インスタンスのRBACで読み取り権限を渡すほうが安全です。 ## ArgoCDカスタムリソースでアプリ用インスタンスを作りnamespaceを管理させる設定 既定インスタンスはクラスター設定用に残し、アプリのデプロイはチームごとのインスタンスで行う。Red Hatのドキュメントが前提にしているのはこの分け方です。 ### ArgoCD CRで作成する名前空間スコープのアプリ用インスタンス `openshift-gitops` 以外の名前空間にArgoCDリソースを置くと、その名前空間だけを管理するインスタンスができます。チームAの例です。 ``` apiVersion: argoproj.io/v1beta1 kind: ArgoCD metadata: name: team-a-argocd namespace: team-a-gitops spec: server: route: enabled: true sso: provider: dex dex: openShiftOAuth: true rbac: defaultPolicy: '' policy: | g, team-a-admins, role:admin g, team-a-devs, role:readonly scopes: '[groups]' ``` RBACを書かないと、ログインしたユーザーは既定で読み取り専用になります。`spec.sso` と `spec.oidcConfig` は併用できず、両方書くとバリデーションエラーです。Keycloakなど外部のIdPへ直接つなぐなら `oidcConfig` だけを使います。旧来の `spec.dex` は1.10.0以降サポートされません。 ### managed-byによる管理対象の指定とApplicationの最小例 名前空間スコープのインスタンスに別の名前空間を任せるには、管理される側へラベルを付けます。Operatorがラベルを見て、Argo CDのサービスアカウントにその名前空間の権限を作ります。 ``` oc label namespace team-a-dev argocd.argoproj.io/managed-by=team-a-gitops oc label namespace team-a-stg argocd.argoproj.io/managed-by=team-a-gitops ``` ``` apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: shop-api-dev namespace: team-a-gitops spec: project: default source: repoURL: https://git.example.com/team-a/shop-api-deploy.git targetRevision: main path: overlays/dev destination: server: https://kubernetes.default.svc namespace: team-a-dev syncPolicy: automated: prune: true ``` ラベルの付け忘れによって起こるのは、管理対象の名前空間への権限不足を原因とする同期エラーです。名前空間スコープのインスタンスは自分の管理する名前空間の中しか触れないので、名前空間はクラスター管理者がラベル付きで先に作る運用にします。複数環境へ同じ形のApplicationを配るなら、[ArgoCD ApplicationSetの使い方](https://www.issoh.co.jp/tech/details/18565/)のジェネレーターがそのまま使えます。 ### クラスター設定を管理しない場合に既定インスタンスの生成を止める設定 クラスター設定もGitOpsで管理しない組織では、既定インスタンスは使われないまま、Podのrequestだけで合計2GiB超のメモリを確保し続けます。その場合はSubscriptionに環境変数を足して作らせないようにします。 ``` spec: config: env: - name: DISABLE_DEFAULT_ARGOCD_INSTANCE value: "true" ``` 値は真偽値ではなく文字列の `"true"` です。逆に、OpenShiftのOAuth設定やMachineConfigなどクラスター自体の設定をGitで管理する予定があるなら、既定インスタンスは残してその用途に限定します。 ## upstream Argo CDとの違いと、権限・設定変更でつまずく箇所 使い勝手の違いは、設定の書き場所と権限の初期値にほぼ集約されます。upstreamの手順書をそのまま当てると、この2点で詰まります。 ### 設定はargocd-cmでなくArgoCD CRに書く運用とextraConfigの扱い upstreamでは `argocd-cm` や `argocd-rbac-cm` を直接編集します。OpenShift GitOpsでは、これらのConfigMapはOperatorがArgoCD CRから作るものです。RBACは `spec.rbac`、ヘルスチェックは `spec.resourceHealthChecks`、除外するリソースは `spec.resourceExclusions` に書きます。 ``` spec: resourceExclusions: | - apiGroups: - tekton.dev kinds: - TaskRun - PipelineRun extraConfig: timeout.reconciliation: 300s ``` CRに専用の項目が無い設定は、`extraConfig` に書くと `argocd-cm` へ足されます。OpenShift Pipelinesを併用しているなら、上のようにTaskRunとPipelineRunを除外しておくと、実行のたびに増えるリソースをArgo CDが追いかけずに済みます。 ### 既定インスタンスの権限範囲と限定ClusterRoleを追加する方法 [クラスター設定の宣言的管理のページ](https://docs.redhat.com/en/documentation/red%5Fhat%5Fopenshift%5Fgitops/1.21/html-single/declarative%5Fcluster%5Fconfiguration/index)は「Argo CD does not have cluster-admin permissions」と明記しています。既定インスタンスが持つのは、自分の名前空間へのadmin権限と、クラスター全体の読み取り、OperatorのSubscriptionやRBACなど一部のクラスター管理リソースへの権限です。 ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: gitops-ingresscontroller-edit rules: - apiGroups: ["operator.openshift.io"] resources: ["ingresscontrollers"] verbs: ["get", "list", "watch", "patch", "update"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: gitops-ingresscontroller-edit subjects: - kind: ServiceAccount name: openshift-gitops-argocd-application-controller namespace: openshift-gitops roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: gitops-ingresscontroller-edit ``` 足りない権限は、このように必要なリソースと動詞だけのClusterRoleを別に作って付けます。Operatorが作ったロールやClusterRoleは直接変えず、専用のロールを作ってbindするよう公式は求めています。cluster-adminをまるごと付ける近道は取りません。 ### 自作インスタンスをクラスタースコープへ昇格する設定と権限分離のリスク 自作のインスタンスにも既定インスタンスと同じクラスタースコープの権限を渡す設定が、Subscriptionの環境変数 `ARGOCD_CLUSTER_CONFIG_NAMESPACES` です。 ``` spec: config: env: - name: ARGOCD_CLUSTER_CONFIG_NAMESPACES value: openshift-gitops, platform-gitops ``` 公式は、明確な用途が無い限り昇格させないよう警告しています。クラスタースコープのインスタンスの名前空間にアクセスできる人は、自分の権限をクラスター管理者まで上げられるからです。さらに、Argo CDの名前空間に触れるKubernetesユーザーは、Argo CDのRBACを迂回できる管理者として扱われます。アプリチームのインスタンスをこの一覧に入れる運用は、権限分離そのものを無効にします。 ## OpenShift GitOpsとupstream Argo CDの採用条件の比較 受託でOpenShiftのGitOps基盤を組むときの判断を、条件付きで言い切ります。 ### サポート窓口と版の遅れを比べてOpenShift GitOpsを選ぶ基準 | 観点 | OpenShift GitOps 1.21系 | upstream Argo CD | | ------------- | ---------------------- | ---------------------- | | Argo CDの版 | 3.4系（1.21.0は3.4.3） | 3.5.5（2026年10月12日） | | 障害・脆弱性の窓口 | Red Hatのサポートとエラータ | 自社でGitHubを追う | | 設定の書き場所 | ArgoCD CR | ConfigMapとHelm values | | OpenShiftログイン | Dex連携が既定で有効 | Dexを自分で設定 | | クラスター権限の初期値 | 限定ClusterRole | install.yamlは全リソースに全操作 | OpenShiftを使っているなら、原則はOpenShift GitOpsです。upstreamの [Argo CDのリリース一覧](https://github.com/argoproj/argo-cd/releases)では3.5系が出ていますが、3.5の新機能がどうしても必要という案件はまれです。権限の初期値が絞られている点と、脆弱性の修正がエラータとして届く点のほうが、運用では効きます。2026年10月に公表されたArgo CDのCritical脆弱性と修正版は[Argo CDの脆弱性一覧と対処](https://www.issoh.co.jp/tech/details/18560/)にまとめました。OpenShift GitOps側の対応はRed Hatのエラータで確かめます。 upstreamを入れるのは、OpenShiftとそれ以外のKubernetesを1つのArgo CDで束ねる場合です。管理側をEKSやAKSに置くなら、Operatorの恩恵が無くなります。 ### 既存のArgo CDやコミュニティ版Operatorから移る前の確認事項 すでにupstreamのArgo CDやコミュニティ版のArgo CD Operatorが動いているクラスターへ入れる場合、同じCRDを取り合うため、先に撤去が必要です。ApplicationとAppProjectのYAMLを書き出し、旧Argo CDを消し、OpenShift GitOpsのインスタンスへ適用し直す順で進めます。旧Argo CDを消す前に、各Applicationから `resources-finalizer.argocd.argoproj.io` のfinalizerを外しておきます。finalizerが付いたままApplicationを消した場合、削除の対象になるのはApplicationだけでなく、配下のDeploymentやServiceまでです。 移行で止まりやすいのは、`argocd-cm` に直接書いていた設定の移し替えと、cluster-adminを付けていた旧サービスアカウントの権限です。前者はCRの項目か `extraConfig` へ、後者は必要な分だけのClusterRoleへ置き換えます。Gitを正とする運用自体が初めてなら、前提は[GitOpsとは：4原則とPush型との違い、Argo CD・Fluxの最小構成YAML](https://www.issoh.co.jp/tech/details/18553/)で整理しました。 OpenShift上のデプロイ手順をOpenShift GitOpsへ移す計画や、チームごとのインスタンスと権限の切り方を相談したい場合は、[DevOps・CI/CD導入支援](https://www.issoh.co.jp/service/system/devops/)で設計から運用の引き継ぎまで対応しています。 ## よくある質問 OpenShift GitOpsを入れるときに出やすい疑問に、Red Hatの公式ドキュメントの記述をもとに答えます。 ### OpenShift GitOpsとOpenShift Pipelinesはどう違いますか？ 両製品の違いは、CIとCDのどちらの工程を担当するかという役割分担です。OpenShift PipelinesはTektonをもとにしたCIの製品で、ソースのビルド、テスト、コンテナイメージの作成とpushまでを受け持ちます。OpenShift GitOpsはArgo CDをもとにしたCDの製品で、Gitに書かれたマニフェストとクラスターの状態を一致させ続けます。Pipelinesの最後でマニフェストのイメージタグを更新するコミットを作り、それをGitOpsが拾って同期する、という分担が典型です。 ### OpenShift GitOpsでargocdコマンドは使えますか？ 使えます。Red HatはOpenShift GitOps用のargocd CLIを配布しており、1.21からGAです。Linux・macOS・Windows向けのアーカイブのほか、RHEL 8以降ならサブスクリプション経由のRPM（`openshift-gitops-argocd-cli`）でも入ります。新しいCLIは古いサーバーと互換がありますが、逆は保証されないため、サーバーと同じかそれより新しい版を使います。 ### Azure Red Hat OpenShiftやROSAでも同じ手順で入りますか？ 基本は同じで、Operatorカタログから入れます。ただしマネージド版はRed Hatやクラウド事業者が管理する名前空間やリソースがあり、クラスター設定をGitで書き換える範囲に制約があります。AROのクラスター自体の構築手順は[Azure Red Hat OpenShift（ARO）とは](https://www.issoh.co.jp/tech/details/18407/)で扱いました。 ### OpenShift GitOpsの既定インスタンスでアプリをデプロイしてもよいですか？ 小規模な検証なら問題ありませんが、本番のアプリのデプロイに既定インスタンスを使う構成は避ける方針です。既定インスタンスはクラスター設定用の権限を持つため、アプリチームにその名前空間を触らせると、権限分離が崩れます。アプリ用には別の名前空間にArgoCDリソースを作り、`managed-by` ラベルで管理対象を渡す構成にします。 ### OpenShift GitOpsのバージョンアップでArgo CDの版も上がりますか？ 上がります。OpenShift GitOpsのマイナー版ごとに同梱されるArgo CDの版が決まっており、1.20.0は3.3.2、1.21.0は3.4.3です。Subscriptionのチャネルが `latest` で承認が自動だと、Argo CDのマイナー版も知らないうちに上がります。版付きチャネルと手動承認にし、リリースノートの破壊的変更を読んでから上げます。 ## 関連記事 - [ArgoCDとは？GitOpsの仕組みとインストール・Sync設定をコード付きで解説](https://www.issoh.co.jp/tech/details/15438/)：OpenShift GitOpsの中身であるArgo CDの仕組みと基本操作 - [GitOpsとは：4原則とPush型との違い、Argo CD・Fluxの最小構成YAML](https://www.issoh.co.jp/tech/details/18553/)：OpenShift GitOpsが前提にする運用モデル - [ArgoCD ApplicationSetの使い方：List・Cluster・Git・Matrixジェネレーターで複数クラスタへ展開するYAML【3.5系】](https://www.issoh.co.jp/tech/details/18565/)：インスタンスから複数環境へApplicationを配る書き方 - [ArgoCDでHelm chartを使う方法：valueFiles・マルチソースの設定とargo-cd chartでのインストール【3.5系】](https://www.issoh.co.jp/tech/details/18562/)：Helm chartで配るアプリの同期設定 - [Azure Red Hat OpenShift（ARO）とは？AKSとの違い・料金の実額・az aro createでの構築手順【2026年10月】](https://www.issoh.co.jp/tech/details/18407/)：OpenShift GitOpsを載せるマネージドOpenShiftの構築 --- 出典: [OpenShift GitOpsとは：Operatorのインストール手順とupstream Argo CDとの違い【1.21系】]()（株式会社一創）