2026.10.20 インフラ・クラウド

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設定をコード付きで解説で扱いました。ここでは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では、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のリリースノートには、版ごとの同梱コンポーネントが表で載っています。主な行を抜き出すと次のとおりです。

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のインストール手順では、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 <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インスタンスの設定ページのとおり、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はグループ名で判定するためです。アクセス制御のページの手順でグループを作ります。

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の使い方のジェネレーターがそのまま使えます。

クラスター設定を管理しない場合に既定インスタンスの生成を止める設定

クラスター設定も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を追加する方法

クラスター設定の宣言的管理のページは「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のリリース一覧では3.5系が出ていますが、3.5の新機能がどうしても必要という案件はまれです。権限の初期値が絞られている点と、脆弱性の修正がエラータとして届く点のほうが、運用では効きます。2026年10月に公表されたArgo CDのCritical脆弱性と修正版はArgo CDの脆弱性一覧と対処にまとめました。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で整理しました。

OpenShift上のデプロイ手順をOpenShift GitOpsへ移す計画や、チームごとのインスタンスと権限の切り方を相談したい場合は、DevOps・CI/CD導入支援で設計から運用の引き継ぎまで対応しています。

よくある質問

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）とはで扱いました。

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のマイナー版も知らないうちに上がります。版付きチャネルと手動承認にし、リリースノートの破壊的変更を読んでから上げます。