🛡️ データ主権は契約書では守れない：KubernetesとGitOpsで強制する設計論

CNCF Blog（2026-07-03）「How data sovereignty is changing cloud native infrastructure design」を起点に、データ主権を「文書上の主張」から「プラットフォームによる技術的強制」へ移す参照アーキテクチャを、構造・データ・構築・利用・運用の観点で整理します。

概要

この設計論が扱う課題

データ主権を Kubernetes と GitOps で強制する設計論は、主権を「データをどこに置くか」ではなく「そのデータに対する法的支配権を誰が持つか」の問題として捉え直します。CNCF Blog の中心的な主張は次の一文に集約されます。

"The core issue isn't where your server sits. It's who can be compelled to hand over what's on it."
（本質的な問題はサーバーの設置場所ではありません。誰がそのデータの提出を強制されうるか、です。）

背景にある規制動向

データ主権が技術設計の課題に格上げされた背景には、複数の規制の進展があります。

US CLOUD Act の要点は「到達範囲はデータの所在地でなく事業者の支配に従う」という点です。米国の法的手続きの対象となる事業者がフランクフルトでインフラを運営していても、データがその "possession, custody, or control"（占有・保管・支配）下にあれば、米国当局は開示を強制できます。EU の GDPR 第48条は、第三国当局による開示命令それ自体は国際協定に基づく場合にのみ EU 側で認識・執行できるとしています。ただし本条は Chapter V の他の移転根拠を直ちに排除する趣旨ではありません。この 2 つの法規は正面衝突とまでは言えないものの、強い緊張関係にあります。

EU CADA が提案する主権保証の段階は、報道・解説ベースで次のように整理されています。以下は提案内容の解説であり、一次資料（提案本文）の条文で確定した区分ではありません。最終的な区分は変わりうる点に注意します。

これらの規制に共通するのは、要求範囲が「データの保存場所（residency）」から「運用支配・サプライチェーンの透明性・可搬性・レジリエンス」へと拡大している点です。

主権の再定義: geographic から jurisdictional へ

この設計論の核心は、主権を 3 つの異なる問いに分解することです。

米国のハイパースケーラーがフランクフルトにインフラを構えていても、親会社が米国法人である以上、米国法の下にあります。したがって「EU リージョンを選ぶ」という対処は jurisdictional な問題を解決しません。この設計論はこの誤解を修正し、主権を「保存場所」でなく「法的支配権・運用権限・監査可能性」の問題として捉え直します。

特徴

従来アプローチとの比較

従来のコンプライアンスプログラムは、文書化・レビュー・手作業の確認に依存してきました。この設計論はそれを、プラットフォームが直接強制する仕組みへ転換します。

なぜ「主張」から「強制」への転換が起きているか

転換の理由はスケーラビリティです。数千のワークロードにまたがる主権要件を、人手による確認だけで担保することはできません。GitOps を組み合わせることで、次のことが自動的に実現します。

• すべての変更が Git 上でバージョン管理される
• 変更はピアレビューと CI パイプラインで検証されてから適用される
• 主権要件はデプロイのたびに自動的・継続的に強制される
• 「ある時点で何が稼働していたか」がコミット履歴から監査可能になる

CNCF Blog は最終的な問いを次のように提示しています。

"The question is whether sovereignty remains something organizations document, or something their platforms can enforce."
（問いは、主権が組織が文書化するものであり続けるか、プラットフォームが強制できるものになるか、です。）

この設計論が実現する範囲

• 主権要件を「文書上の主張」から「プラットフォームによる技術的強制」へ移す
• リージョン選択だけでは解決しない法的支配（jurisdictional control）の問題に対処する
• サプライチェーンの透明性・運用主体の分離・要員国籍まで含む、拡張された主権の定義に対応する
• 監査を「事後のレビュー」から「常時検証可能な状態」に変える
• AI 学習インフラなど新たな領域（フェデレーション学習など、データを移動させず学習だけを分散実行する設計）にも主権の考え方を拡張する

