🦁

OpenMetadataのロールとポリシーについて

2024/05/25に公開

今回はOpenMetadata関連のひさしぶりの記事になります。
ここ最近仕事が忙しすぎて、趣味のツール弄りが全然できてないです〜。
今回はOpenMetadataのロールとポリシーについてです。

OpenMetadataのロールとポリシーガイド

まずOpenMetadataのチームとユーザそれに係る権限についての公式キュメントを確認します。

ポリシー

ポリシーを構成する要素

ポリシーはOpenMetadata内のアセットに対する承認の構成要素の位置づけです。
ポリシーを構成する要素としては次のものがあります。

構成要素名 説明
Rule Name ルールを定義する一意の名前
Description ルールの説明
Resources このルールが適用されるリソースのリスト。
管理者は、テーブルやすべてなどの特定のリソースを選択して、すべてのリソースに適用できます。
Operations このルールが適用される操作のリスト。
管理者は、EditOwner や All などの特定の操作を選択して、すべての操作に適用できます。
Effect true または false を評価するポリシー関数を使用して記述された式。
Condition 操作を拒否または許可します。

Condition

OpenMetadata は、管理者がルール作成時に選択できるSpELベースの条件を提供します。
条件の例をいくつか示します。

Condition 説明
noOwner() アクセスされているリソースに所有者がいない場合は true を返します。
isOwner() リソースにアクセスしているユーザーがリソースの所有者である場合は true を返します。
matchAllTags(tagFqn, [tagFqn…]) リソースにタグ リストのすべてのタグがある場合は true を返します。
matchAnyTag(tagFqn, [tagFqn…]) リソースにタグ リストのいずれかのタグがある場合は true を返します。
matchTeam() ユーザーがリソースを所有するチームに属している場合は true を返します。

条件について
条件は、特定の属性についてテーブル/トピック/ダッシュボードなどのデータアセットを評価するために使用されます。
AND (&&) や OR (||) などの論理演算子を使用して条件を組み合わせることもできます。
たとえば、次の組み合わせ条件:
noOwner() && matchAllTags('PersonalData.Personal', 'Tier.Tier1', 'Business Glossary.Clothing')
は、データ アセット (テーブル、トピックなど) に所有者が割り当てられておらず、指定されたすべてのタグに同時に一致する場合に true の結果を生成します。
これらの動的な条件により、管理者はアクセス制御を指示する際に、データアセットとその属性を総合的に考慮したルールを作成できるようになります。

デフォルトのポリシーとルール

OpenMetadataにはOrganization(組織)と呼ばれる全てのチームを管理する存在がいます。
OpenMetadataのユーザを作成した際に、そのユーザがチームに所属していない場合は、Organizatgionに所属します。
またOrganizationに適用されているロールがそのユーザに継承されます。※継承については後述します。
そのため、Organizationのポリシーはデフォルトポリシーとして動作します。
Organizationのポリシーは次の2つが設定されています。

OrganizationPolicy-NoOwner-Rule

目的:このルールにより、ユーザーは所有者のいないリソースに所有権を割り当てることができます。
例:ユーザーが fact_table にアクセスし、所有者がいないことがわかった場合、所有権フィールドを変更して新しい所有者を設定できます。ただし、すでに所有者が割り当てられている dim_address などのテーブルの場合、所有権を変更しようとすると制限されます。

OrganizationPolicy-Owner-Rule

目的:このルールは、データ資産の所有権に基づいて権限を付与します。
詳細:テーブルを個人的に所有しているユーザー、またはそのテーブルを所有するチームの一員であるユーザーがログインすると、広範な権限が付与されます。そのデータ アセットのすべてのプロパティを変更し、そのデータ アセットに関する完全な情報にアクセスできます。
このようなデフォルト ルールを設定することで、組織は所有権のステータスとユーザー ロールに基づいてアクセス制御を明確にすることができます。

ロール

ポリシーは承認を強制するメカニズムとして機能しますが、ロールは同じ目的のためにより構造化された階層を提供します。
各ロールは、ユーザーの機能または職務記述書と密接に連携しています。
ロールには、ユーザーの特定の機能またはジョブをカプセル化する複数のポリシーをバンドルできるという利点があります。
たとえば、「データ コンシューマー」ロールには「データ コンシューマー ポリシー」が含まれます。
このロールを割り当てられた個人またはチームは、関連するポリシーに概説されている規定に自動的に従うことになります。

さらに、ロールは組織階層内の個々のユーザーまたはチームに割り当てることができます。
ロールがチームに割り当てられると、そのチームのすべてのメンバーがそのロールの権限を継承します。
この設計は意図的なものであり、管理者のロール割り当てプロセスを簡素化することを目的としています。

