Gitless GitOpsとは何か？OCI中心のセキュアな新構成

KubeCon EU 2025で Gitless GitOps の存在を知りました。GitOpsツール(PipeCD)開発者として詳細が気になったものの、巷に情報が少なかったので調査してみました。

🧐「GitOpsなのにGitが無いとは？？？」

詳細はこちらのレポートで読めます。D2と呼ばれるFluxのリファレンスアーキテクチャの一部としてGitlessが紹介されているので、全文読む必要はありません。

https://fluxcd.control-plane.io/guides/d2-architecture-reference/

要点

• Gitless GitOpsとは、GitではなくOCI Registryを中心に据えた新しいGitOpsアーキテクチャ
• GitOpsツールがGitにアクセスしないので"Gitless"だが、根本的に大きく変わるわけではない
• 主なメリットはサプライチェーン関連のセキュリティ強化

おさらい： 現状のGitOps

そもそもGitOpsとは

GitOpsとは、「実環境をGit上の設定と一致させ続ける」デリバリー方式です。
以下の4原則があります。

1. 宣言的
2. バージョン管理され、イミュータブル
3. Pull型
4. 継続的にReconcileされる

代表的なGitOpsツールとして、ArgoCD、FluxCD、PipeCDがあります。

CIOpsという概念もあります。GitOpsとの違いはこちらの記事がわかりやすいです↓

https://blog.inductor.me/entry/2021/09/24/015402

一般的なGitOpsの構成

GitOpsの簡単なアーキテクチャを示します。

一般的なGitOpsの基本構成

GitOpsツール（FluxCDなど）がGitリポジトリを継続的に監視し、変更があれば実環境にデプロイします。

Gitless GitOpsの概要

Gitless GitOpsとは、Gitリポジトリではなくコンテナレジストリに格納されたOCI(Open Container Initiative)アーティファクトによって駆動するデリバリー方式です。

Gitless GitOpsの基本構成

CIの中でOCIアーティファクトの作成・pushまで行い、GitOpsツールはその適用のみを担います。
継続的なReconcileはGitではなくOCIアーティファクトに基づいて行われます。

なお、GitlessにおいてもGitがSingle Source of Truthであり続けるようですが、OCIレジストリへの書込制御等によってGitとOCIレジストリ間の一貫性を保つ機構は必要と思います。

こちらのツール「Gitless」とは無関係なようです。
https://gitless.com/

余談: いつ登場したか

筆者の調べた範囲では、Gitlessの概念・名称はFluxCDの開発者らが主導していて、登場したのはここ3年以内のようです。

• 2022年： FluxがOCIに対応（OCIRepository登場）

https://fluxcd.io/blog/2022/10/cncf-talk-flux-oci/

• 2024年には"Gitless GitOps"というワードが紹介されている

https://www.heise.de/en/background/Gitless-GitOps-The-path-to-a-secure-app-environment-with-Flux-and-OCI-9811957.html

• 2025年4月： ControlPlane社がGitless GitOpsに基づいたリファレンスアーキテクチャを公開
  • ControlPlane社は、エンタープライズ向けのFluxCDなどを提供している企業

https://control-plane.io/posts/d2-reference-architecture-guide/

ちなみに、GitlessかGit-lessかは表記揺れがあるようです。

Gitlessのメリット

各メリットの裏には、「そもそもGit自体がGitOpsを想定しているツールではなく、OCIレジストリの方がクラウドネイティブ環境には適している」という事情がありそうです。

ソフトウェアサプライチェーン周りのセキュリティ・コンプライアンス

この点が最も強調されています。
KubeConのセッションでも "Configuration is Part of the Supply Chain" というメッセージがありました。

Gitlessでは以下のようになります。OCI関連のエコシステムが使えるようになる点が大きいです。

• OCIのアーティファクトの署名/検証により、マニフェスト含めた真正性・完全性を保証できる
  • Fluxではcosignが使われています
• OCIリポジトリで脆弱性スキャンが行える
• マニフェストを含めてSBOMを扱える

背景

こうした対策への関心が高まる背景としては以下の規制があり、いずれにおいてもソフトウェアサプライチェーンが重要視されています。

• 米国: 2021年発令のEO14028 「国家のサイバーセキュリティの向上に関する大統領令」
• ヨーロッパ: 2024年成立の欧州サイバーレジリエンス法(Cyber Resilience Act, CRA)

Gitアクセスが不要に

git pullが不要になるため、GitOpsツールからGitにアクセスするためのネットワーク・認証・権限が不要になります。
後述しますが、gitへの書き込み権限も不要になります。

• Workload Identity等によってOCIレジストリに認証し、PATやSSHキー等を使わずに済む
  • シークレット管理やローテーションが不要
• Gitアクセス権限の管理効率も改善しそう
  • 「Gitへのアクセス制御を厳格にしようとしたら、GitOpsツールの権限も制限してしまい、Image Updater系が動かなくなった」といった事象を防ぎやすい