なお、主権の強調は「集中・効率化」というクラウドネイティブの従来の潮流とは逆方向に働きます。

"Sovereignty is pushing in the opposite direction: more regional control, greater transparency, and stronger operational ownership."
（主権は逆方向に作用します。より強いリージョン単位の支配、より高い透明性、より強固な運用上の所有権です。）

構造

データ主権を強制するプラットフォームの構造を、C4 model の 3 段階で示します。システムコンテキスト図でアクターと外部システムを整理し、コンテナ図でプラットフォーム内の主要コンテナを整理し、コンポーネント図でコンテナ内部の具体的な実装コンポーネントを整理します。

システムコンテキスト図

データ主権プラットフォームは、4 種類のアクターと 3 種類の外部システムに接続します。

要素一覧

コンテナ図

プラットフォーム内部は 6 つの主要コンテナで構成されます。

要素一覧

コンポーネント図

各コンテナをドリルダウンし、具体的な実装コンポーネントを示します。

Admission Policy 強制層

kube-apiserver の admission chain を起点に、複数の policy engine が並列に評価します。

要素一覧

GitOps Reconcile Controller

Git を単一の真実源とし、各コントローラが jurisdiction 別 overlay を継続的に reconcile します。

要素一覧

主権インフラ基盤

OpenStack のコンポーネント群と Ceph（独立プロジェクト）が compute storage network identity を組織支配下に置きます。

要素一覧

Policy Store

jurisdiction 別 overlay に含まれるポリシー定義が、各 policy engine の CRD として etcd に保持されます。

要素一覧

Supply Chain 検証

Sigstore のコンポーネント群が、署名済み成果物のみを許可します。

要素一覧

Audit 監査ログ

複数のログ源を集約し、監視基盤と Auditor に提供します。

要素一覧

データ

主権強制プラットフォームが扱う主要エンティティを、概念モデルと情報モデルの 2 段階でモデル化します。

概念モデル

要素一覧

概念モデルの読み方は次のとおりです。

• 法域ドメインは、主権要件と保存先を法域の管理下に置きます
• GitOps 制御面は、配置ポリシーと admission ポリシーを望ましい状態として宣言します
• ワークロード実行面は、テナントが所有するワークロードを表します
• 主権要件は配置ポリシーと admission ポリシーに変換されます
• 配置ポリシーと admission ポリシーはワークロードを制約・検証します
• ワークロードは保存先にデータを書き込みます
• 監査証跡は GitOps の望ましい状態とワークロードの両方を記録します

情報モデル

属性一覧

情報モデルの読み方は次のとおりです。

• Jurisdiction は 1 件から多数の SovereigntyRequirement を定めます
• Jurisdiction は 1 件から多数の DataResidency をホストします
• SovereigntyRequirement は 1 件から多数の PlacementPolicy と AdmissionPolicy に変換されます
• PlacementPolicy と AdmissionPolicy は多数の Workload を多対多で制約・検証します
• Workload は多数から 1 件の DataResidency にデータを書き込みます
• IdentityTenant は 1 件から多数の Workload を所有します
• GitOpsOverlay は 1 件から多数の PlacementPolicy と AdmissionPolicy を宣言します
• AuditTrail は多数から 1 件の GitOpsOverlay と Workload をそれぞれ記録・証明します

構築方法

この章と次章のコード例はすべて実装案です。実プロジェクトへの適用前に、各公式ドキュメント（参考リンク）で最新仕様を確認してください。

前提条件・バージョン確認

構築前に、次のコマンドでクラスタバージョンとノードの region ラベルを確認します。

kubectl version
kubectl get nodes --show-labels | grep topology.kubernetes.io/region

ノードに topology.kubernetes.io/region や topology.kubernetes.io/zone ラベルが付与されていない場合、クラウドプロバイダの Cloud Controller Manager 側でラベル付与を有効化する必要があります。

Admission/Policy engine の導入（Kyverno）

Kyverno は Helm でインストールします。

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm install kyverno kyverno/kyverno \
  --namespace kyverno --create-namespace