継承の構成要素

OpenMetadataにはポリシーを継承させることができます。
継承には構造があり、以下の図のように頂点をOrganizationとして、次いでDivision、Department、Teamの順で各セクションのポリシーを継承します。
これによって、柔軟なポリシー設計が可能となります。

チーム構造内に配置されたユーザーは、本質的にそのポリシーを採用します。
たとえば、組織の頂点で「Organization-NoOwner-Policy」が制定された場合、その内部メンバー全員がこのポリシーとその中のルールによって管理されます。

同様に、「Division1」に「Division Policy」などのポリシーが指定されている場合、「Department」、「Team1」、「Team2」などのすべてのメンバー、またはこれらのグループ内の個々のユーザーがそのポリシーの対象となります。
ただし、「Team1」に対して明示的にポリシーを策定した場合、「Team1」のメンバーのみが影響を受けます。

デザインの背後にある哲学
このアーキテクチャは、組織レベルで広範かつ包括的なルールを確立することを目的としており、本質的にはより緩やかなものになる可能性があります。
階層を下るにつれて、チームはより厳格でカスタマイズされたポリシーを策定できます。
たとえば、ポリシーでは「チーム 1 以外のすべてのユーザーのアクセスを拒否する」と規定できます。
これにより、トップレベルでの柔軟性と草の根レベルでの精度が融合されます。

まとめ

OpenMetadataのロールとポリシーについて、多少は理解が進んだと思います。
OpenMetadataを企業に導入する際に権限系のガバナンスに対して、どのように設計すれば良いかという悩みの種があると思います。
まずは、OpenMetadataのロールとポリシーの設計思想に基づいて、Organizationで組織全体に対するポリシーを策定し、階層を降りる毎により細かなアクセス制御を行う運用を始めてみてはいかがでしょうか。

また、OpenMetadata公式ドキュメントでユースケースとして。ロールとポリシーの作成例が紹介されているのでご参考ください。
https://docs.open-metadata.org/v1.3.x/how-to-guides/admin-guide/roles-policies/use-cases

TIPS

ユーザ作成時にTeamとRoleを設定しない場合の挙動

OpenMetadataのユーザを作成する際に、ユーザが所属するTeamとユーザの権限を割り当てるRoleを設定できますが、設定しなかった場合どうなるのか確認してみます。

検証内容

まずはOpenMetadataを立ち上げた直後の状態でユーザを作成してみます。
作成条件としては、以下のとおりです。

設定項目 設定値
Email user001"@"kyamisama.com
Display Name user001
Description user001
password *********
Teams 設定なし
Roles 設定なし
Admin チェックなし

以下のとおり、user001を作成します。

上記条件で作成すると、TeamにはOrganizationに所属し、Roleは設定なし、ただし、Inherited Rolesに「Data Consumer」を設定されています。

Inherited Rolesとは継承ロールであり、ユーザーは、所属するチームに適用されるロールを継承します。

今回はOrganizationチームに所属しており、そのチームに適用されている「Data Consumer」ロールを継承しています。
ユーザ自身にロールは設定されていませんが、「Data Consumer」ロールが適用されています。
「Data Consumer」ロールは以下のようなポリシーを持ちます。

「Data Consumer」ロールは、全てのリソースに対して、「EditDescription, EditTags, ViewAll」の許可権限を持ちます。
そのため、取り込んだテーブル情報など参照することができます。
またテーブルのTAGの設定やディスクリプションの設定も可能でした。

ただし、Settings項目の「Ingestion、Notifications、OpenMetadata、Custom Attribute」の項目は表示されませんでした。

Settings項目の「Ingestion、Notifications、OpenMetadata、Custom Attribute」の項目を表示させたい場合は、ユーザにAdminロールを割り当てる必要があります。
たとえ全てのリソースに対して許可するポリシーを作成し、割り当ててもダメでした。
また、Adminロールを付与したユーザはSettingsのUsers項目から消え、Admins項目に移動されます。
そして、AdminロールはRoles項目に表示されないシステムで削除不可なロールのようです。

権限継承の動作

1つのチームに複数のユーザを所属させ、チームに適用した権限がチームに所属するユーザに適用されるのか確認してみます。

検証内容

チームを作成します。

チームにuser001とuser002を所属させます。両ユーザへのRoleは設定していません。

ただし、TeamAに所属させても、継承ロールは外れませんでした。

TeamAにはテーブル情報へのアクセスを拒否するポリシーを作成し、適用しました。

user001とuser002でテーブルへのアクセスが拒否された動きとなりました。

その他メモ

Discussion