セキュアモードでの Hadoop

エンドユーザーアカウント

サービスレベル認証が有効になっている場合、エンドユーザーは Hadoop サービスと対話する前に認証する必要があります。最も簡単な方法は、Kerberos kinit コマンドを使用して、ユーザーが対話的に認証することです。kinit を使用した対話型ログインが不可能な場合は、Kerberos keytab ファイルを使用したプログラムによる認証を使用できます。

Hadoop デーモンのユーザーアカウント

HDFS および YARN デーモンが、hdfs や yarn などの異なる Unix ユーザーとして実行されることを確認してください。また、MapReduce JobHistory サーバーが mapred などの異なるユーザーとして実行されることを確認してください。

それらを Unix グループ（hadoop など）で共有することをお勧めします。グループ管理については、「ユーザーからグループへのマッピング」も参照してください。

Hadoop デーモンの Kerberos プリンシパル

各 Hadoop サービスインスタンスは、Kerberos プリンシパルと keytab ファイルの場所で構成する必要があります。

サービスプリンシパルの一般的な形式は、ServiceName/_HOST@REALM.TLD です。例：dn/_HOST@EXAMPLE.COM。

Hadoop は、サービスプリンシパルのホスト名コンポーネントを _HOST ワイルドカードとして指定できるようにすることで、構成ファイルのデプロイを簡素化します。各サービスインスタンスは、実行時に _HOST を独自の完全修飾ホスト名に置き換えます。これにより、管理者は同じ構成ファイルのセットをすべてのノードにデプロイできます。ただし、keytab ファイルは異なります。

$ klist -e -k -t /etc/security/keytab/nn.service.keytab
Keytab name: FILE:/etc/security/keytab/nn.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 nn/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nn/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nn/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

$ klist -e -k -t /etc/security/keytab/sn.service.keytab
Keytab name: FILE:/etc/security/keytab/sn.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 sn/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 sn/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 sn/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

$ klist -e -k -t /etc/security/keytab/dn.service.keytab
Keytab name: FILE:/etc/security/keytab/dn.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 dn/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 dn/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 dn/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

$ klist -e -k -t /etc/security/keytab/rm.service.keytab
Keytab name: FILE:/etc/security/keytab/rm.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 rm/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 rm/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 rm/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

$ klist -e -k -t /etc/security/keytab/nm.service.keytab
Keytab name: FILE:/etc/security/keytab/nm.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 nm/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nm/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nm/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

$ klist -e -k -t /etc/security/keytab/jhs.service.keytab
Keytab name: FILE:/etc/security/keytab/jhs.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 jhs/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 jhs/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 jhs/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

Kerberos プリンシパルから OS ユーザーアカウントへのマッピング

Hadoop は、hadoop.security.auth_to_local で指定されたルールを使用して、Kerberos プリンシパルを OS ユーザー (システム) アカウントにマップします。Hadoop がこれらのルールを評価する方法は、hadoop.security.auth_to_local.mechanism の設定によって決まります。

デフォルトの hadoop モードでは、Kerberos プリンシパルは、プリンシパルをシンプルな形式（つまり、' @' または '/' のないユーザーアカウント名）に変換するルールと一致する必要があります。そうでない場合、プリンシパルは承認されず、エラーが記録されます。MIT モードの場合、ルールは Kerberos 構成ファイル (krb5.conf) の auth_to_local と同じように機能し、hadoop モードの制限は適用されません。MIT モードを使用する場合は、デフォルトレルムの一部として /etc/krb5.conf で指定されているのと同じ auth_to_local ルールを使用し、それらを同期させることが推奨されます。hadoop モードと MIT モードの両方で、指定されたレルムに関係なく、(DEFAULT を除いて) ルールが *すべて* のプリンシパルに適用されます。また、auth_to_local ルールを ACL として使用するのではなく、適切な (OS) メカニズムを使用する必要があります。

auth_to_local の可能な値は次のとおりです。

• RULE:exp ローカル名は exp から作成されます。exp の形式は [n:string](regexp)s/pattern/replacement/g です。整数 n は、ターゲットプリンシパルが持つべきコンポーネントの数を示します。これが一致する場合、文字列は文字列から作成され、プリンシパルのレルムが $0 に、プリンシパルの n 番目のコンポーネントが $n に代入されます (たとえば、プリンシパルが johndoe/admin の場合、[2:$2$1foo] は adminjohndoefoo という文字列になります)。この文字列が regexp と一致する場合、s//[g] 置換コマンドが文字列に対して実行されます。オプションの g を指定すると、文字列内の最初のマッチのみを置換するのではなく、文字列全体で置換がグローバルに行われます。MIT の拡張として、Hadoop auth_to_local マッピングは、返される名前を小文字にする /L フラグをサポートしています。

