Hadoop and Kerberos

Page 1 © Hortonworks Inc. 2014

Hadoop Security Recap

Yuta Imai

Hadoop + Kerberos


この発表について

•  今⽇はおもにKerberosとHadoopの関係性についての話をします。

•  KerberosはHadoopにとって、とても重要ですが、とても複雑です。

•  Kerberosやらなきゃなのはわかってるんだけど、意味がわからん！という⼈に向けての発表です。


Background


Background: YARNによるHadoopのマルチテナント化

•  Hadoop2で導⼊されたYARNにより、Hadoopクラスタを複数のひとや組織、ワークロードによって共⽤することが容易になった。

•  巨⼤なHDFSクラスタに様々なデータを格納しておき、そのデータに対して様々な処理を⾛らせることが可能に。


1 ° ° ° ° ° ° ° ° °

° ° ° ° ° ° ° ° ° °

°

N

HDFS Hadoop Distributed File System

DATA MANAGEMENT

ストレージ(HDFS)とコンピューティング(MapReduce)が結合して

いた

Before YARN

MapReduce

クラスタ全体のリソース管理や、多数のアプリケーション起動時の性能的なボトルネックなどいくつ

かの課題があった


Others ISV Engines

YARN : Data Operating System

DATA ACCESS

1 ° ° ° ° ° ° ° ° °

° ° ° ° ° ° ° ° ° °

°

N

Batch MapReduce

Script Pig

Search Solr

SQL Hive

NoSQL HBase Accumulo Phoenix

Stream Storm

In-memory Spark

Tez Tez Tez Slider Slider


DATA MANAGEMENT

YARNの柔軟なAPIによりリソースが抽象化され、様々なアプリケーションが共存できるようになった。

HDFSはマルチテナントな巨⼤なデータストアとなった。

YARN


YARN

Others ISV Engines

YARN : Data Operating System

DATA ACCESS

1 ° ° ° ° ° ° ° ° °

° ° ° ° ° ° ° ° ° °

°

N

Batch MapReduce

Script Pig

Search Solr

SQL Hive

NoSQL HBase Accumulo Phoenix

Stream Storm

In-memory Spark

Tez Tez Tez Slider Slider


DATA MANAGEMENT

YARNによりリソースが抽象化され、様々なアプリケーションが共

存できるようになった。

HDFSはマルチテナントな巨⼤なデータストアとなった。

これにより、様々な組織や部署のひとが共⽤Hadoopクラスタを使

うようになった。

Division A Division B


マルチテナント環境の運⽤で注意するべき３つの項⽬

●  Shared Compute & Memory Capacity - 誰がどのくらいの計算リソースを使えるのか

●  Shared Storage Capacity - 誰がどのくらいのストレージを使えるのか

●  Security Controls- 誰が何をできるのか。


マルチテナント環境の運⽤で注意するべき３つの項⽬

●  Shared Compute & Memory Capacity - 誰がどのくらいの計算リソースを使えるのか

●  Shared Storage Capacity - 誰がどのくらいのストレージを使えるのか

●  Security Controls- 誰が何をできるのか。


YARN Queue: Key to Scheduling

●  Capacity: Guaranteed and maximum burst ●  Users & their resource limits ●  Access control lists (ACLs) ●  Node Labels

YARN: Capacity Schedulerによるコンピューティングリソースの管理


HDFS Storage Limits

Page 11

Hadoop Cluster Space Quotas •  Applied to directories •  Associated with users and groups •  Space quotas applied to a user

directory will limit the growth of that directory, not the amount of data a user can place in the cluster

•  The amount of data a single user can place in the cluster is limited by space quotas on their home directory, directories common to the user’s groups, and any common directories the user has access to

A tenant consists of users and groups. Each tenant can consume the sum of space allocated to directories associated with its users and groups.

Additionally, tenants can consume space in directories that are shared across Tenants.

The sum of all space quotas should equal the total amount of available space in the cluster, unless oversubscription is anticipated and consumption is monitored.

Remember to account for replication factors!

HDFSのQuota制御


HDFS Storage Allocation - Directories & Permission HDFSのファイルアクセスの管理


who?

ユーザーを正しく認証するということが⾮常に重要

