Athena x IAM Identity Center の罠（2個目）

前回、Athena Workgroup を作る際のトラップについて書いた。
その後、この Workgroup を使うための EMR Studio を作成中に別のトラップを踏んだのでメモ。

やりたいこと

IAM Identity Center 経由で認証し、Athena で Lake Formation の認可を使う。

公式ドキュメントにある通り、IAM Identity Center による認証の場合 Athena コンソールからはアクセスできないので、EMR Studio を使う必要がある。また、前回書いた通り、IAM Identity Center を有効化した Athena Workgroup を使う必要がある。

前提条件

• IAM Identity Center を Entra ID 連携構成で設定済み。
• こちらの記事に従い、IAM Identity Center 連携用の Workgroup を作成し、IAM Identity Center ユーザーをアサイン済み。
• 適当なデータセットを用意し、同一アカウント内の Lake Formation で DB、テーブルを作成済み。なお、今回はシングルアカウント構成とする（複数アカウントの場合はリソースリンクなども考慮する必要がある）。
• 前述の IAM Identity Center ユーザーに対し、上記テーブルへの SELECT/DESCRIBE 権限を　Lake Formation から GRANT 済み。

データベース	テーブル
flightdata_db	flightdata

あとは EMR Studio を作って検索するのみ...だったのだが、まだ罠は終わりではなかった。

トラップ2-1: Workgroup が表示されない

まず、普通に作成した EMR Studio では、せっかく作った Workgroup が表示されない。

どうやら、EMR Studio 自体にも認証モードの設定がある模様。これが原因か？

トラップ2-2: 認証モードの設定が出てこない

IAM Identity Center を認証モードに設定して EMR Studio を作り直そうとしたのだが、どこにも設定が見当たらない。
これは割合すぐに原因が分かった。「インタラクティブモード」ではなく、「カスタム」を選ぶ必要があるようだ。

「カスタム」を選ぶと、ようやく認証の選択ができるようになった...が、またなんか出たぞ。

トラップ2-3: 画面が日本語(ry

もうだいたい想像が付く。画面の言語を英語に変更してリトライ。

できた。

EMR Studio のリンクを踏んでみたところ、次のエラー。
まだ何かあるのか。

トラップ2-4: IAM ロール x2 を自作要

EMR Studio を構成するには Studio サービスロールと Studio ユーザーロール を適切に構成する必要がある模様。
ここでは、サービスロールだけ作成して、ユーザーロールは（横着して）同じものを指定していたため、sts:SetContextが足りないと怒られた、ということらしい。

というわけで、改めてポリシー内容を精査の上ロールを作成。
サービスロールの方はマネコンで作成時に信頼ポリシーとポリシーのサンプルが生成されるのでそれを使うのが楽だが、Athena 権限が足りてないので要追加。

ポリシー（不足分）

		{
		    "Sid": "AllowAthenaActions",
		    "Effect": "Allow",
		    "Action": "athena:*",
		    "Resource": "*"
		}

ユーザーロールは公式ドキュメントをベースに自力で作成しなければならない。参考までに、サンプルはこちら。

信頼ポリシー

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

ポリシー

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "AllowAddingTagsOnSecretsWithEMRStudioPrefix",
			"Effect": "Allow",
			"Action": "secretsmanager:TagResource",
			"Resource": "arn:aws:secretsmanager:*:*:secret:emr-studio-*"
		},
		{
			"Sid": "AllowPassingServiceRoleForWorkspaceCreation",
			"Action": "iam:PassRole",
			"Resource": [
				"arn:aws:iam::*:role/<作成した EMR サービスロール>"
			],
			"Effect": "Allow"
		},
		{
		    "Sid": "AllowGlueAndLakeFormation",
			"Action": [
			    "glue:*",
			    "lakeformation:*",
                "athena:*"
			],
			"Resource": "*",
			"Effect": "Allow"
		}
	]
}

この辺は正直、他のサービスと同様ワンクリックで作れるようにしておいて欲しいのだが。。。

（※いずれのポリシーも、今回は EMR Studio を動作させることを優先して、広めの権限にしています。実際はもっと権限を絞った方がよいです。）

トラップ2-5: ユーザーのアサインが必要

まだエラーになる、と思ったらここが空だった。QuickSight などと同様、EMR Studio は IAM Identity Center アプリケーションとして作成されるので、そこの利用ユーザーとしてアサインしてやる必要があったのを忘れていた。

追加。

ちなみに、これを設定した時点で、IAM Identity Center のユーザープロパティ、アプリケーションのタブに EMR Studio が現れる。

結果

トラップを乗り越え続けた甲斐あって、Workgroup は無事表示されるようになり、それに伴って（Lake Formation で権限を与えた） DB とテーブルも表示された。

これでクエリー実行が完了すればミッションコンプリートだったのだが、最後の最後で問題発生。

バケットもプレフィックスは存在しており、現に Athena 側で使えている。念のためサービスロールやユーザーロールに AdministratorAccess を付与してもエラー変わらずなので、権限の問題でもなさそう。
ここまで数々のトラップを乗り越えてきたが、これはちょっと原因が分からない（判明したらアップデートします）。

[2024/8/5追記]
結果バケットに、S3 Access Grants なるものを設定する必要があり、これで突破できる模様です（同僚 S 氏の検証結果より）。自分はまだ試せてませんが、参考までにリンクを貼っておきます。

まとめ

思ったよりハードルが高いな、という印象。
EMR Studio 自体は Athena と同じインターフェイスで違和感ないのだが、とにかく手番（と罠）が多く、なかなか使わせて貰えないのがツライ。