LoginSignup
4
3

More than 3 years have passed since last update.

Lake Formation の使い方的な③(クロスアカウントアクセス)

Last updated at Posted at 2020-07-31

クロスアカウントアクセスとは

ログ収集AWSアカウント(データレイクAWSアカウント)のデータカタログを、別のAWSアカウントからアクセスして利用する。

S3上の実データもGlueデータカタログのテーブル情報などのメタデータもログ収集アカウントにある状態で、別のAWSアカウントからリソースリンク(シンボリックリンクみたいな定義)を介して権限制御しつつアクセスできる。
例えばログ収集AWSアカウントのGlueテーブルを、別のAWSアカウントのAthenaで使いクエリ実行する。

前提環境

  • AWSアカウントA:ログ収集用アカウント
  • AWSアカウントB:それ以外の自社サービスで使うアカウント

アカウントAの操作

アカウントAの状況

Athenaでクエリできている

S3にデータがあり、Glueでデータベースやテーブルを作成し、以下のようにAthenaでクエリができる状態

データベース名:default
テーブル名:in0

スクリーンショット 0002-07-31 11.59.12.png

Glueでテーブル確認

スクリーンショット 0002-07-31 12.03.05.png

LakeFormationで権限管理されている

DataLakeLocationに、データがあるS3パスが登録されている
この登録したS3パスに対してLakeFormationはアクセス許可を行える

スクリーンショット 0002-07-31 12.04.58.png

DataLocationsでロールにS3パスへのアクセス許可を与えている
Glueクローラがテーブル作成するために、Glueクローラが使うロールにアクセス許可を与えている

スクリーンショット 0002-07-31 12.07.38.png

共有する

IAMAllowedPrincipalsの許可削除

IAMAllowedPrincipalsに対しての許可があると今回の共有ができないので、これらを削除します。
このプリンシパルは従来のIAMのみのアクセス制御との後方互換のためにあるので実際やる時はご注意ください。
ここでは、IAMAllowedPrincipalsが含まれた許可が2つあります。defaultデータベースへの許可とin0テーブルへの許可です。それらを削除(Revoke)します。

スクリーンショット 0002-07-31 12.10.28.png

データベース側に「Use only IAM access control for new tables in this database」(このデータベースの新しいテーブルにIAMAllowPrincipalsを付ける)の設定があるか確認します。あればチェックを外しておきます
今回はdefaultという名前のデータベース

スクリーンショット 0002-07-31 12.14.41.png

アカウントBに共有する

DataPermissionsで[Grant]をクリックする。
"External account"にチェックを入れ、AWS account IDでアカウントBのIDを選択する。
※同じAWS Organizationに属するアカウントだとリストに表示されます。そうでない場合はRAM(AWS ResourceAccessManager)で共有する必要があります。
データベースは共有したいデータベースのdefault、テーブルは全てとしました。Permissionもテストなのでとりあえず全部チェック入れます。

スクリーンショット 0002-07-31 15.42.37.png

Permissionが作成されるとこんな感じです。
プリンシパルがAWSアカウントBで、アカウントBがアカウントAがオーナーのテーブルにアクセスする許可を与えています。

スクリーンショット 0002-07-31 12.15.28.png

(補足)今回スイッチロールして各AWSアカウントにログインしています。IAMAllowedPrincipalsを削除したので、アカウントAで行っていたAthenaでのクエリは失敗します。引き続きAthenaでクエリする必要があれば、スイッチロールに使っているロールに引き続きAthenaクエリできるように許可付与します。

68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f32373933322f39303434346366382d656233342d376130352d663938312d6138376462333737306465382e706e67.png

アカウントBの操作

データベースやテーブルを確認

共有されたアカウントAのデータベースやテーブルが確認できる。

スクリーンショット 0002-07-31 12.17.23.png

Resource Linkの作成

Resource Linkというものを作ります。元のデータ/テーブルを指し示すシンボリックリンクみたいなものでしょうか?
作成すると普通にテーブルのように見えます。テーブルの[Create]をクリックし、以下の値を入力し[Create]をクリックします。

  • Resource linkにチェック
  • Resource link name:share-in0 (なんでもいい)
  • Database:lf01 (Resource linkを保存するアカウントBのデータベース)
  • Shared table:in0 (アカウントAの共有したテーブルin0)

スクリーンショット 0002-07-31 16.06.29.png

作成されたResource Linkです。share-in0という名前です。わかりやすく"share-in0"という名前のフォントが少しイタリックっぽくなっています。

スクリーンショット 0002-07-31 16.56.14.png

View Dataしてみます。これはAthenaでのクエリ実行です。

スクリーンショット 0002-07-31 16.57.58.png

アカウントBからAthenaでResource Linkを使い、アカウントAのデータをクエリできました。

スクリーンショット 0002-07-31 16.59.28.png

ログ

CloudTrailのログも指定したアカウントに集約できそうです。

レイクフォーメーションは、データレイク内のデータへのすべてのクロスアカウントアクセスの集中監査証跡を提供します。受信者のAWSアカウントが共有テーブルのデータにアクセスすると、レイクフォーメーションはCloudTrailイベントを所有アカウントのCloudTrailログにコピーします。コピーされたイベントには、Amazon AthenaやAmazon Redshift Spectrumなどの統合サービスによるデータに対するクエリ、およびAWS Glueジョブによるデータアクセスが含まれます

こちらも是非

公式ドキュメント(クロスアカウントアクセス)
https://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/access-control-cross-account.html

公式ドキュメント(AWSアカウント間でデータカタログなどの共有)
https://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/sharing-catalog-resources.html

公式ドキュメント(リソースリンクの作成)
https://docs.aws.amazon.com/ja_jp/lake-formation/latest/dg/creating-resource-links.html

Lake Formationの使い方まとめ
https://qiita.com/pioho07/items/76554a7ac4252858b450

Glueの使い方まとめ
https://qiita.com/pioho07/items/32f76a16cbf49f9f712f

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
3