Pod Security Standards などの既製ポリシー集を追加する場合は、別チャートを重ねてインストールします。

helm install kyverno-policies kyverno/kyverno-policies \
  --namespace kyverno --create-namespace

Admission/Policy engine の導入（OPA Gatekeeper）

OPA Gatekeeper も Helm でインストールします。

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts --force-update
helm install gatekeeper gatekeeper/gatekeeper \
  --namespace gatekeeper-system --create-namespace

kubectl 直接適用でも導入できます。master（未固定の HEAD）ではなく、公式リリースページで確認したバージョンタグを固定して適用します。

# <TAG> は公式リリースページで確認した安定版タグに置き換える（例: v3.x.y）
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/<TAG>/deploy/gatekeeper.yaml

GitOps controller の導入（ArgoCD）

ArgoCD は namespace を作成してから公式マニフェストを適用します。

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

GitOps controller の導入（Flux）

Flux は bootstrap コマンドで導入します。bootstrap は Flux 自身のマニフェストを Git リポジトリへ push し、以後 Git を正とする同期を開始します。

flux bootstrap github \
  --owner=<org> \
  --repository=<repo> \
  --branch=main \
  --path=clusters/eu \
  --personal

複数クラスタ・複数 jurisdiction を運用する場合は --path をクラスタごとに変えて bootstrap を繰り返します。

flux bootstrap github --owner=<org> --repository=<repo> --branch=main --path=clusters/us --personal

jurisdiction 別 overlay の Kustomize 構成

base に共通マニフェストを置き、overlays 配下に jurisdiction ごとのディレクトリを作成します。

repo/
├── base/
│   ├── kustomization.yaml
│   ├── namespace.yaml
│   └── deployment.yaml
└── overlays/
    ├── eu/
    │   ├── kustomization.yaml
    │   └── patch-node-selector.yaml
    └── us/
        ├── kustomization.yaml
        └── patch-node-selector.yaml

overlays/eu/kustomization.yaml の実装案です。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: eu-tenant-a
resources:
  - ../../base
labels:
  - pairs:
      jurisdiction: eu
    includeSelectors: true
patches:
  - path: patch-node-selector.yaml
    target:
      kind: Deployment
      name: sovereign-app

patch-node-selector.yaml（eu）の実装案です。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sovereign-app
spec:
  template:
    spec:
      nodeSelector:
        topology.kubernetes.io/region: eu-central-1

patches フィールドは現行の推奨です。ここでは patchesStrategicMerge ではなく patches を優先して使います。

利用方法

必須パラメータ一覧

node affinity / nodeSelector で承認法域ノードに固定する

requiredDuringSchedulingIgnoredDuringExecution は hard constraint です。条件を満たすノードが無ければ Pod はスケジュールされません。

apiVersion: v1
kind: Pod
metadata:
  name: sovereign-app
  namespace: eu-tenant-a
  labels:
    jurisdiction: eu
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: topology.kubernetes.io/region
                operator: In
                values:
                  - eu-central-1
                  - eu-west-1
  containers:
    - name: app
      image: registry.example.com/sovereign-app:1.0.0

単純な一致だけで十分な場合は nodeSelector のみでも固定できます。

spec:
  nodeSelector:
    topology.kubernetes.io/region: eu-central-1

topologySpreadConstraints で法域内のゾーンに分散配置する

法域内で単一障害点を避けるため、承認済みリージョン内のゾーンへ均等分散します。whenUnsatisfiable: DoNotSchedule は条件を満たせない場合にスケジュールを拒否する hard constraint です。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sovereign-app
  namespace: eu-tenant-a
spec:
  replicas: 6
  template:
    metadata:
      labels:
        app: sovereign-app
        jurisdiction: eu
    spec:
      nodeSelector:
        topology.kubernetes.io/region: eu-central-1
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: sovereign-app

Kyverno Policy 例: 承認法域外への配置を拒否する

