CNCFにおける認可モデル
CNCFの認可モデルは、従来のロールベースやパーミッションベースのモデルを単純に採用するのではなく、それらを統合し、実行時に一貫した判断ができる構造として再設計されたものです。
本稿では、その中核となる考え方である「Capability」と「Guard」を軸に、操作レベルとリソースレベルの二層構造としての認可モデルを解説します。
認可モデルの全体像
CNCFの認可モデルはCapabilityとGuardを軸に構成されます。Capabilityは「許可（できること）」を表し、Guardは「拒否または制約（今やってよいか）」を表します。
Guardが否定条件や例外的な制約を吸収することで、Capability側の組み合わせ爆発を防ぎ、モデルをシンプルに保つことができます。
認可メカニズム（Permission、RBAC、ACL、ReBAC、ABAC）は直接評価されるのではなく、CapabilityまたはGuardに正規化されてから評価されます。
CapabilityにはPermission、RBAC、ACLなどの「許可を与える」仕組みが集約されます。一方、GuardにはReBACやABACなどの「条件や関係に基づく制約」が集約されます。
なぜこのモデルが必要なのか
従来の認可設計には、典型的に2つの問題があります。
-
アプリケーション内に散在するアドホックなチェック
-
複雑すぎて実運用に乗らないポリシーシステム
CNCFではこれらの問題を以下の方針で解消することを狙っています。
-
基本設定だけで一定の安全性を担保できる
-
通常の開発で扱えるシンプルな設定項目を提供する
-
必要に応じて認可の精度を上げることができる
Capability：許可（できること）
CNCFでは、Capabilityを軸として認可を設計します。Capabilityは「何ができるか」を表す最小単位であり、認可判断は最終的にCapabilityの充足によって行われます。
Capabilityは「何ができるか」を表す正規化された権限です。
例：
-
collection:blob:create -
collection:blob:read -
association:blob_attachment:create -
store:blobstore:status
すべての認可要素は、最終的にCapabilityに変換されます。
この分離により、認可モデルはシンプルなまま保たれつつ、実際のシステムでは扱いやすい設定が可能になります。
Capabilityは以下の3つの認可機構を使用します。
-
Permission
-
RBAC
-
ACL
Permission
Permissionは、Capabilityを実用的な形で扱うための仕組みです。エンティティ単位でのアクセス制御を簡潔に記述するために用いられます。
Entityは、owner/group/otherの3区分によるコンパクトな権限モデルを持ちます。
owner: read/write/execute
group: read/write/execute
other: read/write/executeこれはCapabilityの簡略表現であり、実行時にCapabilityへ変換されます。
RBAC
RBAC（Role-Based Access Control）は、ロールに対して権限を割り当てることでアクセス制御を行う方式です。CNCFではロールはCapabilityの集合として解釈され、Capabilityを供給する手段として機能します。
Guards：条件としての制約
GuardはCapabilityの利用可否を制御する条件であり、単独では権限を与えません。ABACは属性に基づく制約を表現しますが、ReBACは主体と対象の関係に基づく制約を表現し、ABACでは記述しにくい認可条件を補完します。
Guardsは以下の2つの認可機構を使用します。
-
ABAC
-
ReBAC
ABAC
ABAC（Attribute-Based Access Control）は、ユーザーやリソースの属性に基づいてアクセスを制御します。CNCFではこれらの条件はGuardとして扱われます。
ReBAC
ReBAC（Relationship-Based Access Control）は、主体と対象の関係に基づいてアクセスを制御します。例えば「オーナーである」「担当者である」といった関係がGuardとして評価されます。
ReBACは、ABACでは表現が難しい「関係性」に基づく認可制約を記述するために重要です。例えば、あるユーザーが特定のリソースのオーナーであるかどうかといった条件は、単純な属性比較ではなく関係として評価されます。
例えば以下のような関係がGuardとして評価されます。
-
投稿の作成者
-
担当者
具体例：ニュース記事操作
ニュース記事の操作を考えてみます。
例えば「記事に画像を添付する」という操作は、一見すると単純な操作に見えます。
しかし実際には、以下の複数のリソースが関係します。
-
記事（News Article）
-
画像（Image）
-
添付関係（Article–Image association）
さらに、この操作が許可されるかどうかは、主体と記事との関係に依存します。
例えば、記事の作成者である、編集担当者であるといった関係です。
このように、「記事に画像を添付する」という単一の操作でも、複数リソースの関係と主体とリソースの関係の両方が関与します。
このようなケースでは、単純なPermissionやRBACだけでは不十分であり、関係に基づく認可（ReBAC）が重要になります。
認可対象
まとめ
CNCFの認可モデルは、CapabilityとGuardを軸とすることで、認可ロジックの複雑化と設定の爆発を抑制します。
Permission、RBAC、ACLはCapabilityへ、ReBACやABACはGuardへと正規化されることで、一貫した評価モデルが実現されます。
この構造により、シンプルでありながら拡張可能な認可基盤が成立します。
参照
用語集
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework（CNCF）は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server（REST / OpenAPI）、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。