性能面: 軽量になるかも

Gitlessではgit pullではなくOCIアーティファクト単位でのpullが中心となり、軽量化・高速化が見込まれます。

現状のGitOpsでは、マニフェストリポジトリが大きかったり、トランクベース開発等で高速に更新が走っていると、性能面で課題が発生しえます。というのも、GitOpsツールはその性質上git pullを頻繁に行ううえに、ローカルで処理する際にpullしたリポジトリのコピーなども行っているからです。
そのため、各種GitOpsツールではさまざまな手段でgit操作関連の性能チューニングを行っています。しかし、テンプレーティング等の関係で「どのマニフェストがアプリケーションに紐づいているか特定困難」など、チューニングが難しい点もあります。PipeCDでの例はこちら：

https://pipecd.dev/blog/2024/09/11/performance-improvement-in-git-operations-on-pipecd-v0.48.9/

GitOpsツールのシンプル化

CI側の役割が増える一方で、GitOpsツール本体の責務が減ってシンプルになります。GitOpsツールは「OCIアーティファクトのデプロイ」に集中します。

[1]テンプレーティング処理

CI側でkustomizeやjsonnetなどを実行した結果をOCIアーティファクトとして使用するため、CDにおいてはテンプレーティング処理は不要になります。「結局どんなマニフェストが適用されるのか」を、GitOpsツールのバージョンや依存関係等によらずに固定できます。

Fluxのドキュメントにも「テンプレーティングの関係で最終的なマニフェストがGitに無い場合は特に、OCIアーティファクト中心だと便利」という旨の記載があります。

[2]イメージ自動更新系

前提として各種GitOpsツールは、アプリケーションの新しいバージョンが作成され次第自動でデプロイするための機構を持っています。いずれもGitOpsツールが自らマニフェストリポジトリにコミットする「自作自演」のような構成です。

• FluxCD: Image Reflector Controller & Image Automation Controller
• ArgoCD: Image Updater
• PipeCD: EventWatcher

Gitlessではそれらの責務をGitOpsツールから切り離し、CI側で実施します。これによりGitOpsツールにGit書込権限が不要になります。

イメージ更新を含めたCI/CD全体像のBefore/Afterを示します。

現状の構成

Gitlessでの構成

エッジ環境で強いかも？

ControlPlane社のレポートには言及がありませんでしたが、OCIリポジトリを複製して各所に配置することでエッジ環境などでも高速・安定的にデプロイできるのでは？という指摘もありました。

https://itnext.io/advantages-of-storing-configuration-in-container-registries-rather-than-git-b4266dc0c79f

Gitlessに移行するには何が必要か？

Gitlessへの移行のために必要なタスクをいくつか列挙してみます。GitOpsツールの利用者・開発者両方で対応が必要です。

GitOpsツールのユーザ側の対応

• アプリケーションのイメージがPushされたらマニフェストリポジトリに反映させる
• マニフェストリポジトリからOCIアーティファクトの作成・署名・pushを行う
• GitOpsツールの設定を変更して、GitではなくOCIアーティファクトを監視させる
  • GitOpsツールからGitへのアクセス権限・ネットワークは不要となるので削除可能

GitOpsツールの開発者側の対応 （Fluxは対応済）

• OCIレジストリの監視・取得・署名検証処理に対応
  • FluxではSourceControllerにOCIRepositoryを追加するのがメインだったようで、綺麗にできているなと思いました
• OCIアーティファクトのデプロイ処理に対応
  • マニフェストのapply自体は既にあるはずなので、アーティファクトの解凍処理等を追加すれば基本的には良さそうです

ちなみにArgoCDは現在対応中、PipeCDでは現在未対応です。

なお、実装においてはOCIアーティファクト操作のクライアントツールORAS(CNCF Sandboxプロジェクト)を使うのが便利そうです。Fluxではoras-goを使っているようです。

2025-04-17 訂正 🙇

Fluxでは下記の自前のOCI関連packageを利用していて、oras-goへの依存はnotaryからのものでした。
https://github.com/fluxcd/pkg/tree/main/oci

Flux開発者のStefanさんに教えていただきました🙏

終わりに

FluxCDのパイオニア的な存在感がかっこいいですね。

「全員がGitlessを採用すべきか？」といえば、「現時点では全員ではなさそう」と思います。というのも現状ではGitOpsツールが色々やってくれている一方で、GitlessではCIの作り込みが追加で必要だからです。
ただし、厳格なセキュリティ・コンプライアンスが要求される業界や国においては、Gitlessは強力だと思います。

ソフトウェアサプライチェーンセキュリティの規制の強さや、大規模GitOpsでの性能事例がどれだけ出てくるかによって、Gitlessの盛り上がりが変わってきそうです。

こんな記事を書いてる最中にCVEプログラムの継続性に関する不穏なニュースが飛んできて頭抱えました