Hadoop and Kerberos

© 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
TezTez 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
TezTez Tez Slider Slider
DATA MANAGEMENT
YARNによりリソースが抽象化さ
れ、様々なアプリケーションが共
存できるようになった。
HDFSはマルチテナントな巨⼤な
データストアとなった。
これにより、様々な組織や部署の
ひとが共⽤Hadoopクラスタを使
うようになった。
Division A Division B

マルチテナント環境の運⽤で注意するべき３つの項⽬
●  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 ClusterSpace 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 & PermissionHDFSのファイルアクセスの管理

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 Encryption
with 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
Hive gets
Namenode (NN)
service ticket
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
Hive gets
Namenode (NN)
service ticket
Hive creates
map reduce
using NN ST
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
Use Hive ST,
submit query
Hive gets
Namenode (NN)
service ticket
Hive creates
map reduce
using NN ST
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
Knoxがサポートしているサービス
YARN
WebHDFS
WebHCat/Templeton
Oozie
HBase/Stargate
Hive (via WebHCat)
Hive (via JDBC)

HDFS
Typical Flow – Add Wire and File Encryption
HiveServer 2
A B C
KDC
Use Hive ST,
submit query
Hive gets
Namenode (NN)
service ticket
Hive creates
map reduce
using NN ST
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
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?
HDP2.3
Centralized Security Administration w/ Ranger
EnterpriseServices:Security

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’
$ whoami
baduser

$ hadoop fs -ls /tmp
drwx------ - hdfs hdfs 0 2015-07-14 20:33 /tmp/secure
$ hadoop fs -ls /tmp/secure
ls: Permission denied: 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’
$ whoami
baduser

$ hadoop fs -ls /tmp
drwx------ - hdfs hdfs 0 2015-07-14 20:33 /tmp/secure
$ hadoop fs -ls /tmp/secure
ls: Permission denied: user=baduser, access=READ_EXECUTE, inode="/tmp/
secure":hdfs:hdfs:drwx------
Good right? Look again!
$ HADOOP_USER_NAME=hdfs hadoop fs -ls /tmp/secure
drwxr-xr-x - hdfs hdfs 0 2015-07-14 20: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
•  yuta@EXAMPLE.COM
•  nn/revo1.example.com@EXAMPLE.COM

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}
•  yuta@EXAMPLE.COM
•  Instances
•  ユーザーの役割やサービスの位置を表す
•  yuta/admin@EXAMPLE.COM

コンポーネント
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/revo1.example.com@EXAMPLE.COM)を含む。

チケットについての補足
チケットの持つメタ情報:
•  利⽤スコープについてのフラグ
•  Lifetime, Forwardable, Renewable (max renew lifetime)
•  フィールド
•  Requesting Principal Name
•  Service Principal Name
•  Validity Period
•  Session key
発⾏されたチケットはクライアントにキャッシュされる。

•  アクセスしたい⼈: yuta@EXAMPLE.COM
•  アクセスしたいサービス: nn/revo1.example.com@EXAMPLE.COM
ゴール
•  yuta@EXAMPLE.COMを使って、nn/
revo1.example.com@EXAMPLE.COMの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/
EXAMPLE.COM@EXAMPLE.COM)が含まれる。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/EXAMPLE.COM@EXAMPLE.COM)
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/EXAMPLE.COM@EXAMPLE.COM)
•  TGS Session Key
•  Service Ticket

Hadoop KDC
AS TGS
Client 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 yuta@EXAMPLE.COM
$　hdfs dfs –ls /user/yuta
Before
After

KerberosのService Ticketを受け取ってからの挙動
Hadoop KDC
AS TGS
Client 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_local
group 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
yuta@EXAMPLE.COM -> yuta
admin/admin@EXAMPLE.COM -> admin
nn/revo1.example.com@EXAMPLE.COM -> hdfs

Auth To Local Rules
RULE:[1:$1@$0](ambari-qa-HDP1@HORTONWORKS.LOCAL)s/.*/ambari-qa/
RULE:[1:$1@$0](hbase-HDP1@HORTONWORKS.LOCAL)s/.*/hbase/
RULE:[1:$1@$0](hdfs-HDP1@HORTONWORKS.LOCAL)s/.*/hdfs/
RULE:[1:$1@$0](.*@HORTONWORKS.LOCAL)s/@.*//
RULE:[2:$1@$0](amshbase@HORTONWORKS.LOCAL)s/.*/ams/
RULE:[2:$1@$0](amszk@HORTONWORKS.LOCAL)s/.*/ams/
RULE:[2:$1@$0](dn@HORTONWORKS.LOCAL)s/.*/hdfs/
RULE:[2:$1@$0](hbase@HORTONWORKS.LOCAL)s/.*/hbase/
RULE:[2:$1@$0](hive@HORTONWORKS.LOCAL)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_kerberos
Commercial:
•  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

Hadoop and Kerberos

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (10)

Semelhante a Hadoop and Kerberos

Semelhante a Hadoop and Kerberos (20)

Mais de Yuta Imai

Mais de Yuta Imai (20)

Hadoop and Kerberos