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

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

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

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

# 前提環境

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

# アカウントAの操作

## アカウントAの状況

### Athenaでクエリできている

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

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

<img width="1229" alt="スクリーンショット 0002-07-31 11.59.12.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/5692cda0-3571-efda-ff40-837762f4bebd.png">

### Glueでテーブル確認

<img width="1244" alt="スクリーンショット 0002-07-31 12.03.05.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/c6a57a81-241d-370e-8c1c-67506122d464.png">

### LakeFormationで権限管理されている

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

<img width="1250" alt="スクリーンショット 0002-07-31 12.04.58.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/e57029a7-6ded-5c5d-3de1-f53347b0f2f9.png">

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

<img width="1251" alt="スクリーンショット 0002-07-31 12.07.38.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/8c8d199f-6267-be41-75eb-53d65ffb10c4.png">

## 共有する

### IAMAllowedPrincipalsの許可削除

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

![スクリーンショット 0002-07-31 12.10.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/03f411fa-1d40-549f-15f0-69d5c96f1cb2.png)

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

<img width="687" alt="スクリーンショット 0002-07-31 12.14.41.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/50222e2b-ada8-a4e3-5859-4d2f7c7b2be9.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/e316dc74-4814-c6c4-8306-4dde6b13e189.png)

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

![スクリーンショット 0002-07-31 12.15.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/b681b6d9-08ab-a035-d4b0-4422b8a795ff.png)

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

![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f32373933322f39303434346366382d656233342d376130352d663938312d6138376462333737306465382e706e67.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/d3de7508-6e87-7d09-5fb1-f7037cdb6757.png)

# アカウントBの操作

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

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

![スクリーンショット 0002-07-31 12.17.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/73fc7202-ec38-c5c1-edf1-b3003bf7c618.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/6dba732b-4cfb-fe41-c00c-b77b64afd2fe.png)

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

![スクリーンショット 0002-07-31 16.56.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/c2fc6f71-a6b4-ddd2-637b-87ced0269b49.png)

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

![スクリーンショット 0002-07-31 16.57.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/a04ccf9f-7e40-7788-35ef-3116e8063767.png)

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

<img width="1168" alt="スクリーンショット 0002-07-31 16.59.28.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/27932/178af0f8-740f-23f1-1b86-d13edca16ab5.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