Argo CDは、KubernetesのGitOps継続的デリバリーツールである。Gitリポジトリの内容を真実の情報源とし、その差分をクラスタへ自動的に反映する。プラットフォームエンジニアやGitOps基盤の運用者にとって、Gitリポジトリは実質的にデプロイの入り口になっている。改ざんされたリポジトリに未署名のマニフェストが紛れ込めば、レビューを経ないまま本番クラスタに反映されるリスクがある。Argo CD 3.5は、この経路をふさぐための2つの機能を追加する。1つはGitソースの署名検証を必須化する仕組みで、もう1つはコンポーネント間通信を暗号化する内部mTLSである。3.5はGA（正式版）を2026年8月4日に予定し、6月からリリース候補版が公開されている[4][5]。本稿では、この2機能がGitOps基盤の「信頼された変更」をどう再定義するかを整理する。
予備知識
- GitOps: Gitリポジトリの状態を単一の真実の情報源とし、その差分を自動的にクラスタへ反映する運用手法。
- mTLS（相互TLS）: 通信の両者が証明書を提示し合い、双方向で身元を検証したうえで暗号化する認証方式。
- マニフェスト: Kubernetesリソースを定義した設定ファイル。Argo CDはこれをGitから取得してクラスタに適用する。
- サプライチェーン攻撃: 開発・配布経路（リポジトリ、CI/CD、パッケージなど）を狙い、正規の経路を悪用して不正な変更を混入させる攻撃。
GitOpsの前提となる、信頼できるリリースパイプラインの設計思想を体系的に学べる定番書
GitOpsのリポジトリ改ざんはなぜ静かに成功するか
リポジトリ改ざんとは、正規の権限を持たない変更やコミットがGitに混入する状態を指す。Argo CDは基本的にGitの内容を信頼してクラスタに同期する仕組みで、署名検証が有効でなければコミットの出所を確認せずマニフェストを適用する[1]。CI権限の窃取やアクセストークンの流出、レビューを省いたマージなどで改ざんが起きると、次の同期サイクルで自動的に本番へ反映されてしまう。従来のArgo CDにもGnuPGベースの署名検証機能はあったが、AppProjectへsignatureKeysを任意で宣言する方式であり、有効化を徹底するかどうかは現場の運用判断に委ねられていた[2][3]。攻撃者から見れば、この「検証は任意」という設計こそが狙い目になる。
コンポーネント間通信の暗号化や認証設計を含む、Kubernetes運用のセキュリティ実務を具体的に把握できる
Argo CD 3.5が追加する2つの防御機構
Argo CD 3.5は、Gitソースの署名検証を必須化する「Source Integrity」と、コンポーネント間通信を暗号化する内部mTLSの2つを新設する[1][2]。Source Integrityは、AppProjectまたはApplicationの仕様にsourceIntegrity.required: trueを設定し、署名鍵（signingKeyのkeyId）を指定する形で有効化する。指定した鍵で署名されていないGitソースは同期を拒否される[2][3]。CLIからもargocd app set --source-integrity-requiredのように設定でき、UIを使わないチームでも導入しやすい[2]。もう一方のmTLSは、repo-serverが各コンポーネントからの接続にクライアント証明書を要求する仕組みである。これまでrepo-serverとAPIサーバー、コントローラー間の内部通信は暗号化されていなかった[1]。独自の証明書を用意しない環境では、repo-serverがメモリ上で自己署名証明書を生成する。両機能とも標準では無効なopt-in設計で、設定しない限り既存の挙動は変わらない[1][2]。
権威DNSサーバの代表格であるISC BIND 9で、DNSSEC（DNS応答の改ざんを電子署名で検証する仕組み）の検証をすり抜けられる脆弱性が見つかった。Internet Systems Consortium（ISC）は2026年7月2[…]
導入設計はAppProject単位かApplication単位か
ここでは、新旧の設計をどこで比較し、何を判断材料にすべきかを整理する。旧来のGnuPGベースsignatureKeysは任意設定で、未署名コミットでもそのまま同期されてしまう点が弱点だった[2][3]。
| 項目 | 旧設計（3.4以前） | Argo CD 3.5の新設計 |
|---|---|---|
| 署名検証の単位 | AppProjectのsignatureKeys（GnuPG、任意） | AppProject/ApplicationのsourceIntegrity.required（必須化可能） |
| 未署名コミットの扱い | 検証未設定ならそのまま同期 | required: trueなら同期を拒否 |
| コンポーネント間通信 | 暗号化なし（内部トラフィックは平文） | mTLSで相互認証・暗号化（opt-in） |
| 設定手段 | AppProjectへの手動宣言のみ | UI／CLI（argocd app・argocd appset）からも設定可 |
注意点もある。Source Hydrator機能を使う構成では、Argo CDがハイドレート後にpushするコミットに自ら署名しない。そのためハイドレート済みブランチ側で署名必須化を有効にすると、正当な同期まで失敗する[2]。DRY（変換前）側のコミットで検証し、ハイドレート後のブランチは別の運用ルールで守る、といった切り分けが必要になる。
2026年7月14日、イベント駆動アーキテクチャの仕様記述に使われるOSS標準「AsyncAPI」がnpm（JavaScriptの標準パッケージレジストリ）で配布する4パッケージ5バージョンに、悪性コードが混入していたことが判明した[1][…]
実務でどこから手をつけるか
mTLSはopt-inのため、有効化しない限り既存クラスタへの影響はほぼない。まず検証環境で試し、証明書運用の負荷を確認するところから始められる。Source Integrityはrequired: trueにする前に、コミット署名鍵を誰がどう管理し、CI上でどう署名するかを先に決めておく必要がある。鍵管理が未整備のまま必須化すると、正当な変更まで同期に失敗し、運用が止まりかねない。段階導入としては、まず本番系の重要なAppProjectだけrequired: trueにし、それ以外は監視のみで運用しながら鍵管理の仕組みを整えていくのが現実的な順序になる。
まとめ
Argo CD 3.5は、GitOps基盤の弱点だった「Gitの内容を無条件に信頼する」前提を変える。署名検証必須化と内部mTLSは、どちらもopt-inで既存運用を壊さずに導入できる設計になっている。GA予定の2026年8月4日を待たずとも、リリース候補版で挙動を確認し、本番のAppProjectでsourceIntegrity.requiredを有効化する検討と、署名鍵の発行・保管・ローテーション手順の整備を始める価値がある。まず鍵管理の仕組みを固め、そのうえで重要度の高いAppProjectから段階的に必須化を進めるのが妥当な順序になる。
よくある質問（FAQ）
Q1. sourceIntegrity.requiredは従来の署名検証機能と何が違いますか。
A. 従来のGnuPGベースsignatureKeysはAppProjectへの任意宣言だったのに対し、Source Integrityはrequired: trueで検証を明示的に強制できる新しい枠組みです[2][3]。
Q2. mTLSを有効にすると既存のクラスタ運用に影響しますか。
A. mTLSは標準で無効なopt-in機能です。設定しない限り、既存の内部通信の挙動は変わりません[1][2]。
Q3. Argo CD 3.5はいつ正式リリースされますか。
A. GA（正式版）は2026年8月4日を予定しています。6月からリリース候補版が公開され、検証が進んでいます[4][5]。