validate.deny.conditions に AnyNotIn 演算子を使うと、許可リストに含まれない region を持つ Pod を拒否できます。ブロック挙動は現行スキーマの spec.rules[].validate.failureAction（ルール単位）で指定します。旧 spec.validationFailureAction（spec 直下）は非推奨のため使用しません。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deny-non-approved-jurisdiction
spec:
  background: false
  rules:
    - name: deny-non-approved-region
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaces:
                - "eu-tenant-*"
      validate:
        failureAction: Enforce
        message: >-
          region {{ request.object.spec.nodeSelector."topology.kubernetes.io/region" }}
          is not an approved EU jurisdiction
        deny:
          conditions:
            all:
              - key: "{{ request.object.spec.nodeSelector.\"topology.kubernetes.io/region\" || '' }}"
                operator: AnyNotIn
                value:
                  - eu-central-1
                  - eu-west-1

OPA Gatekeeper ConstraintTemplate + Constraint 例

Rego は v1 構文（contains ... if {}）で記述します。Gatekeeper で Rego v1 を使う場合、公式が推奨する現行形は、targets 配下に code: + source: {version: "v1", rego: ...} を構造化して書く方式です（version: "v1" を明示すれば import rego.v1 は不要）。Rego v1 の対応バージョンや推奨記法は更新されるため、利用前に公式ドキュメントで確認してください。ここでは従来型の rego: 直書き例を示すため、明示的に import rego.v1 を付けています。

ConstraintTemplate の実装案です。

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sjurisdictionnodeselector
spec:
  crd:
    spec:
      names:
        kind: K8sJurisdictionNodeSelector
      validation:
        openAPIV3Schema:
          type: object
          properties:
            allowedRegions:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sjurisdictionnodeselector

        import rego.v1

        violation contains {"msg": msg} if {
          input.review.object.kind == "Pod"
          not input.review.object.spec.nodeSelector["topology.kubernetes.io/region"]
          msg := "pod must set nodeSelector topology.kubernetes.io/region for jurisdiction placement"
        }

        violation contains {"msg": msg} if {
          input.review.object.kind == "Pod"
          region := input.review.object.spec.nodeSelector["topology.kubernetes.io/region"]
          allowed := input.parameters.allowedRegions
          not region in allowed
          msg := sprintf("region '%v' is not in allowed jurisdictions %v", [region, allowed])
        }

Constraint の実装案です。

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sJurisdictionNodeSelector
metadata:
  name: eu-jurisdiction-only
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "eu-tenant-a"
  parameters:
    allowedRegions:
      - "eu-central-1"
      - "eu-west-1"

namespace 分離で tenant/jurisdiction 境界を作る

Namespace に jurisdiction と tenant のラベルを付与し、Policy engine の match.namespaces から参照します。

apiVersion: v1
kind: Namespace
metadata:
  name: eu-tenant-a
  labels:
    jurisdiction: eu
    tenant: tenant-a

Kyverno / Gatekeeper の match 条件は namespace 名またはラベルセレクタで絞り込みます。namespace 名を jurisdiction ごとに規則化しておくと、ワイルドカード一致（eu-tenant-* など）で対象を拡張できます。

GitOps repo レイアウトと ArgoCD Application / Flux Kustomization

GitOps リポジトリは前掲の base + overlays 構成をそのまま使います。ArgoCD の場合は overlay ごとに Application を分けます。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: sovereign-app-eu
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/sovereign-platform.git
    targetRevision: main
    path: overlays/eu
  destination:
    server: https://kubernetes.default.svc
    namespace: eu-tenant-a
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Flux の場合は GitRepository と Kustomization を overlay ごとに分けます。

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: sovereign-platform
  namespace: flux-system
spec:
  interval: 5m
  url: https://github.com/example/sovereign-platform.git
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: sovereign-app-eu
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: GitRepository
    name: sovereign-platform
  path: ./overlays/eu
  prune: true
  targetNamespace: eu-tenant-a

jurisdiction を追加するたびに、ArgoCD は Application を、Flux は Kustomization を 1 つ追加する運用になります。

image signing 検証（cosign / Kyverno verifyImages）