いずれのケースにおいても


もちろんそれだけではない: 5 Pillars of Security

Administration Central management & consistent security

Authentication Authenticate users and systems

Authorization Provision access to data

Audit Maintain a record of data access

Data Protection Protect data at rest and in motion

実⾏者は誰？

実⾏者は何をできる？

いつ誰が何をした？

データは安全に移動/保存できる？

中央集約的に管理できる？


Hadoop Security Recap


一般的なHadoopセキュリティフローの概要

AuthZ

Auth

NameNode

1. 認証

2. ジョブリクエスト

5. オペレーションログ

DataNode

DataNode

暗号化

ResourceManager 3. ジョブサブミットの認可

4. ファイルアクセスの認可

※認証だけ外の世界に依存しているのが特徴


In Hortonworks Data Platform:

Administration Central management & consistent security

Authentication Authenticate users and systems

Authorization Provision access to data

Audit Maintain a record of data access

Data Protection Protect data at rest and in motion

Kerberos, Apache Knox

Apache Ranger, HDFS Permission

Apache Ranger

HDFS Transparent Data Encryptionwith Ranger KMS

Apache Ambari


Typical Access Control Flow - SQL

Page 18 © Hortonworks Inc. 2011 – 2015. All Rights Reserved


HDFS

Typical Flow – SQL Access through Beeline client

HiveServer 2 A B C

Beeline Client

Security set up with Hortonworks Data Platform


HDFS

Typical Flow – Authenticate through Kerberos or LDAP

HiveServer 2 A B C

KDC

Login into Hive

Hive gets Namenode (NN) service ticket

Hive creates map reduce using NN ST

Client gets service ticket for Hive

Beeline Client


Active Directory

Hiveserver2はKerberosもしくはLDAP認証を⾏える※カスタムな認証も実装可能


HDFS

Typical Flow – Add Authorization through Ranger

HiveServer 2 A B C

KDC


Column level access control, auditing

Ranger

Beeline Client

File level access control

Active Directory

Import users/groups from LDAP

Login into Hive using AD password



HDFS

Typical Flow – Firewall, Route through Knox Gateway

HiveServer 2 A B C

KDC

Use Hive ST, submit query



Ranger

Knox gets service ticket for Hive

Knox runs as proxy user using Hive ST

Original request w/user id/password

Client gets query result

Beeline Client

Apache Knox

Active Directory



HDFS

Typical Flow – Firewall, Route through Knox Gateway

HiveServer 2 A B C

KDC




Ranger





Beeline Client

Apache Knox

Active Directory


KnoxがサポートしているサービスYARN

WebHDFSWebHCat/Templeton

OozieHBase/Stargate

Hive (via WebHCat)Hive (via JDBC)


HDFS

Typical Flow – Add Wire and File Encryption

HiveServer 2 A B C

KDC




Ranger





SSL

Beeline Client

SSL SASL

SSL SSL

Apache Knox

Active Directory





Ranger’s Audit Log Visualization with Apache Solr


Ranger KMS

Data Protection With HDFS Transparent Data Encryption

NN

A B

C D

HDFS Client

A B

C D

A B

C D

DN DN DN

•  No need to encrypt whole disk •  Prevent rogue admin access to

sensitive data •  Different access control levels •  Transparent to end application

means few changes needed


•  Wire encryption in Hadoop

•  Native + Ranger KMS and partner encryption

•  Centralized audit reporting w/ Apache Ranger

•  Fine grain access control with Apache Ranger

Security today in Hadoop with HDP

Authorization What can I do?

Audit What did I do?

Data Protection Can data be encrypted at rest and over the wire?

•  Kerberos •  API security with

Apache Knox

Authentication Who am I/prove it?

HD

P 2.

3

Centralized Security Administration w/ Ranger

Ent

erpr

ise

Ser

vice

s: S

ecur

ity


In Hotonworks Data Platform:

•  Apache Rangerが認可と監査、Ranger KMSがHDFS暗号化の鍵管理、そしてApache Ambariがそれらの統合的な設定管理を提供する。

•  これらはすべて、ユーザーの認証が済んでからの話。セキュアな認証はKerberosが担当。

