Zenn
💬

AWS Lake FormationでGlueクローラーの権限エラーを解決した話

に公開
AWS
Glue
Lake Formation
tech

AWS Lake FormationでGlueクローラーの権限エラーを解決した話

最近、AWS Lake FormationとGlueクローラーを組み合わせた環境で、なかなか厄介な権限エラーに遭遇しました。同じ問題に将来また遭遇した時のために、解決までの経緯とLake Formation特有の権限の依存関係について備忘録としてまとめておきます。

背景

データレイク基盤の構築プロジェクトで、S3に蓄積されたデータをGlueクローラーで自動的にカタログ化する仕組みを作っていました。セキュリティ要件により、Lake Formationを有効にしてデータアクセスを制御する必要がありました。

基本的な構成は以下の通りです：

  • S3バケットにCSVやParquetファイルを配置
  • Lake FormationでS3をData Locationとして管理
  • Glueクローラーで定期的にスキャンしてテーブル作成

遭遇した問題

設定完了後、いざクローラーを実行してみると以下のエラーが発生：

Access Denied
LakeFormation.permissions

最初はIAMの設定不備だと思い、Glueサービスロールの権限を何度も見直しました。S3への読み書き権限、Glueの基本権限、CloudWatchログ出力権限など、一般的に必要とされる権限は全て付与済みでした。

しかし、エラーは解消されず。Glueのドキュメントを調べても、Lake Formation特有の設定については詳しく触れられていない部分が多く、しばらく行き詰まっていました。

調査と試行錯誤

エラーメッセージに「LakeFormation.permissions」とあることから、Lake Formation側の設定に問題があることは推測できました。ただ、Lake Formationのコンソールは項目が多く、どこを確認すべきか最初はよく分からない状態でした。

AWS サポートの過去事例や海外のフォーラムを調べていくうちに、Lake Formationでは従来のIAMに加えて、Lake Formation独自の権限体系が存在し、これらが複雑に依存し合っていることが分かってきました。

Lake Formation権限の依存関係について

今回の問題を解決する上で最も重要だったのは、Data Location権限とCatalog権限の依存関係を正しく理解することでした。この関係を理解せずに設定を行うと、権限エラーが頻発します。

Lake Formation権限の種類と役割

Lake Formationには大きく分けて2つの権限体系があります：

1. Data permissions（データ権限）

  • Data Catalogリソース（データベース、テーブル）に対する権限
  • 例：CREATE_TABLE、SELECT、INSERT、DESCRIBE、ALTER、DROP

2. Data location permissions（データロケーション権限）

  • 特定のS3ロケーションを指すCatalogリソースを作成・変更する権限
  • 権限：DATA_LOCATION_ACCESS

重要な依存関係ルール

ルール1: テーブル作成時の必須条件
S3ロケーションを指すテーブルを作成する場合：

  • CREATE_TABLE権限だけでは不十分
  • そのS3ロケーションに対するDATA_LOCATION_ACCESS権限も必要
  • 両方が揃って初めてテーブル作成が可能

ルール2: データベースのlocation propertyによる暗黙的権限
データベースにlocation propertyが設定されている場合：

  • CREATE_TABLE権限があれば、そのロケーションまたは子ロケーションでのテーブル作成に対して暗黙的なdata location権限が付与される
  • ただし、他のロケーションでテーブルを作成する場合は明示的なDATA_LOCATION_ACCESS権限が必要

ルール3: 管理権限とリソース作成権限の分離

  • Catalog Creators権限がないと、データベースやテーブルの作成系操作が拒否される
  • これは他の権限とは独立した管理権限として機能する

ルール4: 権限適用の前提条件

  • S3ロケーションがLake Formationに登録されていないと、すべてのLake Formation権限が無効
  • 登録が権限設定の大前提となる

解決策

結果的に、以下の3つの設定を正しい順序で行うことで問題が解決しました。重要なのは、これらの設定が相互に依存していることです。

1. S3バケットのData Location登録とアクセス権限の付与

ステップ1: S3バケットをData Locationとして登録

  1. Lake Formationコンソールの「Administration」→「Data lake locations」を開く
  2. 「Register location」をクリック
  3. 対象のS3パス（例：s3://my-data-bucket/）を指定
  4. IAMロールを指定して登録完了

なぜ最初に必要か：
この登録により、S3バケットがLake Formationの管理下に入ります。これがすべてのLake Formation権限設定の前提条件となります。

ステップ2: GlueロールにData location権限を付与

  1. Lake Formationコンソールの「Permissions」→「Data locations」を開く
  2. 「Grant」をクリック
  3. 以下を設定：
    • IAM user and roles: GlueクローラーのIAMロール
    • Storage locations: 上記で登録したS3パス
    • 権限として「DATA_LOCATION_ACCESS」が自動的に付与される
  4. 「Grant」をクリックして権限付与完了