イメージ署名は cosign で行います。鍵ペア方式の実装案です。

cosign generate-key-pair
cosign sign --key cosign.key registry.example.com/sovereign-app:1.0.0
cosign verify --key cosign.pub registry.example.com/sovereign-app:1.0.0

keyless（OIDC）署名の実装案です。

cosign sign registry.example.com/sovereign-app:1.0.0
cosign verify \
  --certificate-identity-regexp "https://github.com/example/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  registry.example.com/sovereign-app:1.0.0

クラスタ側は Kyverno の verifyImages で admission 時に署名検証を強制します。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-image-signature
spec:
  webhookConfiguration:
    failurePolicy: Fail
  background: false
  rules:
    - name: check-image
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "registry.example.com/sovereign-app*"
          failureAction: Enforce
          attestors:
            - count: 1
              entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      (cosign.pub の内容を貼付)
                      -----END PUBLIC KEY-----

運用

Policy 違反の検知・監査

Kyverno と OPA Gatekeeper は、いずれも「常時スキャン + レポート化」という同じ運用モデルを取ります。

バックグラウンドスキャンにより、ポリシー適用前に作成済みのリソースや、後からポリシーを追加したケースでも違反を捕捉できます。これは GitOps drift 検知と同じ発想で、「デプロイ時点の検証」だけに依存しない継続的な照合です。

Gatekeeper は Prometheus メトリクスエンドポイントを公開しており、次のような運用が推奨されます。

• 違反件数を監視システムへエクスポートする（Constraint に記録される違反件数の上限 --constraint-violations-limit はデフォルト 20 のため、超過分の取りこぼしに注意する）
• Constraint 単位・重大度単位でアラートをグルーピングする
• ロールアウト時は重複排除・抑制ウィンドウを設定し、アラート疲れを防ぐ

# Gatekeeper: audit-controller の監査ログ確認
kubectl logs -n gatekeeper-system -l control-plane=audit-controller

# Kyverno: 既存リソースの PolicyReport 一覧
kubectl get policyreport -A
kubectl get clusterpolicyreport

監査証跡の取り方

この設計論の監査モデルは、監査ログを別途構築するのではなく Git の変更履歴そのものを監査証跡として扱う 点が特徴です。

• Policy / overlay の変更はすべて Pull Request 経由（peer review 必須）
• CI パイプラインでのポリシーテストが merge の前提条件になる
• git log / commit 署名（GPG）が「誰が・いつ・何を・なぜ変更したか」の一次証跡になる
• ランタイムの Admission 判定ログ（許可/拒否）と PolicyReport が「実際に何が強制されたか」の証跡になる

Git 側（意図の証跡）とクラスタ側（実行結果の証跡）の 2 系統を突き合わせることで、「宣言された policy」と「実際に強制された policy」の一致を検証できます。

Policy の段階導入（audit mode → enforce mode）

新規ポリシーをいきなり enforce（block）で投入すると、想定外のワークロード停止を招きます。両ツールとも共通して次の 2 段階ロールアウトが推奨されます。

• 影響範囲が広い主権系ポリシー（ノード配置・イメージ署名）ほど、非本番 namespace → 一部 namespace → 全 namespace の順に enforce 範囲を広げます
• PolicyReport / Violation をレビューする際は、既存ワークロードのうち何件が違反するかを必ず件数で確認してから enforce に切り替えます

multi-jurisdiction cluster fleet の運用

法域ごとに個別クラスタを持つ構成では、通常 1 クラスタで完結していた運用作業がクラスタ数倍に増えます。

• アップグレード、証明書ローテーション、RBAC 変更、セキュリティパッチ、キャパシティプランニングが法域ごとに発生する
• Git リポジトリに「共通設定」+「法域別 overlay（Kustomize base/overlays 等）」を持たせ、各クラスタ内の GitOps コントローラーがそれぞれ desired state に対して継続的に reconcile する