who? -> Kerberos※一部コンポーネントはADやLDAPでの認証をサポートしているものもある。


Kerberos: You MUST do it! “By default Hadoop runs in non-secure mode in which no actual authentication is required” – Apache Hadoop Documentation https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SecureMode.html


Here we are as the user ‘baduser’ $whoamibaduser$hadoopfs-ls/tmpdrwx-------hdfshdfs02015-07-1420:33/tmp/secure

$hadoopfs-ls/tmp/securels:Permissiondenied:user=baduser,access=READ_EXECUTE,inode="/tmp/secure":hdfs:hdfs:drwx------

Good right?

Kerberos: You MUSTdo it!


Kerberos: You MUST do it!

Here we are as the user ‘baduser’ $whoamibaduser$hadoopfs-ls/tmpdrwx-------hdfshdfs02015-07-1420:33/tmp/secure

$hadoopfs-ls/tmp/securels:Permissiondenied:user=baduser,access=READ_EXECUTE,inode="/tmp/secure":hdfs:hdfs:drwx------

Good right? Look again! $HADOOP_USER_NAME=hdfshadoopfs-ls/tmp/securedrwxr-xr-x-hdfshdfs02015-07-1420:35/tmp/secure/blah

Oh my!


Hadoop is Unix-like but…

•  HadoopのセキュリティモデルはUserとGroupに基づいた管理であり、⾮常にUnixライクであり⾮常にシンプル。

•  デフォルトでは実⾏者のUnixユーザーがHadoop内部でもそのままUser（とGroup）として扱う。

•  Kerberos化されたクラスタの場合、ユーザーのKerberos PrincipalをもとにUserとGroupを判断する。


Kerberos - You MUST do it!


Kerberos化(Kerberize)

•  Hadoopの認証周りの各種設定をKerberosを利⽤するように設定する。

•  各サービスが利⽤するkeytab(後述)を⽣成して配布する。•  詳細

•  https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/SecureMode.html

•  様々な設定や作業が必要だが、AmbariやCloudera Managerなどを使っていれば簡単に設定が可能。


Kerberos化(Kerberize)

•  Hadoopの認証周りの各種設定をKerberosを利⽤するように設定する。

•  各サービスが利⽤するkeytab(後述)を⽣成して配布する。•  詳細

•  https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/SecureMode.html

•  様々な設定や作業が必要だが、AmbariやCloudera Managerなどを使っていれば簡単に設定が可能。

基本的にはトランスペアレントに利⽤できるKerberos。今⽇はその裏側を⾒てみましょう。


What is Kerberos?

●  ネットワーク上の分散システムを想定して作られた認証システム

●  ３つの登場⼈物●  ユーザー(User Principal, UPN): 認証される側の⼈。サービスにアクセスする⼈。●  サービス(Service Principal, SPN): アクセスされる側のサービス。アクセスする側に回ることも。●  Kerberosインフラストラクチャ(AS,TGS): 認証のためのサービス群。

●  共有鍵ベースの認証

●  よく知られている実装としては下記のとおり●  MIT Kerberos●  Active Directory

•  [email protected]

•  nn/[email protected]


Kerberos is NOT

●  ディレクトリサービス ●  KerberosはユーザーのUIDやGroup情報などは管理しない ●  ただし、Active DirectoryやFreeIPAはKerberosとディレクトリサービス（LDAP）を統合して提供する。

●  認可サービス ●  Kerberosはユーザーの認証のみを提供し、認可は提供しない。


コンセプト•  REALMS – Kerberosが管理する対象のドメイン。慣習的にDNSのドメイン

と同じ⽂字列を使うことが多い。•  Host: revo1.example.com•  REALM: EXAMPLE.COM

•  Principals•  ユーザーやサービスを表すエンティティ。ユーザーを表すUser Principal(UPN)とサービスを表す

Service Principal(SPN)に別れる。•  {name of entity}/{instance}@{REALM}•  [email protected]•  nn/[email protected]

•  Instances•  ユーザーの役割やサービスの位置を表す•  yuta/[email protected]•  nn/[email protected]


コンポーネントKDC (Key Distribution Center) 1.   Principal/Key Database

•  Principalとそれらに紐づくkeyやmetadataを管理

