Hadoop Security with Kerberos

Analogy categoryAnalogies

Why Hadoop Needs Kerberos

By default, Hadoop runs in 'simple' authentication mode, which trusts whatever username the client process claims to be, equivalent to no real authentication at all, meaning anyone with network access to the cluster who sets their local username to 'hdfs' can potentially masquerade as the HDFS superuser and read or delete any file. Kerberos, a mature network authentication protocol originally developed at MIT, closes this gap by requiring every user and every Hadoop service, the NameNode, DataNodes, ResourceManager, to prove its identity cryptographically before any RPC call is honored, which is why enabling hadoop.security.authentication=kerberos is the first step in hardening any multi-tenant Hadoop cluster.

🏏

Cricket analogy: Simple authentication is like a stadium gate that lets anyone in just by saying their name out loud, no ticket check at all, while Kerberos is like requiring a verified ticket with a security chip scanned at the turnstile before anyone, even players, can enter the ground.

Kerberos Fundamentals: KDC, Principals, and Tickets

A Kerberos deployment centers on the Key Distribution Center (KDC), which holds every principal's secret key and issues two kinds of tickets: when a user runs kinit, the Authentication Service (AS) verifies their password and returns a Ticket Granting Ticket (TGT), a time-limited credential (typically valid 10-24 hours) proving the user authenticated once without needing to resend their password again; the user's client then presents that TGT to the Ticket Granting Service (TGS) to obtain a service ticket for a specific Hadoop daemon like the NameNode, and that service ticket is what actually gets sent with each RPC request. Hadoop service daemons themselves authenticate the same way but using a keytab file, an encrypted file holding the service principal's key so the daemon can obtain its own tickets non-interactively at startup without a human typing a password.

🏏

Cricket analogy: The TGT is like a player's tournament accreditation badge issued once after identity verification at the start of the World Cup, which they then present at each individual stadium's gate to get a match-specific access pass, rather than re-verifying identity fresh at every ground.

bash

# Obtain a TGT interactively (10-24 hour lifetime by default)
kinit alice@ANALYTICS.EXAMPLE.COM

# Inspect currently cached tickets
klist

# A Hadoop service authenticates non-interactively with a keytab
kinit -kt /etc/security/keytabs/nn.service.keytab \
      nn/namenode1.cluster.internal@ANALYTICS.EXAMPLE.COM

# Verify a keytab's principal entries
klist -kt /etc/security/keytabs/nn.service.keytab

A user's TGT is cached locally after kinit and reused for every subsequent service-ticket request until it expires, which is why long kinit lifetimes are convenient for interactive work but should still be bounded, an indefinitely renewable TGT defeats much of Kerberos's protection against a stolen credential.

Securing Hadoop Services

Enabling Kerberos across a cluster means setting core-site.xml's hadoop.security.authentication to kerberos and hadoop.security.authorization to true, then creating a dedicated Kerberos service principal and keytab for every daemon instance (for example nn/namenode.cluster.internal@REALM for the NameNode), and additionally enabling SPNEGO, an HTTP-layer extension of Kerberos, so that web UIs like the NameNode and ResourceManager dashboards also require a Kerberos ticket rather than serving pages to anonymous browsers. Client-facing tools like Hive, HBase, and Spark all need their own service principals too, and inter-service communication, DataNode-to-DataNode block transfers, for instance, must also be secured, since Kerberos alone doesn't encrypt data in transit; that requires separately enabling RPC encryption and SASL-wrapped data transfer.

🏏

Cricket analogy: Giving every Hadoop daemon its own keytab is like issuing every individual team official, not just players, their own personalized accreditation badge for a tournament, so a broadcast technician's credential is distinct from a groundskeeper's, each scoped to exactly what that role needs.

Authorization Beyond Authentication: Ranger and Delegation Tokens

Kerberos authentication alone doesn't handle fine-grained authorization, which is why enterprise Hadoop deployments layer Apache Ranger (or the older, now largely retired Apache Sentry) on top, providing a centralized policy engine for column-level and row-level access control on Hive tables, HDFS path permissions, and HBase table ACLs, all tied back to the same Kerberos-authenticated identity. For long-running YARN applications like a Spark job or an Oozie workflow that must keep accessing HDFS or Hive long after a user's short-lived Kerberos ticket would normally expire, Hadoop issues a delegation token, obtained once at job submission time and renewed automatically by the ResourceManager on the job owner's behalf, so the job doesn't need the user's Kerberos credentials cached for its entire runtime.

🏏

Cricket analogy: A delegation token is like a tour manager being handed a limited power-of-attorney to handle a player's logistics for the whole tour, so hotel and travel bookings can be renewed on the player's behalf without the player personally re-authorizing every single booking.

Kerberos is extremely sensitive to clock skew: if a client's clock and the KDC's clock drift by more than the configured tolerance (default 5 minutes), ticket validation fails outright with cryptic 'Clock skew too great' errors. Every node in a Kerberized cluster must run NTP and stay tightly synchronized, or authentication will intermittently break in ways that look like unrelated network issues.

Hadoop's default 'simple' authentication trusts a client-supplied username with no real verification.
Kerberos requires every user and service to cryptographically prove identity via the Key Distribution Center before any RPC is honored.
kinit obtains a Ticket Granting Ticket (TGT) from the Authentication Service; that TGT is then exchanged for per-service tickets via the Ticket Granting Service.
Hadoop daemons authenticate non-interactively at startup using a keytab file instead of a typed password.
SPNEGO extends Kerberos to HTTP, so web UIs like the NameNode dashboard also require a valid ticket.
Kerberos handles authentication only; tools like Apache Ranger provide the fine-grained authorization layer on top.
Delegation tokens let long-running YARN applications keep accessing HDFS/Hive without holding the user's Kerberos credentials for the job's entire runtime.