• DEFAULT レルムが default_realm (通常は /etc/krb5.conf で定義) と一致する場合に限り、プリンシパル名の最初のコンポーネントをシステムユーザー名として選択します。例：デフォルトルールは、デフォルトレルムが MYREALM.TLD の場合、プリンシパル host/full.qualified.domain.name@MYREALM.TLD をシステムユーザー host にマップします。

ルールが指定されていない場合、Hadoop はデフォルトで DEFAULT を使用します。これは、ほとんどのクラスターには*適切ではない*可能性があります。

Hadoop は複数のデフォルトレルムをサポートしていないことに注意してください (Heimdal のように)。また、Hadoop は、ローカルシステムアカウントが存在するかどうかをマッピングで検証しません。

ルールの例

一般的なクラスターでは、HDFS および YARN サービスはそれぞれシステム hdfs および yarn ユーザーとして起動されます。hadoop.security.auth_to_local は次のように構成できます。

<property>
  <name>hadoop.security.auth_to_local</name>
  <value>
    RULE:[2:$1/$2@$0]([ndj]n/.*@REALM.\TLD)s/.*/hdfs/
    RULE:[2:$1/$2@$0]([rn]m/.*@REALM\.TLD)s/.*/yarn/
    RULE:[2:$1/$2@$0](jhs/.*@REALM\.TLD)s/.*/mapred/
    DEFAULT
  </value>
</property>

これは、レルム REALM.TLD の任意の host 上の任意のプリンシパル nn, dn, jn をローカルシステムアカウント hdfs にマップします。次に、REALM.TLD の任意の host 上の任意のプリンシパル rm, nm をローカルシステムアカウント yarn にマップします。3番目に、レルム REALM.TLD の任意の host 上のプリンシパル jhs をローカルシステムアカウント mapred にマップします。最後に、デフォルトレルムの任意のホスト上の任意のプリンシパルは、そのプリンシパルのユーザーコンポーネントにマップされます。

カスタムルールは、hadoop kerbname コマンドを使用してテストできます。このコマンドでは、プリンシパルを指定し、Hadoopの現在の auth_to_local ルールセットを適用できます。

ユーザーからグループへのマッピング

システムユーザーからシステムグループへのマッピングメカニズムは、hadoop.security.group.mapping を介して構成できます。詳細については、Hadoop グループマッピングを参照してください。

実際には、セキュアモードの Hadoop で LDAP を使用して Kerberos を使用して SSO 環境を管理する必要があります。

プロキシユーザー

Apache Oozie など、エンドユーザーに代わって Hadoop のサービスにアクセスする一部の製品は、エンドユーザーになりすますことができる必要があります。詳細については、プロキシユーザーのドキュメントを参照してください。

セキュア DataNode

DataNodeデータ転送プロトコルはHadoop RPCフレームワークを使用しないため、DataNodeはdfs.datanode.addressとdfs.datanode.http.addressで指定された特権ポートを使用して自身を認証する必要があります。この認証は、攻撃者がDataNodeホストでルート権限を取得できないという前提に基づいています。

hdfs datanode コマンドを root として実行すると、サーバープロセスは最初に特権ポートをバインドし、次に権限を破棄し、HDFS_DATANODE_SECURE_USER で指定されたユーザーアカウントとして実行されます。この起動プロセスでは、JSVC_HOME にインストールされている jsvc プログラムを使用します。起動時に (hadoop-env.sh で) HDFS_DATANODE_SECURE_USER と JSVC_HOME を環境変数として指定する必要があります。

バージョン 2.6.0 以降では、SASL を使用してデータ転送プロトコルを認証できます。この構成では、セキュリティ保護されたクラスタが jsvc を使用して root として DataNode を起動し、特権ポートにバインドする必要はなくなりました。データ転送プロトコルで SASL を有効にするには、hdfs-site.xml で dfs.data.transfer.protection を設定します。SASL 対応の DataNode は、次の 2 つの方法でセキュアモードで起動できます。1. dfs.datanode.address に非特権ポートを設定します。2. dfs.http.policy を HTTPS_ONLY に設定するか、dfs.datanode.http.address を特権ポートに設定し、起動時に (hadoop-env.sh で) HDFS_DATANODE_SECURE_USER および JSVC_HOME 環境変数が環境変数として正しく指定されていることを確認します。

