ロールと条件#

#目的

Data Platformは、プロジェクト内の権限を管理するためにロールベースのアクセス制御アプローチを使用します。ロールは、ユーザー、サービスアカウント（プロジェクトIAMのみ）、またはグループに割り当てることができる一連の権限です。これにより、プロジェクト/組織内のリソースやデータにアクセスすることができます。条件を使用すると、より細かい制御が可能になり、指定された条件が満たされた場合にのみアクセスを許可できます。例えば、リクエストが勤務時間中に行われた場合、またはリクエストされたリソースに特定のタグが付いている場合などです。

各ユーザーまたはサービスアカウントは、1) ロールを通じて個別に付与された権限と、2) 所属するグループに付与された権限の合計を持っています。

#ロール

IAMには2種類のロールがあります：

• 事前作成されたロール：プロジェクトまたは組織内の人気のあるサービスとリソースの組み合わせにアクセスを提供します。これらはData Platformによって管理されます。
• カスタムロール：ユーザーが指定した権限のリストに基づいて細かいアクセスを提供します。

#事前作成されたロール

Data Platformには、プロジェクトや組織に典型的な権限を簡単に付与できるように設計された多くの事前作成されたIAMロールが付属しています。

例えば、プロジェクトIAMの事前作成されたロールのリストを以下に示します。最も人気のあるものから始めます：

• Admin：プロジェクト全体に対するフル管理者アクセスを付与します
• Application User：プロジェクトのカスタムAPIをクエリするアクセスを付与します。これは通常、アプリケーションからアクセスする場合です。これは、ロール条件を使用してデータアクセスを制御する必要があるエンドユーザーに付与するロールです。
• Analytics Consumer：これは、外部コンサマーを使用して分析を実行するユーザーに通常付与されます。このロールは、データソースとテーブルへの読み取りアクセスと、それらに対するクエリの作成と実行の能力を付与します。
• Dashboard Editor：Analytics Managerでクエリとダッシュボードを作成する権限を付与します
• Dashboard Viewer：Analytics Managerのダッシュボードの読み取り専用バージョンにアクセスする権限を付与します
• Read-only：プロジェクト内のすべてのリソースへの読み取りアクセスを付与します
• AM Admin：Analytics Manager内のすべてのリソースに対するフル管理者アクセスを付与します
• API & App Editor：すべてのカスタムAPIとアプリケーションに対するフル管理者アクセスを付与します
• Control Center Editor：Control Center内のすべてのリソースに対するフル管理者アクセスを付与します
• LM & AM Editor：Lakehouse Manager（バケットを除く）とAnalytics Manager内のすべてのリソースに対するフル管理者アクセスを付与します
• DPE Editor：Data Processing Engine内のすべてのリソースに対するフル管理者アクセスを付与します
• DataStore Editor：バケット内のすべてのリソースに対するフル管理者アクセスを付与します
• Identity Access Manager Editor：Identity Access Manager内のすべてのリソースに対するフル管理者アクセスを付与します

#ロールの作成

#Identity Access Managerインターフェースから

Identity Access Managerで、Rolesタブを開きます。画面の右上にあるNew Roleをクリックします。

ロールは、特定のリソースに対する権利である原子的な権限で定義されます。 ロールの画像、名前、説明、タグを入力した後、Add Permissionをクリックしてロールに新しい権限を追加します。

権限は、次の要素を指定することで定義されます：

• サービスとリソース、すなわち権限によってアクセスが許可されるプロジェクトリソース（例：Data Processing Engine：アクション、ワークフローなど）
• アクション、すなわちこのサービスとリソースに対するどのようなアクセスが許可されるか（例：作成、読み取り、削除など）

ロールに任意の数の権限を追加できます。例えば、以下のロールは、DPEのワークフローへのフルアクセスと、別のサービスのすべてのリソースに対する読み取り専用の権限を組み合わせています。

最後に、Createをクリックしてロールを保存します。

#APIを使用して

# {permission} should be replaced by one or multiple permissions.
# A permission has the following format: "service:resource:action"
# e.g.:
# "iam:user:read": will give read-only access to the users list of a Project

curl --request POST \
  --url '/roles' \
  --header 'content-type: application/json' \
  --data '{
	"display_name": "My role",
	"permissions":[{permission}]
}'

#ユーザー、サービスアカウント、またはグループにロールをバインドする

#Identity Access Managerインターフェースから

このプロセスは、ユーザー、サービスアカウント、グループにとって同じです。それらのいずれかにロールをバインドするには、Identity Access Managerのそれぞれのタブに移動するだけです。

