メインコンテンツまでスキップ

認可コンパイラ (Authorization Compiler)

認可コンパイラは、人間がレビューできる認可仕様を、実行可能なポリシー成果物へ変換します。Ninka では、その認可仕様が 手形 (Tegata) です。

要件
    ↓
手形                   人間がレビューする認可仕様
    ↓
関所 (Sekisho)         機械的に判定できる検査
    ↓
Ninka コンパイラ        決定論的な変換
    ↓
Rego + メタデータ
    ↓
固定された OPA で build 再現可能な実行成果物の生成
    ↓
Execution Bundle
    ↓
Consumer Projection
    ↓
Ninka ランタイム
    ↓
判定

重要なのは「AI を使うかどうか」ではなく、責任をどこで分けるかです。AI は認可仕様の作成を支援できます。人間は、その仕様が意図した認可要件を表しているかをレビューします。その後の実行成果物への変換は toolchain が機械的に担います。

手形から Rego までは決定論的に変換する​

Ninka コンパイラは、canonical な手形を Rego へ決定論的に変換します。同じ canonical な手形を同じ Ninka リリースでコンパイルすれば、Rego はバイト単位で同一になります。

この保証は Rego までです。WASM は、その後の OPA build で生成します。Ninka は既定の OPA toolchain を固定し、同じ build 条件で実行成果物を再現できるようにしています。

同じ canonical な手形 + 同じ Ninka リリース
    → バイト単位で同一の Rego

同じ Rego + 同じ固定 OPA toolchain / build 契約
    → 再現可能な WASM

したがって、Ninka コンパイラ単体が WASM まで決定論的に生成するわけではありません。

承認の完全性は、3 つの別々の主張でできている​

「人がこれを承認した」から「このバイト列が動いている」までの連鎖は、1 つの主張ではありません。 3 つあり、混ぜてはいけません。

  1. 同じ tegata_hash は、同じ正規の認可仕様を表す
  2. 同じ Ninka のリリースは、その仕様からバイト単位で同一の Rego を導く
  3. 動いている成果物は、rego_sha256・wasm_sha256・両者をつなぐ build の系譜によって、 その仕様へ束縛されている

3 つを 1 つに畳むと、Ninka について最も多い誤読が生まれます。tegata_hash が実行される バイト列を識別している、という読み方です。tegata_hash が識別するのは、人がレビューした 仕様のほうです。そこから先へ identity を運ぶのは、成果物のハッシュです。

仕様の identity と成果物の identity は別​

それぞれの識別子は、別の対象を識別します。

  • tegata_hash：どの canonical な認可仕様か
  • rego_sha256：どの Rego バイト列か
  • wasm_sha256：どの実行用 WASM バイト列か
  • generated_by / opa_version：どの Ninka / OPA リリースで生成したか

最初の三つは、それぞれ異なる対象の identity です。generated_by と opa_version は生成元を示す provenance であり、認可仕様そのものの identity ではありません。

後段の処理が上流の判断を独自に再計算しなくてよいように、これらの情報を成果物として受け渡します。

コンパイラが導出し、成果物が宣言し、ランタイムが検証して実行する。

たとえば、ポリシーの entrypoint を導出するのはコンパイラです。生成されたメタデータが policy・Rego・entrypoint・実行 bundle の対応を宣言し、ランタイムが宣言どうしと実際の module を照合します。ランタイム側で別の entrypoint 命名規則を持つことはありません。

必要な identity や結び付きが検証できなければ、問題の無い部分だけを使うのではなく、その bundle 全体を拒否します。

成果物の正確なフィールドと形式は 生成ファイル を参照してください。

verify は再現性を検査し、確認できない項目は明示する​

ninka-authz verify は、現在の手形と toolchain の契約からソース由来の状態を再生成し、既存の生成物と比較します。固定された OPA toolchain を利用できる場合は、実行 bundle も再 build し、WASM に対する validation も必要な範囲で再実行します。

WASM まですべて検査済みの green な結果であれば、検査した生成状態について再現性の証拠になります。ただし、人間が手形を承認したことや、以前の認可実装と同じ挙動であることを示すものではありません。

一方、固定された OPA toolchain を取得できない環境では、WASM 関連の検査が not checked と明示されたまま exit 0 になる場合があります。これは「一致を確認した」という意味ではありません。成功・失敗・スキップの正確な扱いは CLI リファレンス を参照してください。

また、verify は Git を参照しません。生成ファイルを Git で追跡する方針と、ディスク上の成果物を検証することは別の問題です。

Validation は、コンパイラ自身の出力だけを基準にしない​

Ninka は手形から validation 用の入力を導出しますが、期待される判定は、生成された Rego とは独立した reference evaluator が手形の意味論から決めます。そのうえで、生成された WASM が同じ判定を返すことを確認します。

これにより、検査対象の変換ロジックと同じロジックで期待値まで作り、同じ誤りを「正しい」と判定してしまう構造を避けています。

ただし validation にも範囲があります。Ninka が導出できる変換上の義務を検査するものであり、元の業務要件が正しかったかどうかは判断しません。そこは人間のレビューに残ります。

OPA は build 時に使い、リクエスト処理には入らない​

OPA が担当するのは、Rego から実行用の WASM を build する工程です。実行時の認可判定で OPA サーバへ通信することはありません。アプリケーション内の Ninka ランタイムが、検証済みの bundle をプロセス内で評価します。

Ninka は別のホスト型認可サーバを増やすためのものではありません。認可の意図とアプリケーションでの適用の間に、レビュー可能な認可仕様と、検証可能なコンパイル・build の経路を置くものです。

Consumer Projection がアプリケーションとの境界になる​

Consumer Projection は、生成されたアプリケーション向けのモジュールです。policy reference、型付きの入力契約、実行 bundle、そしてランタイムが bundle を検証するために必要なメタデータを運びます。

アプリケーション
      │
      ▼
Consumer Projection
      │
      ▼
Ninka ランタイム → ALLOW / DENY

いつ認可判定を呼ぶか、どの具体的なリソースを対象にするか、入力をどう組み立てるか、返された判定をどう適用するかはアプリケーション側の責任です。

Authorization Reference は表示用のビューであり、別の権威ではない​

Authorization Reference は、手形と生成済みの状態を、人間が読んだり具体例を試したりできる形で表示します。プロジェクトを編集・コンパイルせず、独自の認可意味論も定義しません。

最後のコンパイル後に仕様だけが変わった場合、LIVE モードはコンパイル済みの状態を STALE として扱い、古い成果物を現在のポリシーとして評価しません。

関連項目​