root 認証を使用していた既存のクラスタを移行して代わりに SASL を使用するには、まず、2.6.0 以降のバージョンがすべてのクラスタノードと、クラスタに接続する必要のある外部アプリケーションに展開されていることを確認してください。データ転送プロトコルの認証に SASL を使用する DataNode に接続できるのは、HDFS クライアントのバージョン 2.6.0 以降のみであるため、移行する前にすべての呼び出し元が正しいバージョンを持っていることが不可欠です。2.6.0 以降のバージョンがすべてに展開されたら、外部アプリケーションの設定を更新して SASL を有効にします。HDFS クライアントで SASL が有効になっている場合、root 認証または SASL 認証のいずれかで実行されている DataNode に正常に接続できます。すべてのクライアントの設定を変更することで、DataNode でのその後の構成変更がアプリケーションを中断しないことが保証されます。最後に、各 DataNode は、構成を変更して再起動することで移行できます。この移行期間中は、root 認証で実行されている DataNode と SASL 認証で実行されている DataNode が混在していてもかまいません。SASL が有効になっている HDFS クライアントはどちらにも接続できるためです。

RPC でのデータ暗号化

Hadoopサービスとクライアントの間で転送されるデータは、転送中に暗号化できます。core-site.xml で hadoop.rpc.protection を privacy に設定すると、データ暗号化が有効になります。

ブロックデータ転送でのデータ暗号化。

DataNode のデータ転送プロトコルのデータ暗号化を有効にするには、hdfs-site.xml で dfs.encrypt.data.transfer を true に設定する必要があります。

オプションで、特定の暗号化アルゴリズムを選択するために、dfs.encrypt.data.transfer.algorithm を 3des または rc4 に設定できます。指定しない場合、システムで構成された JCE のデフォルト (通常は 3DES) が使用されます。

dfs.encrypt.data.transfer.cipher.suites を AES/CTR/NoPadding に設定すると、AES 暗号化が有効になります。デフォルトでは、これは指定されていないため、AES は使用されません。AES が使用される場合でも、dfs.encrypt.data.transfer.algorithm で指定されたアルゴリズムが最初の鍵交換中に使用されます。AES キービット長は、dfs.encrypt.data.transfer.cipher.key.bitlength を 128、192、または 256 に設定することで構成できます。デフォルトは 128 です。

AES は、最大の暗号強度と最高のパフォーマンスを提供します。現時点では、3DES および RC4 が Hadoop クラスタでより頻繁に使用されています。

HTTPでのデータ暗号化

Web コンソールとクライアント間のデータ転送は、SSL (HTTPS) を使用して保護されます。SSL 構成は推奨されますが、Kerberos で Hadoop セキュリティを構成するために必須ではありません。

HDFS デーモンの Web コンソールで SSL を有効にするには、hdfs-site.xml で dfs.http.policy を HTTPS_ONLY または HTTP_AND_HTTPS のいずれかに設定します。KMS および HttpFS はこのパラメーターを尊重しないことに注意してください。HTTPS を介した KMS の有効化と、HTTPS を介した HttpFS の有効化の詳細については、Hadoop KMS および HTTP 上の Hadoop HDFS - サーバー設定を参照してください。

YARN デーモンの Web コンソールで SSL を有効にするには、yarn-site.xml で yarn.http.policy を HTTPS_ONLY に設定します。

MapReduce JobHistory サーバーの Web コンソールで SSL を有効にするには、mapred-site.xml で mapreduce.jobhistory.http.policy を HTTPS_ONLY に設定します。

HDFS とローカルファイルシステムパスの両方の権限

次の表に、HDFS およびローカルファイルシステム (すべてのノード上) 上のさまざまなパスと推奨される権限を示します。

共通構成

Hadoop で RPC 認証を有効にするには、hadoop.security.authentication プロパティの値を "kerberos" に設定し、以下に示すセキュリティ関連の設定を適切に設定します。

次のプロパティは、クラスタ内のすべてのノードの core-site.xml にある必要があります。

NameNode

次の設定を使用すると、NameNode Web UI への SSL アクセスを構成できます (オプション)。

セカンダリ NameNode

JournalNode

DataNode

WebHDFS

ResourceManager

NodeManager

WebAppProxyの設定

WebAppProxyは、アプリケーションによってエクスポートされたWebアプリケーションとエンドユーザー間のプロキシを提供します。セキュリティが有効な場合、潜在的に安全でないWebアプリケーションにアクセスする前にユーザーに警告します。プロキシを使用した認証と認可は、他の特権付きWebアプリケーションと同様に処理されます。