ユーザー/サービスアカウント/グループを選択し、行の末尾にあるEdit ✏️ボタンをクリックします。

Role ConditionsボックスでAddをクリックします。

ドロップダウンメニューからバインドしたいロールを選択します。ロールバインドに条件を設定することもできます（後述）。

Createをクリックし、Saveをクリックします。

#APIを使用して

# {type} should be replaced by "users", "service_accounts" or "groups"
# {id} should be replaced by the id of the user, service account or group you want to edit
# {roleId and anotherRoleId} should be the id of the roles to add

## REMEMBER that it will replace all the roles of the edited object. It won't keep other roles already there, so be careful not to remove existing roles.

curl --request PUT \
  --url '/{type}/{id}' \
  --header 'content-type: application/json' \
  --data '{
    "roles": [{
      "role":"{roleId}"
    },{
      "role":"{anotherRoleId}"
    }]
}'

#条件

条件は、ロールに付与された権限に設定できるフィルターです。ユーザー/サービスアカウント/グループにロールをバインドする際に使用します。

デフォルトでは、ロールは条件なしでバインドされます。条件を設定せずにロールをバインドすると、そのロールの権限で説明されている制限なしの完全なアクセスが付与されます。条件を追加すると、権限によって提供されるアクセスを、より特定のリソース、または特定のプロパティを検証するユーザーに対してのみフィルタリングできます。

ただし、Name.contains("dev-")のような条件を追加すると、このロールはユーザーにアラート名に_"dev-"_を含むアラートのみの編集アクセスを付与し、他のアラートは編集できなくなります。

現在、2つの条件モデルが共存しています:レガシーJSON条件と新しいCEL条件です。新しいCEL条件をサポートするロールに対しては、レガシーJSON条件を作成することはできません。各モデルの互換性情報は下記を参照してください。

#新しいCEL条件

CEL条件は、Common Expression Language (CEL)を使用して表現されます。論理ステートメントをブール演算子（AND、OR）を使用して組み合わせたもので、各論理ステートメントは次の要素で構成されます：

• 属性
• 演算子（属性に適用される関数を含む）
• 値

一般的に、CEL条件は、ロールの権限で説明されているリソース、またはロールが付与されるIAMプリンシパル（近日中に提供!）、またはその両方に適用できます。さらに、条件はロールによって付与される権限の要素に適用でき、ロールの一部のみに条件を細かく設定できます。すべての属性と演算子の参照は下記を参照してください。

#条件属性

現在、Identity Access Managerで利用可能な次の条件（すなわち、条件の属性）があります：

• ロールの権限に対する条件
  • サービス（CEL名：Service）：権限で説明されているリソースを含むData Platformサービスに条件を適用します（例："Data Processing Engine"、"Analytics Manager"など）。
  • リソース（CEL名：Resource）：権限で説明されているData Platformリソースに条件を適用します（例："Workflows"、"Dashboards"など）。
  • アクション（CEL名：Action）：権限によってリソースに付与されるアクセスに条件を適用します（例："Read"、"Write"など）。
• リソースに対する条件

  • ID（CEL名：Id）：リソースのIDに条件を適用します。

  • 技術名（CEL名：Name）：リソースの技術名に条件を適用します。

  • パス（CEL名：Path）：リソースのパスに条件を適用します。

• ポリシータグに対する条件（高度なデータアクセス制御）
  • ポリシータグ値（CEL名：PolicyTags.<key>）：リソースに割り当てられたポリシータグの値に条件を適用します。<key>をタグキー名（例：PolicyTags.sensitivity == "high"）で置き換えます。ロールがサービスadacの権限を含む場合に利用可能です。
  • ポリシータグ存在（CEL名：has(PolicyTags.<key>)）：リソースにポリシータグキーが存在するかどうかを確認します（例：has(PolicyTags.sensitivity)）。タグキーが存在する場合は、その値に関係なくtrueを返します。

• ユーザー/サービスアカウントに対する条件：近日中に提供！

#条件演算子

現在、Identity Access Managerで利用可能な次の条件（すなわち、条件の演算子）があります。

• 等しい（CELモデリング：attribute == ""）
• 等しくない（CEL名：attribute != ""）
• 含まれる（CEL名：attribute in []）
• 含まれない（CEL名：!(attribute in [])）
• 開始する（CEL名：attribute.startsWith("")）
• 開始しない（CEL名：!(attribute.startsWith(""))）
• 終了する（CEL名：attribute.endsWith("")）
• 終了しない（CEL名：!(attribute.endsWith(""))）
• 一致する（CEL名：attribute.matches("")）
• 一致しない（CEL名：!(attribute.matches(""))）
• 含む（CEL名：attribute.contains("")）
• 含まない（CEL名：!(attribute.contains(""))）

