CNCFにおける認可モデル
CNCFの認可モデルは、従来のロールベースやパーミッションベースのモデル (Model)を単純に採用するのではなく、 それらを統合し、実行時に一貫した判断ができる構造として再設計されたものです。
本稿では、その中核となる考え方である「Capability (ケーパビリティ)」と「Guard」を軸に、 操作 (Operation)レベルとリソースレベルの二層構造としての認可モデルを解説します。
認可モデルの全体像
CNCFの認可モデルはCapabilityとGuardを軸に構成されます。 Capabilityは「許可（できること）」を表し、Guardは「拒否または制約 (Constraint)（今やってよいか）」を表します。
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を供給する手段として機能します。
ACL
ACL（Access Control List）は、リソース単位で個別に権限を指定する仕組みです。 Permissionよりも低レベルで、直接的にCapabilityを付与する手段として機能します。
Guards：条件としての制約
GuardはCapabilityの利用可否を制御する条件であり、単独では権限を与えません。 ABACは属性 (Attribute)に基づく制約を表現しますが、ReBACは主体と対象の関係に基づく制約を表現し、ABACでは記述しにくい認可条件を補完します。
Guardsは以下の2つの認可機構を使用します。
-
ABAC
-
ReBAC
ReBAC
ReBAC（Relationship (モデル関係)-Based Access Control）は、主体と対象の関係に基づいてアクセスを制御します。 例えば「オーナーである」「担当者である」といった関係がGuardとして評価されます。
ReBACは、ABACでは表現が難しい「関係性」に基づく認可制約を記述するために重要です。 例えば、あるユーザーが特定のリソースのオーナーであるかどうかといった条件は、単純な属性比較ではなく関係として評価されます。
例えば以下のような関係がGuardとして評価されます。
-
投稿の作成者
-
担当者
具体例：ニュース記事操作
ニュース記事の操作を考えてみます。
しかし実際には、以下の複数のリソースが関係します。
-
記事（News Article）
-
画像（Image）
-
添付関係（Article–Image association）
さらに、この操作が許可されるかどうかは、主体と記事との関係に依存 (Dependency)します。
例えば、記事の作成者である、編集担当者であるといった関係です。
このように、「記事に画像を添付する」という単一の操作でも、複数リソースの関係と主体とリソースの関係の両方が関与します。
このようなケースでは、単純な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 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- 操作 (Operation)
-
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
- ケーパビリティ (Capability)
-
ケーパビリティ(Capability)とは、モデルまたはシステムが利用者や対象領域に対して何を可能にするかを表す概念です。実現方法ではなく、提供できる結果や働きに着目します。
- 制約 (Constraint)
-
UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。
- 属性 (Attribute)
-
Attributeとは、ClassifierのInstanceが保持し得る値または参照を表すStructural Featureです。Attributeは名前、Type、Multiplicity、既定値、Constraintなどによって特徴付けられます。
- モデル関係 (Relationship)
-
Undefined
- 依存 (Dependency)
-
UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。