例 2: OPA と Rego を使用したマルチテナントアクセスコントロールとユーザー定義 RBAC

この例では、OPA と Rego を使用して、テナントユーザーが定義したカスタムロールを持つマルチテナントアプリケーションの API でアクセスコントロールを実装する方法を示します。また、テナントに基づいてアクセスを制限する方法も示します。このモデルは、高レベルのロールで提供される情報に基づいて、OPA がきめ細かなアクセス許可の決定を行う方法を示しています。

テナントのロールは、OPA のアクセス決定を行うために使用される外部データ (RBAC データ) に保存されます。

{
    "roles": {
        "tenant_a": {
            "all_access_role": ["viewData", "updateData"]
        },
        "tenant_b": {
            "update_data_role": ["updateData"],
            "view_data_role": ["viewData"]
        }
    }
}

これらのロールは、テナントユーザーによって定義された場合、テナント定義ロールをアクセス許可とテナント自体にマッピングする際に信頼できるソースとして機能する外部データソースまたは ID プロバイダー (IdP) に保存する必要があります。 

この例では、OPA で 2 つのポリシーを使用して認可の決定を行い、これらのポリシーがテナント分離をどのように適用するかを調べます。これらのポリシーは、前に定義した RBAC データを使用します。

default allowViewData = false
allowViewData = true {
    input.method == "GET"
    input.path = ["viewData", tenant_id]
    input.tenant_id == tenant_id
    role_permissions := data.roles[input.tenant_id][input.role][_]
    contains(role_permissions, "viewData")
}

このルールがどのように機能するかを示すには、次の入力を持つ OPA クエリを検討してください。

{
    "tenant_id": "tenant_a",
    "role": "all_access_role",
    "path": ["viewData", "tenant_a"],
    "method": "GET"
}

この API コールの承認決定は、RBAC データ、OPA ポリシー、および OPA クエリ入力を組み合わせることで、次のように行われます。

1. のユーザーは、 への API コールTenant Aを行います/viewData/tenant_a。

2. データマイクロサービスは呼び出しを受け取り、allowViewDataルールをクエリして、OPA クエリ入力の例に示されている入力を渡します。

3. OPA は、OPA ポリシーのクエリされたルールを使用して、指定された入力を評価します。また、OPA は RBAC データからのデータを使用して入力を評価します。OPA は以下を実行します。

   1. API コールの実行に使用されるメソッドが であることを確認しますGET。

   2. リクエストされたパスが であることを確認しますviewData。

   3. パスtenant_idの がユーザーinput.tenant_idに関連付けられた と等しいことを確認します。これにより、テナントの分離が維持されます。同じロールを持つ別のテナントは、この API コールの実行を承認できません。

   4. ロールの外部データからロールのアクセス許可のリストを取得し、変数 に割り当てますrole_permissions。このリストは、 のユーザーに関連付けられているテナント定義のロールを使用して取得されます。 input.role.

   5. アクセス許可が含まれているrole_permissionsかどうかを確認します viewData.

4. OPA は、データマイクロサービスに次の決定を返します。

{
    "allowViewData": true
}

このプロセスは、RBAC とテナントの認識が OPA による認可の決定にどのように役立つかを示しています。この点をさらに説明するために、次のクエリ入力/viewData/tenant_bを使用して への API コールを検討してください。

{
    "tenant_id": "tenant_b",
    "role": "view_data_role",
    "path": ["viewData", "tenant_b"],
    "method": "GET"
}

このルールは、ロールが異なる別のテナントの OPA クエリ入力と同じ出力を返します。これは、この呼び出しが 用/tenant_bであり、RBAC データの view_data_role には引き続き、それに関連付けられた viewData アクセス許可があるためです。に同じタイプのアクセスコントロールを適用するには/updateData、同様の OPA ルールを使用できます。

default allowUpdateData = false
allowUpdateData = true {
    input.method == "POST"
    input.path = ["updateData", tenant_id]
    input.tenant_id == tenant_id
    role_permissions := data.roles[input.tenant_id][input.role][_]
    contains(role_permissions, "updateData")
}

このルールは機能的にはallowViewDataルールと同じですが、別のパスと入力メソッドを検証します。このルールは引き続きテナントの分離を保証し、テナント定義ロールが API 発信者に許可を付与することを確認します。これがどのように適用されるかを確認するには、 への API コールの次のクエリ入力を調べます/updateData/tenant_b。

{
    "tenant_id": "tenant_b",
    "role": "view_data_role",
    "path": ["updateData", "tenant_b"],
    "method": "POST"
}

このクエリ入力は、 allowUpdateData ルールで評価されると、次の認可決定を返します。

{
    "allowUpdateData": false
}

この呼び出しは承認されません。API 発信者は正しい に関連付けられtenant_idており、承認された方法を使用して API を呼び出していますが、 input.roleはテナント定義の ですview_data_role。には アクセスupdateData許可view_data_roleがないため、 の呼び出し/updateDataは許可されていません。この呼び出しは、 を持つtenant_bユーザーに対して成功しましたupdate_data_role。