#例

Common Expression Language (CEL)の条件の例をいくつか示します：

1. リソースを"demo"のみに制限：

Name == "demo"

2. フォルダー"my_folder"に含まれるワークフローのみにアクセスを制限し、ロールが最初にワークフローとその他のリソースへのアクセスを付与している場合は、その他のリソースへの完全なアクセスを付与：

Resource != "workflow"
||
(
  Resource == "workflow"
  &&
  Path.contains("/my_folder")
)

3. バケット名が"my_bucket"のもの（関連サービス名はdatastore）のみにアクセスを制限し、ロールが最初に少なくともバケットとその他のサービスのリソースへのアクセスを付与している場合は、その他のサービスのリソースへのアクセスを付与（この条件は、バケットではないdatastoreのリソースへのアクセスをブロックします）：

Service != "datastore"
|| 
(
	Service == "datastore"
	&&
	Resource == "bucket"
	&&
	Name == "my-bucket" 
)

4. データセット、テーブル、属性の3つのレベルでポリシータグを強制（関連サービス名はadac）。これは完全なアクセス制御に推奨されるパターンです：

Service == "adac" && (
  (PolicyTags.access_level == "level 1" && Resource == "dataset")
  || (PolicyTags.access_level in ["level 1", "level 2"] && Resource == "table")
  || (PolicyTags.access_level in ["level 1", "level 2"] && Resource == "attribute")
)

5. sensitivity: highでタグ付けされたテーブルへのアクセスを付与し、データセットと属性レベルではパススルー（そのレベルではタグ強制なし）：

Service == "adac" && (
  Resource == "dataset"
  || (PolicyTags.sensitivity == "high" && Resource == "table")
  || Resource == "attribute"
)

6. sensitivityポリシータグのないすべてのテーブルへのアクセスを付与：

Service == "adac" && (
  Resource == "dataset"
  || (!has(PolicyTags.sensitivity) && Resource == "table")
  || Resource == "attribute"
)

#ロールバインド時に条件を追加

ロールバインドに条件を追加する方法は2つあります。

• ビジュアルビルダーは、フィールド、演算子、値（例：リソース名がmy_bucketと等しい）を使用して条件を指定するポイントアンドクリックインターフェースを提供します。
• カスタムCELエディタは、Common Expression Language (CEL)を使用して類似の条件を作成する条件ライターです。

チュートリアル：特定のバケットに対するロール条件の構築方法

#レガシーJSON条件

レガシーJSONエディタは、JSON形式を使用した条件ライターです。JSON条件は現在非推奨であり、新しいCEL条件に自動的に移行されます。

#特定のデータ値にロール条件を追加

アプリケーションまたはAPI内の特定のデータ値へのアクセスを制限するには、API関連の権限のfilterパラメータを使用する必要があります。

まず、API * *へのアクセスを持つロールを作成します。

次に、このロールを選択したグループ/ユーザーにバインドし、ロール条件を追加します。

バインドにfilterパラメータを条件として設定します。filterパラメータは、各属性の属性名と値のリストの辞書を受け付けます。

{
  "filter": {
    "station_id": [
      40010
    ]
  }
}

filterに複数の値を入力できます。複数の属性を一度にフィルタリングする（AND演算子）か、属性の複数の値をフィルタリングする（OR演算子）ことができます。

#特定のバケットにロール条件を追加

Lakehouse Manager内の特定のバケットへのアクセスを制限するには、Data store関連の権限のbucket_nameパラメータを使用する必要があります。

まず、datastore * *へのアクセスを持つロールを作成します。

次に、このロールを選択したグループ/ユーザーにバインドし、bucket_nameパラメータをバインドにロール条件として追加します。

{
  "bucket_name": "mybucket" 
}

#さらに詳しく

当社のソリューションを実装するためのトレーニングや技術サポートが必要な場合は、営業担当者にお問い合わせください、またはこのリンクをクリックして見積もりを依頼し、プロフェッショナルサービスの専門家にプロジェクトのカスタム分析を依頼してください。

Discord チャネルで質問をしたり、フィードバックを送信したり、Data Platformを構築するチームと直接交流したりしてください。

OVHcloudサービスについてサポートが必要な場合は、ヘルプセンターでリクエストを作成してください。

ユーザーコミュニティに参加してください。