AWS EMR (on EC2) - Yarn Resource Manager vulnerability

Hello,

In general, security is the one of the important pillars in the AWS well architected framework. . In general, following the best practices recommended in EMR helps to mitigate the security related issues. To further double check your concerns, I strongly recommend to reach out AWS Support/TAM to get assistance more specific for your usecase.

1. We recommend to use Persistent Application UI's to remove the need to open firewall to get access to debugging UI. The block public access feature in EMR prevents a cluster in a public subnet from launching when any security group associated with the cluster has a rule that allows inbound traffic from IPv4 0.0.0.0/0 or IPv6 ::/0 (public access) on a port, unless the port has been specified as an exception - port 22 is an exception by default. This feature is enabled by default for each AWS Region in your AWS account and is not recommended to be turned off.
2. We recommend to use fine grained IAM policies in general for any services to manage the least and right privileges for the legitimate actions. EMR provides managed IAM policies to grant specific access privileges to users. Managed policies offer the benefit of updating automatically if permission requirements change. If you use inline policies, service changes may occur that cause permission errors to appear.
3. Recommend to upgrade your EMR Releases to latest version or use a Custom AMI to get the latest OS and application software patches that fix the vulnerabilities related issues. A couple of best practices docs.

https://aws.github.io/aws-emr-best-practices/security/best_practices/ https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/configuration-vulnerability.html

Hi,

In addition to above answer, I'd like to provide further information on your questions:

Could you please confirm that users cannot start any job with REST API via this exposed point?

EMR Persistent UI for YARN Timeline server is hosted outside the EMR cluster, and can be accessed even after cluster termination. It utilizes the application information and logs persisted to EMR managed S3 bucket. Hence, users cannot start any job with REST API via the endpoint for EMR Persistent UI. Ref: https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html#app-history-spark-UI-event-logs

We are making a dedicated IAM policy to forbid the creation of EMR cluster into public subnet, do you have any tamplate for this purpose?

I'm unsure if there is a verified template for this. As suggested in the previous answer, utilizing EMR Managed V2 Policies could provide some granular control in terms of tagging for-use-with-amazon-emr-managed-policies = true only the private subnets for EMR usage. However, it might not be a full-proof solution.

could you please also share with us some best practices to face this vulnerability?

In addition to previous recommendations, applying Security Configuration to enable Kerberos authentication, rest and in-transit encryption, and having a mechanism to check and notify of any EMR cluster in public subnet could be some of the best practices.