IAM Identity CenterのユーザーをLake Formationで許可してAthenaでクエリする

やりたいこと

タイトルの通りです。
「ユーザー認証はOktaなどの外部IdP認証にして、Data Catalogへの認可はLake Formationで一元管理したい！」というユースケースなどで使われます。

2023年の12月の以下のアップデートで上記の構成が可能となりました。

ただし、これで利用できるのはAthenaコンソールではなく、Amazon EMR StudioからのAthena SQLインターフェースであることに注意してください。

信頼できる ID 伝達を使用する Athena ワークグループからのクエリは、IAM アイデンティティセンターが有効な EMR Studio の Athena SQL インターフェイスから実行する必要があります。

実施の流れ

基本的には、以下のAWS Big Data Blogを実施していけばできます。
BlogではOktaを使っていますが、私は東京リージョンのIAM Identity Centerのユーザーとグループを作成して実施して、Athenaでクエリできるところまで行けました。

Blogの手順を日本語に直したものを記載します。なお、先ほども言った通り、1のOktaのところはIAM Identity Centerでユーザーとグループを作成することで代替しています。

1. OktaとIAM Identity Centerを統合し、ユーザーとグループを同期する。

2. IAM Identity CenterとEMR Studioを統合する。

3. IAM Identity CenterからユーザーまたはグループをEMR Studioに割り当てる。

4. IAM Identity CenterでLake Formationをセットアップする。

5. 伝搬されたコーポレートIDに対して、Lake Formationを使用して細かいロールベースのアクセス権を設定する。

6. Athenaでワークグループを設定し、アクセスを制御する。

7. Amazon S3リソース(バケット、プレフィックス、オブジェクトなど)への細かいアクセスを許可するために、Amazon S3 Access Grantsを設定する。

8. AWS アクセスポータルを介してIAM Identity CenterでEMR Studioにアクセスする。

9. EMR StudioのAthena SQLエディターでクエリを実行する。

10. ワークフォースIDの終了から終了までの監査証跡を確認する。

最終的には、以下のようにAWS Identity Centerからログインして、EMR Studioに入り、Athenaでクエリを実行することが出来ました。ただし、Blogに書いてあることだけだとうまくいかないので、独自に実施した点を次の「注意点」に記載します。

注意点

Amazon S3 Access GrantsでAthenaクエリ結果バケットへの許可を付与する

手順の7で実施しているのがこれです。
Amazon S3 Access Grantsとは、AWS Identity Centerのユーザーやグループに対して、S3バケットへの権限を付与できるサービスです。今回、Athenaクエリ結果バケットへAWS Identity Centerのグループへの許可を与えたいため、これを使います。
これをやらないと、Athenaでクエリしても「そんなクエリ結果バケットはない」というエラーが出てしまいます。

Amazon S3 Access GrantsでのLocationで指定するIAMロールは新規作成したら信頼ポリシーを変える

同じくAmazon S3 Access Grantsです。Blogではここの設定を動画で説明していて、Locationで指定するロールは前もって作成しているためどんなロールを作成すれば良いかよくわかりません。
ただ、現在は以下のようにCreate new roleがあるのでこれを選択してみましたが、この新規に作成されたロールのままだとうまくいきません。

原因は信頼ポリシーです。自動で作成されたIAMロールの信頼ポリシーをEditしてみると、以下のようにエラーが出てしまいます。

そこで、信頼ポリシーを以下の記事の通りに修正しました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "access-grants.s3.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:SetSourceIdentity",
                "sts:SetContext"
            ]
        }
    ]
}

Amazon S3 Access GrantsでのGrant scopeはサブプレフィックス「*」を指定する

さらに同じくAmazon S3 Access Grantsです。ここは、動画と全く同じ操作をしてもうまく動きません。
Grant scopeの指定の仕方に問題があります。
動画では、以下のようにサブプレフィックスには何も入力せず、The grant scope is an objectにチェックを入れていました。この設定だと、Athenaでクエリ実行してエラーが出ます。

以下のように、サブプレフィックスに「*」を指定し、The grant scope is an objectにはチェックなしが正解です。こうすると動きます。

Lake FormationのData lake locationに付与するIAMロールは自分で作成する

次はLake Formationです。Data Catalogの元データが格納されているS3の場所をData lake locationとして登録する必要がありますが、その時にIAMロールも指定します。
普通ならLake Formationが用意してくれるサービスリンクロールを使うのですが、これを使うとエラーが起きます。

Service-linked rolesはSetContext auditingをサポートしていないとのこと。であれば、自分で作るしかありません。
作成したロールに付与する権限は、おそらくサービスリンクロールと同じで大丈夫なはずです（私はテスト用にAdministratorAccessを付与しました）。重要なのは、またもや信頼ポリシーです。以下のように信頼ポリシーを設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "lakeformation.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:SetContext"
            ]
        }
    ]
}

サービスロールの信頼ポリシーは"sts:AssumeRole"しか許可していなかったので、最初はそれをそのまま使ったのですが、"sts:SetContext"も許可してくださいというエラーが出てしまいました。そのため、"sts:SetContext"を追加しています。

以下の画像の、上が自作のロール、下がサービスリンクロールです。これでクエリ実行が成功しました（Hybrid access modeは、デフォでテーブル作成ができるようになるモードなのであまり関係ないです）。

AWS Identity Centerのポータル画面はシークレットウィンドウで開きなおす

これは全体を通してなのですが、Adminとして色々操作するロールと同じブラウザ上（別タブ）でAWS Identity Centerポータルを開いてユーザー操作していたら、何やら変なエラーが多発しました。セッションか何かが残ってしまっているのかわかりませんが、それを回避するためにChromeのシークレットウィンドウやFirefoxのプライベートウインドウでIdentity Centerユーザーはログインするようにしたら直りました。

おわりに

かなり道なき道を行った感じがありますが、何とかAthenaでクエリ実行ができました。
ただ、IAMポリシー書きたくないからLake Formation使ったのに、この検証でいくつのIAMロールを作成したのかと思うと、ちょっと複雑な気分です。特にLake Formationのサービスリンクロールはどこにもドキュメントに記載がなかったのでこれで合っているのかは少し不安です。
色々試行錯誤しましたが、最終的にクエリは実行できてよかったです。

参考