How Amazon EMR on EKS works with Amazon Lake Formation
Using Amazon EMR on EKS with Lake Formation lets you enforce a layer of permissions on each Spark Job to apply Lake Formation permission control
when Amazon EMR on EKS executes jobs. Amazon EMR on EKS uses Spark resource profiles
The following is a high-level overview of how Amazon EMR on EKS gets access to data protected by Lake Formation security policies.

The following steps describe this process:
A user submits a Spark Job to an Amazon Lake Formation-enabled Amazon EMR on EKS virtual cluster.
The Amazon EMR on EKS service sets up the User Driver and runs the job in the User Profile. The User Driver runs a lean version of Spark that has no ability to launch tasks, requests executors, access Amazon S3 or the Glue Data Catalog. It only builds a Job plan.
The Amazon EMR on EKS service sets up a second driver called a System Driver and runs it in the System Profile (with a privileged identity). Amazon EKS sets up an encrypted TLS channel between the two drivers for communication. The User Driver uses the channel to send the job plans to the System Driver. The System Driver does not run user-submitted code. It runs full Spark and communicates with Amazon S3 and the Data Catalog for data access. It requests executors and compiles the Job Plan into a sequence of execution stages.
Amazon EMR on EKS service then runs the stages on executors. User Code in any stage is run exclusively on User profile executors.
Stages that read data from Data Catalog tables protected by Lake Formation or those that apply security filters are delegated to System executors.