LinuxContainerExecutor

YARNフレームワークで使用されるContainerExecutor。これは、起動および制御されるコンテナを定義します。

以下はHadoop YARNで利用可能です。

LinuxContainerExecutor実行可能ファイルをビルドするには、以下を実行します。

 $ mvn package -Dcontainer-executor.conf.dir=/etc/hadoop/

-Dcontainer-executor.conf.dirに渡されるパスは、setuid実行可能ファイルの構成ファイルを配置する必要があるクラスタノード上のパスである必要があります。実行可能ファイルは、$HADOOP_YARN_HOME/binにインストールする必要があります。

実行可能ファイルには、特定の権限が必要です。6050または--Sr-s---権限は、root（スーパーユーザー）が所有し、NodeManager Unixユーザーがグループメンバーである特別なグループ（例：hadoop）がグループ所有者であり、通常のアプリケーションユーザーはメンバーではありません。アプリケーションユーザーがこの特別なグループに属している場合、セキュリティが侵害されます。この特別なグループ名は、conf/yarn-site.xmlとconf/container-executor.cfgの両方で、構成プロパティyarn.nodemanager.linux-container-executor.groupに対して指定する必要があります。

たとえば、NodeManagerがユーザーyarnとして実行され、グループusersとhadoopの一部であり、そのいずれかがプライマリグループであるとします。また、usersには、yarnと別のユーザー（アプリケーション送信者）aliceがメンバーとしており、aliceはhadoopに属していないとします。上記の説明に従うと、setuid/setgid実行可能ファイルは、ユーザー所有者としてyarn、グループ所有者としてhadoopで6050または--Sr-s---に設定する必要があります。hadoopにはyarnがメンバーであり（aliceもメンバーであるusersではなく）、yarnもメンバーではありません。

LinuxTaskControllerでは、yarn.nodemanager.local-dirsおよびyarn.nodemanager.log-dirsで指定されたディレクトリを含むパスと、そのディレクトリに至るまでのパスは、上記のディレクトリの権限の表で説明したように、755権限に設定する必要があります。

• conf/container-executor.cfg

実行可能ファイルには、上記で説明したmvnターゲットに渡された構成ディレクトリにcontainer-executor.cfgという構成ファイルが存在する必要があります。

構成ファイルは、NodeManagerを実行しているユーザー（上記の例ではユーザーyarn）が所有し、グループ所有者は誰でもよく、権限は0400またはr--------である必要があります。

実行可能ファイルでは、conf/container-executor.cfgファイルに次の構成項目が存在する必要があります。項目は、1行に1つずつ、単純なkey=valueペアとして記述する必要があります。

まとめると、以下は、LinuxContainerExecutorに関連するさまざまなパスに必要なローカルファイルシステムの権限です。

MapReduce JobHistory サーバー

使用法

KDiag: Diagnose Kerberos Problems
  [-D key=value] : Define a configuration option.
  [--jaas] : Require a JAAS file to be defined in java.security.auth.login.config.
  [--keylen <keylen>] : Require a minimum size for encryption keys supported by the JVM. Default value : 256.
  [--keytab <keytab> --principal <principal>] : Login from a keytab as a specific principal.
  [--nofail] : Do not fail on the first problem.
  [--nologin] : Do not attempt to log in.
  [--out <file>] : Write output to a file.
  [--resource <resource>] : Load an XML configuration resource.
  [--secure] : Require the hadoop configuration to be secure.
  [--verifyshortname <principal>]: Verify the short name of the specific principal does not contain '@' or '/'

hadoop kdiag --out out.txt

hadoop kdiag --keytab zk.service.keytab --principal zookeeper/devix.example.org@REALM > out.txt 2>&1

hadoop kdiag --resource hbase-default.xml --resource hbase-site.xml

<property>
  <name>hadoop.security.authentication</name>
  <value>simple</value>
</property>

例

hadoop kdiag \
  --nofail \
  --resource hdfs-site.xml --resource yarn-site.xml \
  --keylen 1024 \
  --keytab zk.service.keytab --principal zookeeper/devix.example.org@REALM

これは、早期に失敗することなくすべての診断を実行し、HDFS および YARN XML リソースをロードし、最小キー長を 1024 バイトとし、プリンシパル zookeeper/devix.example.org@REALM としてログインを試みます。キーは keytab zk.service.keytab にある必要があります。