権限依存関係のポイント：

  • この権限は後述のCREATE_TABLE権限と密接に関連
  • CREATE_TABLE権限だけでは、S3ロケーションを指すテーブルは作成できない
  • DATA_LOCATION_ACCESS権限により、指定されたS3パス（およびその子パス）を指すCatalogリソースの作成が可能になる

2. Administrative roles and tasksでのCatalog Creators設定

Lake Formationの「Administrative roles and tasks」で、GlueクローラーのIAMロールを「Catalog Creators」に追加する必要がありました。

手順：

  1. Lake Formationコンソールの「Administrative roles and tasks」を開く
  2. 「Catalog Creators」セクションで「Add」をクリック
  3. GlueクローラーのIAMロールを選択して追加

なぜ必要か：
この設定により、クローラーがGlue Catalogにデータベースやテーブルを作成する管理権限が付与されます。Catalog Creatorsに登録されていない場合、他の権限があってもカタログへの作成系操作が拒否されます。

3. Data permissions（データベース・テーブル権限）の設定

Data LocationとCatalog Creatorsの設定に加えて、Glueクローラーが作成するデータベースやテーブルに対する適切な権限設定も必要でした。

手順：

  1. Lake Formationコンソールの「Permissions」→「Data permissions」を開く
  2. 「Grant」をクリック
  3. 以下を設定：
    • IAM user and roles: GlueクローラーのIAMロール
    • Databases: 対象データベース（または「All databases」）
    • Database permissions: 「CREATE_TABLE」を選択
    • Tables: 必要に応じて「All tables」を選択
    • Table permissions: 「SELECT」「INSERT」「DESCRIBE」を選択
  4. 「Grant」をクリックして権限付与完了

権限依存関係のポイント：

  • CREATE_TABLE権限は、前述のDATA_LOCATION_ACCESS権限と組み合わせて初めて機能
  • これらの権限により、クローラーは以下の操作が可能になる：
    • データベース内でのテーブル作成
    • 作成したテーブルのスキーマ設定
    • テーブルメタデータの更新

権限設定の正しい順序

権限設定には正しい順序があります：

  1. S3バケットをData Locationとして登録（前提条件）
  2. Data location権限を付与（CREATE_TABLEの前提）
  3. IAMロールをCatalog Creatorsに追加（管理権限）
  4. Data permissions（CREATE_TABLE等）を付与（実際の操作権限）

この順序を守らないと、途中でエラーが発生することがあります。

設定後の確認

すべての設定を行った後、クローラーを再実行したところ、無事にテーブルが作成されました。想定していたスキーマでパーティションも正しく認識され、Athenaからもクエリできることを確認しました。

学んだこと

今回の件で、Lake Formation環境での権限管理について理解が深まりました：

Lake Formationのアクセス制御は追加型
IAMの権限に加えて、Lake Formation独自の権限が必要になります。IAMで許可されていても、Lake Formation側で拒否されればアクセスできません。

権限の依存関係が複雑
特にData Location権限とCatalog権限の依存関係は理解が重要です。CREATE_TABLE権限だけでは不十分で、対象のS3ロケーションに対するDATA_LOCATION_ACCESS権限も必要になります。

Data Location登録の影響範囲
S3バケットをData Locationに登録すると、そのバケットのアクセス制御がLake Formationに移管されます。既存のアプリケーションがある場合は、影響範囲を事前に確認する必要があります。

エラーメッセージの読み解き
Lake Formation関連のエラーは比較的シンプルなメッセージしか出ないことが多いため、ログの文脈や設定状況から原因を推測するスキルが重要です。

暗黙的権限の存在
データベースのlocation propertyによる暗黙的なdata location権限など、明示的でない権限の仕組みも理解しておく必要があります。

IAM権限は基本的な前提
今回はIAMロールの基本権限（Glue、S3、lakeformation:GetDataAccessなど）は適切に設定済みでしたが、Lake Formation環境では必須の前提条件です。

今後の運用での注意点

本番環境への適用時は、以下の点にも注意が必要そうです：

  • 新しいIAMロールを追加する際の権限設定手順の標準化
  • データ追加時のパーティション設定
  • 他のAWSサービス（EMR、Redshift Spectrum等）との連携時の権限設定
  • 本番データでの権限テスト手順
  • 権限の依存関係を意識したトラブルシューティング手順の策定

まとめ

Lake FormationとGlueの組み合わせは強力な機能を提供しますが、権限設定の複雑さと依存関係が課題となることがあります。特にData Location権限とCatalog権限の複雑な依存関係を理解することが、問題解決の鍵となります。

今回の経験を通じて、段階的な検証とドキュメント化の重要性、そして権限間の依存関係を正しく理解することの重要性を改めて実感しました。

Discussion