EMR cluster Kerberos should be enabled
Without Kerberos, EMR clusters rely on weaker authentication where any user who can reach the cluster can impersonate others or access HDFS data without proper identity verification. Enforcing least privilege or auditing individual user actions across Spark, Hive, and other Hadoop services becomes practically impossible.
Enabling Kerberos ties every cluster action to a verified principal. HDFS file permissions, YARN queue ACLs, and Hive table grants then enforce who they claim to. For clusters processing sensitive data, Kerberos is the prerequisite that makes every downstream access control meaningful.
Implementation
Choose the approach that matches how you manage Terraform.
Use AWS provider resources directly. See docs for the resources involved: aws_emr_cluster.
resource "aws_emr_cluster" "this" {
ec2_attributes {
instance_profile = "arn:aws:iam::123456789012:instance-profile/example-instance-profile"
subnet_id = "subnet-12345678"
}
kerberos_attributes {
kdc_admin_password = "ChangeMe123!"
realm = "EC2.INTERNAL"
}
master_instance_group {
instance_type = "m5.xlarge"
}
name = "example-abc123"
release_label = "emr-6.15.0"
security_configuration = "example-security-config"
service_role = "arn:aws:iam::123456789012:role/example-role"
}What this control checks
Kerberos for EMR is configured in a security configuration referenced by the security_configuration argument on aws_emr_cluster (managed with aws_emr_security_configuration). The security configuration JSON must include Kerberos settings under AuthenticationConfiguration.KerberosConfiguration.
The kerberos_attributes block on aws_emr_cluster supplies Kerberos-related parameters required by certain setup modes, such as a cluster-dedicated KDC or AD cross-realm trust inputs. A cluster without a security configuration that includes Kerberos fails this control. If the selected Kerberos mode requires additional cluster attributes and they are absent or empty, the cluster is also non-compliant.
Common pitfalls
Sensitive password values in state
kdc_admin_password and cross_realm_trust_principal_password in kerberos_attributes are stored as plaintext in Terraform state. Use secrets manager references or sensitive variable declarations, and ensure the state backend uses encryption with restricted access.
Security configuration and cluster attributes must align
Kerberos enablement lives in aws_emr_security_configuration under AuthenticationConfiguration.KerberosConfiguration in the configuration JSON. The kerberos_attributes block on aws_emr_cluster supplies credentials and trust parameters, and its contents must match the Kerberos mode defined in the security configuration. A mismatch will either fail cluster launch or produce a cluster where authentication does not work as intended, with no obvious error surfaced.
Cross-realm trust requires networking to AD
If using Active Directory cross-realm trust, the EMR cluster VPC must have network connectivity to the AD domain controller. Missing security group rules or VPC peering will cause Kerberos ticket requests to time out silently, and the cluster may start but authentication will fail for AD-backed principals.
Transient clusters may be missed by periodic scans
Short-lived EMR clusters launched for batch jobs may terminate before AWS Config evaluates them. Use RunJobFlow CloudTrail event rules or an SCP that denies elasticmapreduce:RunJobFlow without KerberosAttributes to catch non-compliant launches in real time.
Audit evidence
An auditor expects to see that each in-scope EMR cluster references a security configuration with Kerberos enabled. The aws emr describe-cluster output should show the SecurityConfiguration name; aws emr describe-security-configuration for that name should contain AuthenticationConfiguration with KerberosConfiguration in the JSON body.
CloudTrail RunJobFlow events should show the securityConfiguration request parameter and, where applicable, Kerberos-related cluster attributes. AWS Config custom rules or Security Hub findings showing continuous evaluation across all in-scope EMR clusters provide ongoing assurance.
Framework-specific interpretation
SOC 2: CC6.1 and CC6.3 call for logical access controls restricting data processing infrastructure to authorized, authenticated individuals. Kerberos provides the verifiable identity layer SOC 2 auditors look for when assessing Hadoop workloads, and the ticket-based protocol supports separation-of-duties claims across Spark and Hive.
PCI DSS v4.0: Requirement 7 restricts system component access to need-to-know; Requirement 8 mandates identification and authentication for every user. On EMR, Kerberos addresses both: every user and service holds a ticket tied to a named principal, eliminating shared credentials and anonymous access to cardholder data environments.
HIPAA Omnibus Rule 2013: The HIPAA Security Rule requires covered entities to assign a unique user ID to each person accessing ePHI (45 CFR 164.312(d)) and maintain audit logs that attribute access to individuals (45 CFR 164.312(b)). Without Kerberos, neither requirement is enforceable at the EMR cluster level: shared or unauthenticated sessions make individual attribution impossible regardless of what downstream logging you have in place.
Related controls
Tool mappings
Use these identifiers to cross-reference this control across tools, reports, and evidence.
- Compliance.tf Control:
emr_cluster_kerberos_enabled - AWS Config Managed Rule:
EMR_KERBEROS_ENABLED - Powerpipe Control:
aws_compliance.control.emr_cluster_kerberos_enabled
Last reviewed: 2026-03-09