• overlay の更新は base への commit → 各法域 overlay への merge（または自動生成）→ 各クラスタの GitOps controller が自律的に pull/reconcile、という一方向の流れにします。クラスタへの直接 kubectl apply は drift の原因になるため避けます
• ArgoCD は selfHeal: true で live state のドリフトを自動的に Git 側へ巻き戻せます。Flux は reconcile のたびに drift を補正する挙動が既定です。両者とも「クラスタ側の手動変更は必ず打ち消される」運用を前提にします

ベストプラクティス

契約でなくアーキテクチャで主権を強制する

この設計論の中心原則は次の対比に集約されます。

「Sovereignty policies live in Git, are peer reviewed, tested through CI pipelines, and enforced automatically at deployment time」という原文の通り、主権要件は Git 上のコードとして表現し、CI でテストし、デプロイ時に自動強制するところまで一貫させます。

サプライチェーン: SBOM + image signing + HBOM

SBOM + 署名検証を admission に組み込むことで、「ビルド元・改ざんの有無」まで含めてサプライチェーン全体を検証できます。CNCF Blog はこれをさらに一段掘り下げ、HBOM とファームウェア検証を「OS より下の層」の主権論点として位置づけています。ハードウェア・ファームウェアの provenance が確認できなければ、OS 以上でどれだけ強制しても土台が保証されない、という指摘です。

下位層主権: 自前 identity / 分散ストレージ / ベアメタル

Kubernetes は主にオーケストレーション・ポリシー層を担いますが、その下の層（identity、ストレージ、ハードウェア）が外部事業者に依存していれば、Kubernetes 層で強制した保証は土台から揺らぎます。この設計論は OpenStack コンポーネントによる下位層の自主運用を推奨します。

「OpenStack can be deployed entirely within a controlled environment. No license servers. No mandatory telemetry services. No external dependencies required.」という原文の通り、これらは「外部への強制通信経路を持たない」構成が要点です。

分散主権パターン: federated learning

学習データを法域外へ移動させず、集約後のモデル更新のみを越境させるパターンです。

• 生データはローカルの namespace / cluster に留まり、越境するのは勾配やモデル重みなどの集約更新のみです
• 主権確保のための namespace 境界・ガバナンス統制は、通常ワークロードと同じ仕組み（policy engine、admission、RBAC）を流用します
• フレームワーク選定の目安は次のとおりです

Policy as Code の CI テスト

Policy をコードとしてテストすることで、「Git に merge される前に」影響範囲を検証できます。

# Kyverno CLI: クラスタ接続不要でポリシーの単体テスト
kyverno test ./policies/sovereignty-node-placement/

# conftest: 構造化データ (Kubernetes manifest 等) を Rego ポリシーで検証
conftest test deployment.yaml -p policy/

# OPA: Rego ルールそのものの単体テスト
opa test policy/ -v

• kyverno test はクラスタ接続なしでローカル実行できるため、PR の CI で「デプロイ前」に軽量チェックできます
• conftest / opa test は Rego ポリシー自体の単体テストに向き、Gatekeeper に投入する前にロジックの正しさを検証します
• CI をブロッキングにする前に、まず non-blocking（警告のみ）で運用し、誤検知の洗い出しを終えてから必須チェック化するのが安全です

トラブルシューティング

「Kubernetes だけで主権が完結しない」限界

Kubernetes 層の admission・ノードアフィニティ・ポリシーエンジンは、あくまで強制手段の一部です。この設計論自身、次の限界を明示しています。

