ロールと条件#

#目的

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）：リソースのパスに条件を適用します。

• ポリシータグに対する条件（Advanced Data Access Control）
  • ポリシータグ値（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. データセット、テーブル、属性のすべてのレベルでポリシータグを強制します（関連するサービス名は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で特定のデータ値へのアクセスを制限するには、filterパラメータをAPI関連の権限に使用する必要があります。

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

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

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

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

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

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

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

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

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

{
  "bucket_name": "mybucket" 
}

#さらに詳しく

当社のソリューションのトレーニングや技術的なサポートが必要な場合は、営業担当者にお問い合わせください。または、Professional Servicesページをご覧になり、見積もりをご依頼いただき、当社の専門家がプロジェクトを分析してください。

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

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

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