2.   Authentication Server (AS) •  TGT(Ticket Granting Ticket)の発⾏を⾏う。•  TGTをユーザーのパスワードを使って暗号化したものをクライアントに返すので、それによって認

証がなされる。

3.   Ticket Granting Server (TGS) •  ST(Service Ticket)の発⾏を⾏う。•  クライアントからのリクエスト(TGS_REQ)には“アクセスしたいサービスのPrincipal”とTGTが含

まれており、TGTの検証が正しくなされれば、当該サービスへアクセスを許可するSTを発⾏する。


チケット1.   TGT(Ticket Granting Ticket)

•  STを要求するためのチケット。チケットのためのチケット。•  リクエスト時に⽣成されるsession keyという⽂字列を、TGSのキーで暗号化したもの。

2.   ST(Service Ticket) •  実際にサービスへのアクセスに利⽤されるチケット。•  アクセス先のサービスのService Principal(nn/[email protected])を含む。


チケットについての補足

チケットの持つメタ情報:•  利⽤スコープについてのフラグ

•  Lifetime, Forwardable, Renewable (max renew lifetime)

•  フィールド•  Requesting Principal Name•  Service Principal Name•  Validity Period•  Session key

発⾏されたチケットはクライアントにキャッシュされる。


•  アクセスしたい⼈: [email protected]•  アクセスしたいサービス: nn/[email protected]

ゴール•  [email protected]を使って、nn/

[email protected]のService Ticketを取得する。

First Step:•  Authentication ServerからTicket Granting Ticket(TGT)を取得する

例えばNameNodeへのアクセス時には・・・

※これはKerberosの仕組みを説明するために簡略化されたワークフロー。実際にHadoopの実装利⽤される際には若⼲の際があるので注意。詳細は後述。


1.   クライアント: Authentication Server(AS)へリクエスト(AS_REQ)を送信 – これにはユーザーのPrincipal、ローカルタイム、Ticket Granting Server(TGS)のPrincipal Namee.g. krbtgt/[email protected])が含まれる。Instance名のEXAMPLE.COMが、どのTGSが処理できるかを⽰す。

2.   AS: ユーザーのPrincipalが存在し、ローカルタイムに問題がないことを確認 - 問題なければ、ランダムなsession_key⽂字列を⽣成し、２つのコピーをつくる。ひとつはユーザーのパスワードで暗号化し、もうひとつはTGSのパスワードで暗号化する（これがTGT）。そして両者をまとめてクライアントに返す。




3.   クライアント:AS_REP内のsession_keyを復号化 – クライアントがユーザーに対してパスワードを求め、⼊⼒されたものを使ってAS_REPの復号化を⾏う。問題なく復号化されたら、sesison_keyとTGTはクライアントのキャッシュに保存される。




Ticket Cache:•  AS Session Key•  Ticket Granting Ticket (krbtgt/[email protected])

Next Steps:•  実際のサービスとやりとりするためのチケット(ST, Service Ticket)を

Ticket Granting Serverに要求する。




1.   クライアント: TGS requestを準備•  TGS Request – 下記を含む:

•  利⽤したいサービスのService Principle（の名前）。•  Ticket Granting Ticket (TGT) •  Authenticator – タイムスタンプをsession keyで暗号化したもの。リプレイ攻撃を防ぐためと、ASとの共有

鍵を持っていることを証明するために使われる。

2.   TGS: TGS reply – TGS Session Keyを⽣成し、やはり２つのコピーをつくる。１つはクライアント⽤にAS Session Keyで暗号化。もうひとつはサービス⽤にそのサービスのパスワードで暗号化し、Service Ticketに埋め込む。そしてリプライ全体はAS Session Keyで暗号化する。

3.   クライアント: TGS replyを処理 – AS Session Keyを使ってメッセージを復号化。TGS Session KeyとService Ticketをticket cacheに保存する。




Ticket Cache: •  AS Session Key

•  Ticket Granting Ticket (krbtgt/[email protected])

•  TGS Session Key

•  Service Ticket



Page 50 © Hortonworks Inc. 2014 ※これはKerberosの仕組みを説明するために簡略化されたワークフロー。

実際にHadoopの実装利⽤される際には若⼲の際があるので注意。詳細は後述。


