In today’s data-driven world , enterprises are increasingly reliant on vast amounts of data to drive decision-making and innovation. With this reliance comes the critical need for robust data security and access control mechanisms. Fine-grained access control restricts access to specific data subsets, protecting sensitive information and maintaining regulatory compliance. It allows organizations to set detailed permissions at various levels, including database, table, column, and row. This precise control mitigates risks of unauthorized access, data leaks, and misuse. In the unfortunate event of a security incident, fine-grained access control helps limit the scope of the breach, minimizing potential damage.
AWS is introducing general availability of fine-grained access control based on AWS Lake Formation for Amazon EMR Serverless on Amazon EMR 7.2. Enterprises can now significantly enhance their data governance and security frameworks. This new integration supports the implementation of modern data lake architectures, such as data mesh, by providing a seamless way to manage and analyze data. You can use EMR Serverless to enforce data access controls using Lake Formation when reading data from Amazon Simple Storage Service (Amazon S3), enabling robust data processing workflows and real-time analytics without the overhead of cluster management.
In this post, we discuss how to implement fine-grained access control in EMR Serverless using Lake Formation. With this integration, organizations can achieve better scalability, flexibility, and cost-efficiency in their data operations, ultimately driving more value from their data assets.
Key use cases for fine-grained access control in analytics The following are key use cases for fine-grained access control in analytics:
Solution overview In this post, we explore how to implement fine-grained access control on Iceberg tables within an EMR Serverless application, using the capabilities of Lake Formation. If you’re interested in learning how to implement fine-grained access control on open table formats in Amazon EMR running on Amazon Elastic Compute Cloud (Amazon EC2) instances using Lake Formation, refer to Enforce fine-grained access control on Open Table Formats via Amazon EMR integrated with AWS Lake Formation.
With the data access control features available in Lake Formation, you can enforce granular permissions and govern access to specific columns, rows, or cells within your Iceberg tables. This approach makes sure sensitive data remains secure and accessible only to authorized users or applications, aligning with your organization’s data governance policies and regulatory compliance requirements.
A cross-account modern data platform on AWS involves setting up a centralized data lake in a primary AWS account, while allowing controlled access to this data from secondary AWS accounts. This setup helps organizations maintain a single source of truth for their data, provides consistent data governance, and uses the robust security features of AWS across multiple business units or project teams.
To demonstrate how you can use Lake Formation to implement cross account fine-grained access control within an EMR Serverless environment, we use the TPC-DS dataset to create tables in the AWS Glue Data Catalog in the AWS producer account and provision different user personas to reflect various roles and access levels in the AWS consumer account, forming a secure and governed data lake.
The following diagram illustrates the solution architecture.
The producer account contains the following persona:
The consumer account contains the following personas:
store_sales, catalog_sales, web_sales, item, and promotion for comprehensive financial analysis.sales tables to avoid exposure to sensitive pricing strategies. Limited access to sensitive columns like credit_rating in the customer_demographics table.item, store_sales, and customer tables to evaluate product and market trends.customer table, such as customer_address , email_address, and date of birth.Prerequisites You should have the following prerequisites:
Set up infrastructure in the producer account We provide a CloudFormation template to deploy the data lake stack with the following resources:
Set up Lake Formation for the data engineer in the producer account Set up Lake Formation cross-account data sharing version settings:
To learn more about the differences between data sharing versions, refer to Updating cross-account data sharing version settings. Make sure Default permissions for newly created databases and tables is unchecked.
Register the Amazon S3 location as the data lake location When you register an Amazon S3 location with Lake Formation, you specify an IAM role with read/write permissions on that location. After registering, when EMR Serverless requests access to this Amazon S3 location, Lake Formation will supply temporary credentials of the provided role to access the data. We already created the role LakeFormationServiceRole using the CloudFormation template. To register the Amazon S3 location as the data lake location, complete the following steps:
s3://<DatalakeBucketName>. (Copy the bucket name from the CloudFormation stack’s Outputs tab.)LakeFormationServiceRoleDatalake.Generate TPC-DS tables in the producer account In this section, we generate TPC-DS tables in Iceberg format in the producer account.
Grant database permissions to the data engineer
First, let’s grant database permissions to the data engineer IAM role Amazon-EMR-ExecutionRole_DE that we will use with EMR Serverless. Complete the following steps:
iceberg_db for Name and s3://<DatalakeBucketName> for Location.Amazon-EMR-ExecutionRole_DE.tpc-source and iceberg_db for Databases.Create an EMR Serverless application Now, let’s log in to EMR Serverless using Amazon EMR Studio and complete the following steps:
my-emr-studio. You will be directed to the Create application page on EMR Studio. Let’s create a Lake Formation enabled EMR Serverless applicationemr-fgac-application.emrs-vpc for the VPC, enter any two private subnets, and enter emr-serverless-sg for Security groups.Create a Workspace Complete the following steps to create an EMR Workspace:
emr-fgac-workspace.emr-fgac-application for the application and Amazon-EMR-ExecutionRole_DE as the runtime role.To verify that the data is generated, you can go to the AWS Glue console. Under Data Catalog, Databases, you should see TPC-DS tables ending with _iceberg for the database iceberg_db.
Share the database and TPC-DS tables to the consumer account We now grant permissions to the consumer account, including grantable permissions. This allows the Lake Formation data lake administrator in the consumer account to control access to the data within the account.
Grant database permissions to the consumer account Complete the following steps:
iceberg_db, and on the Actions menu, under Permissions, choose Grant.iceberg_db for Databases.This allows the data lake administrator in the consumer account to describe the database and grant describe permissions to other principals in the consumer account.
Grant table permissions to the consumer account Repeat the preceding steps to grant table permissions to the consumer account.
Choose All tables under Tables and provide select and describe permissions for Table permissions and Grantable permissions.
Set up Lake Formation in the consumer account For the remaining section of the post, we focus on the consumer account. Deploy the following CloudFormation stack to set up resources:
The template will create the Amazon EMR runtime role for both analyst user personas.
Log in to the AWS consumer account and accept the AWS RAM invitation first:
You should be able to see the iceberg_db database on the Lake Formation console.
Create a resource link for the shared database To access the database and table resources that were shared by the producer AWS account, you need to create a resource link in the consumer AWS account. A resource link is a Data Catalog object that is a link to a local or shared database or table. After you create a resource link to a database or table, you can use the resource link name wherever you would use the database or table name. In this step, you grant permission on the resource links to the job runtime roles for EMR Serverless. The runtime roles will then access the data in shared databases and underlying tables through the resource link.
To create a resource link, complete the following steps:
iceberg_db database, verify that the owner account ID is the producer account, and on the Actions menu, choose Create resource links.iceberg_db_shared).iceberg_db database.Grant permissions on the resource link to the EMR job runtime roles Grant permissions on the resource link to Amazon-EMR-ExecutionRole_Finance and Amazon-EMR-ExecutionRole_Product using the following steps:
iceberg_db_shared) and on the Actions menu, choose Grant.iceberg_db_shared.This allows the EMR Serverless job runtime roles to describe the resource link. We don’t make any selections for grantable permissions because runtime roles shouldn’t be able to grant permissions to other principles.
Choose Grant.
Grant table permissions for the finance analyst Complete the following steps:
iceberg_db_shared) and on the Actions menu, choose Grant on target.Amazon-EMR-ExecutionRole_Finance.iceberg_db.store_sales_iceberg.ss_wholesale_cost and ss_ext_wholesale_cost).customer_demographics_iceberg and exclude the column cd_credit_rating.store_iceberg and item_iceberg.date_dim_iceberg, we provide selective row-level access.date_dim_iceberg under Tables and in the Data filters section, choose Create new.FA_Filter_year.d_year=2002 to only provide access to the 2002 year.FA_Filter_year is selected under Data filters and grant select permissions on the filter.Grant table permissions for the product analyst You can provide permissions for the next set of tables required for the product analyst role using the Lake Formation console. Alternatively, you can use the AWS Command Line Interface (AWS CLI) to grant permissions. We provide grant on target permissions for the resource link iceberg_db_shared to IAM role Amazon-EMR-ExecutionRole_Product.
store_sales_iceberg, date_dim_iceberg, store_iceberg, and house_hold_demographics_iceberg, provide select permissions for All data access. Make sure the role selected is Amazon-EMR-ExecutionRole_Product.For table customer_iceberg, we limit access to personally identifiable information (PII) columns.
c_birth_day, c_birth_month, c_birth_year, c_current_addr_sk, c_customer_id, c_email_address, and c_birth_country.Verify access using interactive notebooks from EMR Studio Complete the following steps to test role access:
emr-studio-service-role for Service role and datalake-resources-<account_id>-<region> for Workspace storage, then launch your Workspace.Now, let’s verify access for the finance analyst.
Amazon-EMR-ExecutionRole_Finance as the interactive runtime role.Now let’s test access for the product analyst.
Amazon-EMR-ExecutionRole_Product as the interactive runtime role.In a real-world scenario, both analysts will likely have their own Workspace with restricted rights to assume only the authorized interactive runtime role.
Considerations and limitations EMR Serverless with Lake Formation uses Spark resource profiles to create two profiles and two Spark drivers for access control. Read this white paper to learn about the feature details. The user profile runs the supplied code, and the system profile enforces Lake Formation policies. Therefore, it’s recommended that you have a minimum of two Spark drivers when pre-initialized capacity is used with Lake Formation enabled jobs. No change in executor count is required. Refer to Using EMR Serverless with AWS Lake Formation for fine-grained access control to learn more about the technical implementation of the Lake Formation integration with EMR Serverless.
Clean up To avoid incurring ongoing costs, complete the following steps to clean up your resources:
Conclusion In this post, we showed how to integrate Lake Formation with EMR Serverless to manage access to Iceberg tables. This solution showcases a modern way to enforce fine-grained access control in a multi-account open data lake setup. The approach simplifies data management in the main account while carefully controlling how users access data in other secondary accounts.
Try out the solution for your own use case, and let us know your feedback and questions in the comments section.
About the Authors Anubhav Awasthi is a Sr. Big Data Specialist Solutions Architect at AWS. He works with customers to provide architectural guidance for running analytics solutions on Amazon EMR, Amazon Athena, AWS Glue, and AWS Lake Formation.
Nishchai JM is an Analytics Specialist Solutions Architect at Amazon Web services. He specializes in building Big-data applications and help customer to modernize their applications on Cloud. He thinks Data is new oil and spends most of his time in deriving insights out of the Data.