[小ネタ]Amazon DataZoneサービスのアクセス許可とプロジェクトメンバーのIAMロールについて

どーも、データアナリティクス事業本部コンサルティングチームのsutoです。

メタデータのアクセスやセキュリティを細かく設定しながらデータカタログを実現できるAmazon DataZoneですが、バックグラウンドでどのようなIAMポリシーやIAMロールが使われているか調べてみました。

本記事をご覧になる前に

• 本記事は、Amazon DataZoneのパブリックプレビュー段階で検証した内容です。GA時には本記事で記載した検証結果や前提条件が異なる可能性がありますのでご注意ください。

Amazon DataZoneを操作するための管理ポリシー

AWSコンソールからAmazon DataZoneを利用するために自身のIAMユーザーやIAMロールに必要なアクセス許可があります。

DataZoneサービスの機能を自由に触るには基本的にAmazonDataZonePreviewConsoleFullAccessをアタッチしておけば良さそうですが、以下に4つ管理ポリシーが存在します。

AmazonDataZonePreviewConsoleFullAccess

• AWS マネジメントコンソール経由で Amazon DataZone のプレビューリリースへのフルアクセスを許可（datazonecontrolフルアクセス）
• KMSエイリアスリスト、キーの参照を許可
• Redshiftクラスターへの読み取りアクセスの許可
• Glueデータベース、テーブルへの読み取りおよびGlue接続の作成を許可
• サブネットへの読み取りアクセスの許可
• IAMロールのリストを参照でき、プリンシパルがロールを渡すことも許可
  • PassRole可能なロールには AmazonDataZoneServiceRole* 、 AmazonDataZoneBootstrapRole* などユーザーがDataZoneポータルでプロジェクト作成をした際に、裏で作成されるIAMロールなどの作成を行うために必要なポリシーが含まれているロールとなります
• なお、以下のようにAmazonDataZonePreviewConsoleFullAccessだけでは権限が足りない場合があります
  • 独自のAWS KMSキーでAmazon DataZoneルートドメインを作成する場合、ルートドメインの作成を成功させるためにkms:CreateGrant、そのキーでlistDataSourcesやcreateDataSourceなどのAmazon DataZone APIを呼び出すためにkms:GenerateDataKey、kms:Decryptの権限が必要です
  • データソースの追加などでAmazon DataZone コンソール内でロールの作成機能を使用する場合は、管理者権限を持っているか、IAM ロールとポリシーを作成するために必要な IAM アクセス許可（iam:CreateRole、iam:CreatePolicy、iam:AttachRolePolicyなど）を持っている必要があります。

AmazonDataZonePortalFullAccessPolicy

• datazonecontrolフルアクセスのみを持つポリシー

AmazonDataZoneProjectDeploymentPermissionsBoundary

• IAMのアクセス許可の境界にアタッチするポリシー
• CDKブートストラップ時にこのポリシーが付与されているIAMロールを作成しており、これによって作成されたIAMロールを使っていることで後続のプロジェクト作成のスタックを完了することができる
  • ※プロジェクト作成を初めて作成する際、裏ではAWS CDKがブートスラップ実行およびプロジェクト作成のためのスタックデプロイメントを行っています
  • プロジェクトマネージャーおよびプロジェクトユーザーロールを作成するために使用され、この権限境界により、プロジェクトに必要なリソースおよびアクションへのアクセスのみを許可されるように制限されます

AmazonDataZoneProjectRolePermissionsBoundary

• IAMのアクセス許可の境界にアタッチするポリシー
• プロジェクト作成と同時に作成されるプロジェクト用IAMロールのアクセス許可の境界に対して付与される
  • AWS Glue、Amazon S3、AWS Lake Formation、Amazon Redshift、Amazon Athena などのサービスに対する Amazon DataZone の読み取りおよび書き込みアクセスを許可します
  • この権限境界により、プロジェクトのデプロイメントに必要なリソースおよびアクションへのアクセスのみを許可されるように制限されます

参考

プロジェクトメンバー追加・削除とユーザー権限ごとのIAMロール

作成したプロジェクトにはメンバーの追加・削除を行うことで、データのパブリッシュ・サブスクライブ操作やパブリッシュジョブ設定などのリソース閲覧と管理ができるユーザーを制御することができます。

メンバー追加は、「プロジェクトのOwner権限を持つユーザーによる追加操作」または「ユーザーによるプロジェクトJoinのリクエスト→Ownerによる承認」の２通りで実施できます

• Ownerによる追加の場合

• ユーザーから追加リクエストする場合

ユーザーに付与する権限は以下の３種類となり、各権限に紐づいているIAMロールがあります

• Viewer : プロジェクト内の設定データやパブリッシュ、サブスクライブされたデータアセットを閲覧できる読み取り専用ユーザー
  • 基本的に設定の追加や削除のような操作ができない
  • パブリッシュジョブの表示や実行はできないため、データパブリッシュはできない
  • パブリッシュ済みのデータアセットを他のプロジェクトへサブスクライブは可能(ただしサブスクライブ先のプロジェクトでContributor以上の権限を持っていること)
  • datazone-usr-v-proj-＜プロジェクトごとのハッシュ値＞ という命名のIAMロールが紐づいている
• Contributor : プロジェクトのリソース編集の権限をもっている
  • データパブリッシュが可能で、データアセット追加の操作をする場合はこの権限が必要
  • プロジェクトメンバーの追加／削除などのユーザー管理はできない
  • プロジェクト自体の削除を行える権限はない
  • datazone-usr-c-proj-＜プロジェクトごとのハッシュ値＞ という命名のIAMロールが紐づいている
• Owner : プロジェクト管理者の権限をもっている
  • プロジェクトに対してすべての操作が可能のため、ViewerやContributorではできない操作も可能
  • datazone-usr-o-proj-＜プロジェクトごとのハッシュ値＞ という命名のIAMロールが紐づいている

上記3つのロールは、プロジェクト用のGlueデータベース、S3バケット、Athenaワークグループなどと同様にプロジェクト作成と同時に作られます。

よってロールのカスタムポリシーには同時作成されたGlue、Athenaワークグループのみが許可されたリソースをなっています。

そのためデータソース追加などでプロジェクト用Glueデータベース以外の既存Glueデータベースを追加し、データをパブリッシュすると、データアセットとしては問題なく登録できるが、以下画面の「AthenaのQuery data」でクエリしようとしても既存Glueデータベースは参照できなかった。（DatazoneのIAMロールでスイッチロールしてAthenaの画面へ遷移する仕様のため）

データソースに追加した既存のGlueデータベースを「AthenaのQuery data」からクエリ実行する場合、 datazone-usr-〜 のIAMロールのポリシーを編集して既存のGlueデータベースの許可を追加する必要があります