• 下位層への依存が残る: Kubernetes 自体が、法域外の事業者が運用するプラットフォーム上で動いている場合、Kubernetes 層で強制した保証は土台から揺らぎます。「If that foundation is tied to a platform operated by an organization outside your jurisdiction, some of the guarantees enforced at the Kubernetes layer become harder to maintain.」という原文の通りです。identity（Keystone）・ストレージ（Ceph）・ベアメタル（Ironic）まで自主運用して初めて、Kubernetes 層の保証が意味を持ちます
• クラウド事業者の法的支配は技術で消せない: US CLOUD Act のように、司法管轄がサーバー所在地でなく親会社の法人格に従う法制度が存在します。暗号化や地理的配置だけでは、事業者自身が域外法の適用対象である限り、開示強制のリスクは解消しません。真に解消するには、事業者自体の法域を変えるか、事業者に依存しない自主運用（self-hosted）構成にするかのいずれかが必要です
• 技術的強制と法的強制は別レイヤー: Admission Controller は「ポリシーに反するワークロードを止める」ことはできても、「事業者が司法当局からの開示命令に応じない」ことは保証できません。アーキテクチャによる強制は「意図しない設定・人為的ミスによる違反」を防ぐ手段として有効な一方、「主権国家の法的強制力」に対する防御は、事業者の法人格・所在地・準拠法の設計を伴わなければ完結しません

まとめ

データ主権は「どのリージョンに置くか」ではなく、「誰が法的にデータ提出を強制されうるか」の問題です。この記事では、その主権要件を契約書の約束から、Kubernetes の admission・node affinity・GitOps・サプライチェーン検証による技術的強制へ移す参照アーキテクチャを、構造・データ・構築・運用の観点で整理しました。

Kubernetes 層だけでは、クラウド事業者の法的支配や下位層への依存という問題は完結しません。それでも「意図しない設定ミスによる主権違反」を防ぐ強制手段としては有効です。契約による統治から、コードとして検証・強制できる主権へ、設計の重心を移す一歩になります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

概要 / 規制

• How data sovereignty is changing cloud native infrastructure design | CNCF Blog (2026-07-03)
• Cloud and AI Development Act | Shaping Europe's digital future (European Commission)
• The EU's Cloud and AI Development Act (CADA) | HLC
• European Commission's Proposed Cloud Sovereignty Framework | Jones Day
• The EU Cloud and AI Development Act in Depth | Inside Global Tech
• U.S. CLOUD Act And Why Corporate Structure Matters For Data Sovereignty | UpCloud
• How the US CLOUD Act and FISA 702 Create Legal Exposure for EU Cloud Data | SoftwareSeni
• The CLOUD Act and UK Data Protection: Why Jurisdiction Matters | Kiteworks
• Gaia-X - Wikipedia
• About - Gaia-X: A Federated Secure Data Infrastructure

構造 / Policy engine

• ValidatingAdmissionPolicy | Kubernetes
• Kyverno Introduction
• OPA Gatekeeper Documentation
• Argo CD Architecture Overview
• Ironic Documentation | OpenStack
• Sigstore Policy Controller Overview
• sigstore/policy-controller | GitHub
• fluxcd/kustomize-controller | GitHub
• fluxcd/helm-controller | GitHub

データ / サプライチェーン標準

• Constraint Templates | Gatekeeper
• How to use Gatekeeper
• Validate Rules | Kyverno
• Resource Definitions | Kyverno
• Pod Topology Spread Constraints | Kubernetes
• SLSA • Provenance
• CycloneDX Bill of Materials Standard
• A Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management | CISA
• SBOMs in the Era of the CRA | OpenSSF

構築 / 利用

• Kyverno Installation
• Kyverno Image Verification (Sigstore)
• Installation | Gatekeeper
• Argo CD Getting Started
• Argo CD Kustomize integration
• Flux Installation
• Flux Repository Structure
• Declarative Management of Kubernetes Objects Using Kustomize
• Assign Pods to Nodes using Node Affinity
• Sigstore cosign

運用 / トラブルシューティング

• Policy Reports | Kyverno
• Audit | Gatekeeper
• GitOps policy-as-code: Securing Kubernetes with Argo CD and Kyverno | CNCF
• Kubernetes Drift Detection with Policy-as-Code | Nirmata
• Testing Policies | Kyverno
• Upgrading to v1.0 | Open Policy Agent
• Kubernetes Policy Controller - Sigstore
• Verify Signed Kubernetes Artifacts | Kubernetes
• Welcome to NVIDIA FLARE documentation
• Federated Learning on GPU Cloud: Flower, NVIDIA FLARE, OpenFL | Spheron Blog