# Changing access controls for S3 Tables integration
After you have integrated Amazon S3 Tables with the AWS Glue Data Catalog, you can change how access to your catalog resources is controlled. This section how to change access control depending on your current and desired access control model. Enabling Lake Formation allows you to use fine-grained permissions such as column-level and row-level security through Lake Formation grants, and allows Lake Formation to vend temporary credentials on behalf of principals through a registered role. Changing access control from AWS Lake Formation to IAM returns access control to standard IAM policies, which may be appropriate if your workloads do not require fine-grained access and you prefer to manage permissions entirely through IAM. Both migration paths involve updating the Data Catalog defaults, adjusting resource registrations with Lake Formation, and coordinating permission grants to avoid access disruptions during the transition.
**Topics**
+ [Enable Lake Formation with S3 Tables integration with Data Catalog](change-access-iam-to-lf.md)
+ [Change access control from AWS Lake Formation to IAM](change-access-lf-to-iam.md)
# Enable Lake Formation with S3 Tables integration with Data Catalog
This section describes the workflow to migrate access control from IAM privileges to IAM with AWS Lake Formation grants for Amazon S3 Tables integrated with the AWS Glue Data Catalog.
**Important**
Enabling AWS Lake Formation access control will revoke all existing IAM-based access to your S3 Tables resources. After completing Step 1, users and roles that previously accessed data through IAM permissions will immediately lose access. You must grant Lake Formation permissions in Step 2 before users can query data again. Plan this migration during a maintenance window and coordinate with your data team.
## Prerequisites
For read/write access to S3 Tables, in addition to Lake Formation permissions, principals also need the `lakeformation:GetDataAccess` IAM permission. With this permission, Lake Formation grants the request for temporary credentials to access the data.
## Using AWS CLI
1. **Step 1: Register bucket with Lake Formation using IAM role**
Register the S3 Tables resource with Lake Formation.
**Note**
If you have an existing role, ensure hybrid access is false.
```
aws lakeformation register-resource \
--resource-arn "arn:aws:s3tables:us-east-1:AWSAccountID:bucket/*" \
--role-arn "arn:aws:iam::AWSAccountID:role/service-role/LFAccessRole" \
--with-federation
```
1. **Step 2: Update AWS Glue catalog to enable Lake Formation access control**
Update the catalog with empty `CreateDatabaseDefaultPermissions` and `CreateTableDefaultPermissions` (set to `[]`) and set `OverwriteChildResourcePermissionsWithDefault` to `Accept`. This removes IAM-based access from all existing child resources and allows the catalog and its objects to be managed using Lake Formation grants.
```
aws glue update-catalog \
--catalog-id "s3tablescatalog" \
--catalog-input '{
"FederatedCatalog": {
"Identifier": "arn:aws:s3tables:us-east-1:AWSAccountID:bucket/*",
"ConnectionName": "aws:s3tables"
},
"CreateDatabaseDefaultPermissions": [],
"CreateTableDefaultPermissions": [],
"OverwriteChildResourcePermissionsWithDefault": "Accept",
"AllowFullTableExternalDataAccess": "True"
}'
```
1. **Step 3: Grant Lake Formation permissions to your data team**
Grant Lake Formation permissions to the principals (roles, users, or groups) that need access. For example, to grant full-table read access to a role:
```
aws lakeformation grant-permissions \
--principal DataLakePrincipalIdentifier=arn:aws:iam::AWSAccountID:role/DataTeamRole \
--resource '{
"Table": {
"CatalogId": "AWSAccountID",
"DatabaseName": "s3tablescatalog/table-bucket-name/namespace",
"TableWildcard": {}
}
}' \
--permissions "SELECT" "DESCRIBE"
```
Repeat for each principal and resource combination as needed.
# Change access control from AWS Lake Formation to IAM
This section describes the workflow to change access control from AWS Lake Formation grants to IAM privileges for Amazon S3 Tables integrated with the AWS Glue Data Catalog.
**Important**
Changing access control from AWS 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 AWS Lake Formation only. Before proceeding to migrate access controls from AWS 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 AWS 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 AWS 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.
1. **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"
}'
```
1. **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.