Change access control from Amazon Lake Formation to IAM - Amazon Lake Formation
PrerequisitesUsing Amazon CLI
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Change access control from Amazon Lake Formation to IAM

This section describes the workflow to change access control from Amazon Lake Formation grants to IAM privileges for Amazon S3 Tables integrated with the Amazon Glue Data Catalog.

Important

Changing access control from Amazon Lake Formation grants to IAM will revoke all existing Lake Formation-based access to your S3 Tables resources. After completing Step 2, users and roles that previously accessed data through Lake Formation grants will immediately lose access. You must grant IAM access in Step 1 before updating the catalog. Plan this migration during a maintenance window and coordinate with your data team.

Important

Fine-grained access controls, such as column-level access and data cell filters, with Data Catalog objects are available when using Amazon Lake Formation only. Before proceeding to migrate access controls from Amazon Lake Formation to IAM, audit your existing Lake Formation grants using aws lakeformation list-permissions and determine whether equivalent IAM policies can provide the access your users need. Any principal that relied on fine-grained Lake Formation grants will require full table-level IAM access after migrating access control.

Prerequisites

Before you begin, ensure the following:

  • You have identified all Lake Formation grants currently in effect for the resources being migrated. Run aws lakeformation list-permissions --resource-type TABLE to review them.

  • You have prepared IAM policies that provide equivalent access for all affected principals.

  • The IAM role registered with Lake Formation still has lakeformation:GetDataAccess (needed during the hybrid transition period).

Using Amazon CLI

  1. Step 1: Grant IAM permissions to principals

    Attach IAM policies to the users or roles that need access. The policy must include both Amazon Glue metadata permissions and S3 Tables data permissions.

    Note

    The following example policy only provides read access.

    aws iam put-user-policy \
  --user-name GlueIAMAccessUser \
  --policy-name S3TablesIAMAccessPolicy \
  --policy-document '{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "GlueMetadataAccess",
            "Effect": "Allow",
            "Action": [
                "glue:GetCatalog",
                "glue:GetDatabase",
                "glue:GetTable"
            ],
            "Resource": [
                "arn:aws:glue:us-east-1:AWSAccountID:catalog/s3tablescatalog",
                "arn:aws:glue:us-east-1:AWSAccountID:database/s3tablescatalog/table-bucket-name/namespace",
                "arn:aws:glue:us-east-1:AWSAccountID:table/s3tablescatalog/table-bucket-name/namespace/*"
            ]
        },
        {
            "Sid": "S3TablesDataAccess",
            "Effect": "Allow",
            "Action": [
                "s3tables:GetTableBucket",
                "s3tables:GetTable",
                "s3tables:GetTableMetadataLocation",
                "s3tables:GetTableData"
            ],
            "Resource": [
                "arn:aws:s3tables:us-east-1:AWSAccountID:bucket/table-bucket-name",
                "arn:aws:s3tables:us-east-1:AWSAccountID:bucket/table-bucket-name/table/*"
            ]
        }
    ]
  }'

    Verify that all affected users and roles can access the expected tables using their IAM credentials before proceeding.

  2. Step 2: Update the catalog to restore IAM default permissions

    Update the catalog so that CreateDatabaseDefaultPermissions and CreateTableDefaultPermissions grant ALL to IAM_ALLOWED_PRINCIPALS. Set OverwriteChildResourcePermissionsWithDefault to Accept so the change propagates to all existing child resources, not just newly created ones.

    aws glue update-catalog \
  --catalog-id "s3tablescatalog" \
  --catalog-input '{
    "FederatedCatalog": {
        "Identifier": "arn:aws:s3tables:us-east-1:AWSAccountID:bucket/*",
        "ConnectionName": "aws:s3tables"
    },
    "CreateDatabaseDefaultPermissions": [{
        "Principal": {"DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS"},
        "Permissions": ["ALL"]
    }],
    "CreateTableDefaultPermissions": [{
        "Principal": {"DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS"},
        "Permissions": ["ALL"]
    }],
    "OverwriteChildResourcePermissionsWithDefault": "Accept"
  }'

  3. Step 3: Deregister the resource from Lake Formation

    Once you have confirmed that all access is working through IAM policies and no principals depend on Lake Formation grants, you can deregister the resource from Lake Formation to complete the migration.

    aws lakeformation deregister-resource \
  --resource-arn "arn:aws:s3tables:us-east-1:AWSAccountID:bucket/*"
    Note

    After deregistering the resource, remove lakeformation:GetDataAccess from IAM principals that no longer need it.

No revoke-permissions step is required.