Hadoop KDCAS TGSClient NameNode

AS_REQ(UPN,localtime,TGS_SPN)

AS_REP(enc(AS Session Key,TGT, user_password))

TGS_REQ(TGT, Target_SPN,Authenticator)

TGS_REP(enc(TGS Session Key, Service Ticket))

Hadoop RPC call(UPN, Service Ticket(TGS Session Key))

dec(TGT)

dec( AS_REP, UPN Password)

dec( TGS_REP, AS Session Key)

dec( TGS Session Key, SPN Password)


Kerberos + Hadoop HadoopにおけるKerberosの組み込み


Kerbeos認証とHadoop

1.  AS: TGT取得 2.  Hadoop APIの呼び出し

3.  TGS: Service Ticket取得

4.  User名の解決

5.  Group名の解決

6.  Delegation Token/ Block Access Tokenの発行

7.  Impersonation

8.  APIの中身の実行

Client: KDCとのやりとり

Client: UPN、TGT、Service TicketをHadoopのサービスに渡す

User Resolution。KerberosのPrincipalから、実際の処理の実⾏ユーザーを決めるための⼀連の処理。

Hadoop: TGTを使ってSTを取得※実際のHadoopの実装ではSTはClientではなくHadoopが要求

上記⾚字の補⾜にあるとおり、実際のHadoop内でのKerberos利⽤の際は、ST取得はクライアントではなくHadoop側で⾏われるので注意。


Kerberos認証とHadoop

$　hdfs dfs –ls /user/yuta $ kinit [email protected] $　hdfs dfs –ls /user/yuta

Before

After


KerberosのService Ticketを受け取ってからの挙動

Hadoop KDCAS TGSClient NameNode

AS_REQ(UPN,localtime,TGS_SPN)

AS_REP(enc(AS Session Key,TGT, user_password))

TGS_REQ(TGT, Target_SPN,Authenticator)

TGS_REP(enc(TGS Session Key, Service Ticket))

Hadoop RPC call(UPN, Service Ticket(TGS Session Key))

Hadoop RPC Response

auto_to_localgroup mapping

Get required ST

(Create Token)(Impersonate)works!


User Resolution User名とGroup名の解決


User名の解決 – auth_to_local

•  RPC Call/API Callとともに渡されるService TicketにはService Principalが含まれている。しかし、このPrincipal名そのままをHadoopは扱えない。

•  Hadoopの各サービスはここから利⽤可能なUser名に変換する。⼀般的にOSのユーザー名に変換をしてやる。

•  hadoop.security.auth_to_local

[email protected] -> yutaadmin/[email protected] -> adminnn/[email protected] -> hdfs


Auth To Local Rules

RULE:[1:$1@$0]([email protected])s/.*/ambari-qa/

RULE:[1:$1@$0]([email protected])s/.*/hbase/

RULE:[1:$1@$0]([email protected])s/.*/hdfs/

RULE:[1:$1@$0](.*@HORTONWORKS.LOCAL)s/@.*//

RULE:[2:$1@$0]([email protected])s/.*/ams/

RULE:[2:$1@$0]([email protected])s/.*/ams/

RULE:[2:$1@$0]([email protected])s/.*/hdfs/

RULE:[2:$1@$0]([email protected])s/.*/hbase/

RULE:[2:$1@$0]([email protected])s/.*/hive/


Group名の解決 – User Group Mapping

•  User名が解決されたので、次はGroup名を解決したい。•  しかし、HadoopはそもそもGroupという概念を内部に持っていないので、

User名に対応するOSのGroup名を利⽤する。•  hadoop.security.group.mapping•  Unix /etc/passwd•  LDAP

•  ということは、Hadoopクラスタのすべてのマシンは同じUser/Groupを持っている必要がある！

•  このへんでActive DirectoryやOpenLDAPが必要になってくる。


User/Groupを統⼀管理するためのツールOpen Source:•  SSSD•  pam_ldap/pam_kerberosCommercial:•  Centrify•  QAS


Delegation Token/Block Access Token•  MapReduceやTezなど、ひとつのジョブで複数回のNameNodeへのアクセ

スを要求するようなアプリケーションの場合は、毎回Kerberos認証を⾏う代わりに、NameNodeがDelegation Tokenというものを払い出し、２回め以降のアクセスにはこれを使うことができる。

•  これを使うか使わないかはアプリケーションの実装に依存。•  更にDataNodeのBlockに対するオペレーションについてはNameNodeが

Block Access Tokenというブロックへのアクセス認証Tokenを払い出す。


Block Access Token

Page 61

Client

KDC

NN

DN

1. kinit - Login and get Ticket Granting Ticket (TGT) 3. Get NameNode Service Ticket (NN-ST)

2. Client Stores TGT in Ticket Cache 4. Client Stores NN-ST in Ticket Cache

5. Read/write file given NN-ST and file name; returns block locations, block IDs and Block Access Tokens

if access permitted

6. Read/write block given Block Access Token and block ID

Client’s Kerberos

Ticket Cache


Impersonation•  User名の解決はUPNをauth_to_localしたものが利⽤される。•  しかし、場合によっては別のユーザーとしてジョブを実⾏したい場合もある。•  例: Oozieのようなスケジューラはoozieユーザーでスケジューリングをしつ

つ、実際のジョブはyutaやadmin、もしくはhdfs、yarnなどで実⾏したい。•  これを実現してくれるのがImpersonation(物真似、なりすまし)。•  利⽤するかどうかはアプリケーション側に依存。•  Proxy, Proxy Userとも呼ばれる。設定項⽬

•  hadoop.proxyuser.${user}.groups <- ${user}がimpersonateできるgroup•  hadoop.proxyuser.${user}.hosts <- ${user}がimpersonateできるhost


全体の流れの整理

1.  AS: TGT取得 2.  Hadoop APIの呼び出し

3.  TGS: Service Ticket取得

4.  User名の解決

5.  Group名の解決

6.  Delegation Token/ Block Access Tokenの発行

7.  Impersonation

8.  APIの中身の実行

Client: KDCとのやりとり

Client: UPN、TGT、Service TicketをHadoopのサービスに渡す

Hadoop: auth_to_localする

Hadoop: OSやLDAPをもとにUser名からGroup名の解決

Hadoop: UPNをもとに実⾏ユーザーの決定

Hadoop: MapReduceやTezの場合、繰り返しアクセスのためのDelegation Tokenを発⾏して利⽤。更にBlock オペレーションのためのBlock Access Tokenを発⾏

Hadoop: TGTを使ってSTを取得※実際のHadoopの実装ではSTはClientではなくHadoopが要求


まとめ•  YARNによってHadoopのマルチテナント化が進んでいる•  認証、認可、監査、暗号化の4点と統合された管理、が考えるべ

きセキュリティの柱。•  認可、監査、暗号化（の鍵管理）はいずれも「正しい認証」に依

存する。•  Hadoopは認証にKerberosを採⽤している。•  Kerberosの利⽤⾃体はクラスタマネージャを使えば容易。•  ただしKerberosとHadoopの組み合わせはとても複雑。•  理解しておくと、うれしいことがあるかも・・・？笑


プレゼントが当たる抽選やってます！

and, of course,We are hiring! ご興味ある方はぜひ声をかけてね。

•  特等賞(1名様) – Bose QuietComfort 20 ノイズキャンセリングヘッドホン

•  Hortonworks賞(20名様) – Hortonworksロゴ入りソックス

•  Hadoop賞(参加者全員) – Hortonworksステッカー ※応募時に名刺を1枚頂きます。後日、弊社より様々な情報をお送りさせていただく場合があります。ご了承下さい。 ※Bose QuietComfort 20は後日発送いたします。


Field Notes: Kerberos (AD or MIT KDC)

Challenges: •  HDP requires several SPNs (typically 3-5 per datanode) •  Most AD admins are not happy with that

Recommendations: a)  Integrate directly with Active Directory

i)  At >100 nodes, provide dedicated AD replica for the cluster b)  MIT KDC in the cluster for SPNs. Cross-realm trust to AD for UPNs (users)

Note on Users/Groups:

• Users/Groups from your directoy should exist in the Hadoop nodes • Common implementations: SSSD, Centrify, VAS

Software

Hadoop and Kerberos