2017年10月30日に開催されたNTTデータ テクノロジーカンファレンス2017での講演資料です。 Apache Hadoopの未来 3系になって何が変わるのか? Introduction of Apache Hadoop security isssue and Hitchhiker Erasure Coding algorithm

1. 1
© 2017 NTT DATA Corporation
株式会社NTTデータ
鯵坂 明
2017/10/30 NTTデータ テクノロジーカンファレンス2017
Apache Hadoopの未来
3系になって何が変わるのか?

2. 2
 鯵坂 明 (Akira Ajisaka, @ajis_ka)
 Hadoopと関わり続けて6年が経過
 Hadoopの新機能や、関連するミドルウェアの検証
 プロジェクトへの技術支援
 サポートサービス
 Apache Hadoop committer, PMC member
 Java9がリリースされたので、対応中
 JUnitやLog4Jのアップデートに苦戦
 10年物のコードを直すことも
自己紹介
コミッタ選出
リリース投票
ブランド管理
ライセンス管理
など

3. 3
先月に、10年前から残っていたバグを直した

4. 4
Apache Hadoop 3のリリースが近い
20142011 20132012 2015
2.2.0
2.3.0
2.4.02.0.0-alpha
2.1.0-beta
0.23.0
0.23.11(final)
NameNode Federation, YARN
NameNode HA
HDFS Snapshots
NFSv3 support
Windows
Heterogeneous storage
HDFS in-memory caching
HDFS ACLs
HDFS Rolling Upgrades
Application History Server
RM Automatic Failover
2.5.0
2.6.0
YARN Rolling Upgrades
Transparent Encryption
Archival Storage
2.7.0
Drop JDK6 support
Truncate API
2016
branch-0.23
branch-2
trunk
Hadoop2
Hadoop3
2017
2.8.0
3.0.0-alpha1 3.0.0-beta1
HDFS caller context
S3A improvement
Support Azure Data Lake
3.0.0-alpha4

5. 5
Hadoop 3で大きく変わるポイント
 HDFS Erasure Coding
 YARN Timeline Service v.2
 Shell script rewrite
 Shaded client jars
 MapReduce task-level native optimization
 Intra-datanode balancer
 HDFS Router-Based Federation
 ・・・
全ては紹介しきれない
Apache Hadoop 3で変わること

6. 6
技術的に面白く、世の中に情報が出ていない話を2つ紹介
 YARN NodeManagerの脆弱性について
 脆弱性修正の裏側を話せる範囲で紹介
 先進的研究成果の取り込みについて
 Hitchiker erasure codingの紹介
今回は技術的に面白い話がしたい

7. 7
技術的に面白く、世の中に情報が出ていない話を2つ紹介
 YARN NodeManagerの脆弱性について
 脆弱性修正の裏側を話せる範囲で紹介
 先進的研究成果の取り込みについて
 Hitchiker erasure codingの紹介
今回は技術的に面白い話がしたい

8. 8
すでに修正済かつ公になっているYARN NodeManagerの脆弱
性について、以下の流れで説明
 脆弱性の内容
 詳細解説
 脆弱性の修正・公表
 脆弱性の修正によるトラブルとその対策
まえがき

9. 9
CVE-2016-3086: Apache Hadoop YARN NodeMangaer
vulnerability
今回紹介する脆弱性の内容
The YARN NodeManager in Apache Hadoop 2.6.x before 2.6.5
and 2.7.x before 2.7.3 can leak the password for credential store
provider used by the NodeManager to YARN Applications.
If you use the CredentialProvider feature to encrypt passwords
used in NodeManager configs, it may be possible for any
Container launched by that NodeManager to gain access to the
encryption password. The other passwords themselves are not
directly exposed.
http://mail-archives.apache.org/mod_mbox/hadoop-general/201701.mbox/%3C0ed32746-5a53-9051-5877-2b1abd88beb6%40apache.org%3E

10. 10
sensitiveな情報を保存するための、Hadoopの機能
例: Hadoopで実行するジョブでS3にアクセスする
 AWS(IAM)のaccess key/secret keyが必要
 core-site.xmlに記載するのが最もシンプル
 ただし、ジョブの設定に残るため、HistoryServerから
keyが見えてしまう
こういった問題を避けたい場合に利用する
Credential Providerとは

11. 11
HDFSの/user/ajisakaa/s3.jceksに情報を保存
S3を利用するDistCpの実行
Credential Providerを利用してS3にアクセスする
$ hadoop credential create s3a.access.key -value 123 -provider
jceks://hdfs@nn1.example.com/user/ajisaka/s3.jceks
$ hadoop credential create s3a.secret.key -value 456 -provider
jceks://hdfs@nn1.example.com/user/ajisaka/s3.jceks
$ hadoop distcp -D
hadoop.security.credential.provider.path=jceks://hdfs@nn1.exampl
e.com/user/ajisaka/s3.jceks /user/ajisaka/backup/ s3a://ajisaka-
backup/

12. 12
jceksファイル: Java keystoreの実装
 暗号化されているが、keystoreのパスワードが判明すれば
ツールで読み書き可能
 keystoreのパスワードは設定しなくてもよい
 keystoreへのアクセス制御がなされていれば問題ない
 パスワードを設定する場合、以下のいずれかの方法で
Hadoopクラスタ内でパスワードを共有・同期する
 環境変数HADOOP_CREDSTORE_PASSWORDに記載
 password fileを利用
Credential Providerの設定

13. 13
通常の設定の取得 (Configuration.java)
keystoreに保存した設定の取得 (Configuration.java)
S3AFileSystemの場合 (S3AUtils#getAWSAccessKeys)
keystoreに保存した設定の取得
public String get(String name) {
public char[] getPassword(String name) throws IOException {
String accesskey = getPassword(c, ACCESS_KEY,
login.getUser());
String secretKey = getPassword(c, SECRET_KEY,
login.getPassword());

14. 14
HDFS
イラストでわかる攻撃手法 (1/3)
NodeManager
YARN container
YARN Applicationを起動
Keystore

15. 15
HDFS
イラストでわかる攻撃手法 (2/3)
NodeManager
YARN container
containerの環境変数
HADOOP_CREDSTORE_
PASSWORDを取得
→ NodeManagerの
環境変数と一致 Keystore

16. 16
HDFS
イラストでわかる攻撃手法 (3/3)
NodeManager
YARN container
Keystoreへのアクセス
制御が充分でない場合、
手に入れた環境変数
をパスワードとして
Keystoreにアクセス可能 Keystore

17. 17
以下の全項目を満たす場合のみ、攻撃可能
 2.6.0～2.6.4, 2.7.0～2.7.2のいずれかを利用
 Credential Providerを利用
 NodeManagerの環境変数
HADOOP_CREDSTORE_PASSWORDにkeystoreのパスワー
ドを設定
 NodeManagerが利用するkeystoreが攻撃者から読み取れ
る状態になっている
Kerberos認証はもちろん有効ですよね?
攻撃成功の必要十分条件

18. 18
Shell.java
YARN containerがNodeManagerの環境変数を引き継がない
ように、環境変数を消去する
脆弱性修正の方針
+ // Remove all env vars from the Builder to prevent
+ // leaking of env vars from the parent process.
+ if (!inheritParentEnv) {
+ builder.environment().clear();
+ }

19. 19
HDFS
イラストでわかる攻撃手法 (2/3) (脆弱性修正後)
NodeManager
YARN container
containerの環境変数
HADOOP_CREDSTORE_
PASSWORDを取得
→ NodeManagerの
環境変数と一致しない Keystore

20. 20
本修正のコミットログ
通常のコミットには、JIRAのissue idが記載されている
脆弱性修正のコミットには、対応するJIRAがない
commit 9d4d30243b0fc9630da51a2c17b543ef671d035c
Author: Robert Kanter <rkanter@apache.org>
Date: Thu Apr 28 19:24:38 2016 -0700
Remove parent's env vars from child processes
commit 07694fc65ae6d97a430a7dd67a6277e5795c321f
Author: Akira Ajisaka <aajisaka@apache.org>
Date: Wed Aug 9 13:20:03 2017 +0900
HADOOP-14355. Update maven-war-plugin to 3.1.0.

21. 21
ASF Project Security for Committers
https://www.apache.org/security/committers.html
脆弱性の修正と悟られないようにしている
9. The project team agrees the fix on their private list.
12. The project team commits the fix. No reference
should be made to the commit being related to a
security vulnerability.

22. 22
ASF Project Security for Committers
https://www.apache.org/security/committers.html
脆弱性の公表は、修正されたリリースが出た後
15.The project team announces the vulnerability. The
vulnerability announcement should be sent after, or at
the same time as, the release announcement to the
following destinations:
a. the same destinations as the release announcement
b. the vulnerability reporter
c. the project's security list
*snip*

23. 23
CVEの公表

24. 24
修正後、3系でMapReduceジョブが失敗するようになった
2016-12-02 04:54:52,413 INFO mapreduce.Job: Job
job_1480654443168_0001 failed with state FAILED due to: Application
application_1480654443168_0001 failed 2 times due to AM Container
for appattempt_1480654443168_0001_000002 exited with exitCode: 1
Failing this attempt.Diagnostics: Exception from container-launch.
Container id: container_1480654443168_0001_02_000001
Exit code: 1
Stack trace: ExitCodeException exitCode=1:
at org.apache.hadoop.util.Shell.runCommand(Shell.java:974)
at org.apache.hadoop.util.Shell.run(Shell.java:878)
at
org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.jav
a:1172)
(snip)

25. 25
YARNコンテナが利用可能なNodeManagerの環境変数一覧に
赤字の部分を追加
MAPREDUCE-6704で、これがドキュメント化された
MapReduceジョブを実行するためには追加設定が必要
<property name="yarn.nodemanager.env-whitelist"
value="="JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HAD
OOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,
HADOOP_MAPRED_HOME"/>

26. 26
MAPREDUCE-6704での議論を抜粋
 *snip* since its a mapreduce property its not correct to
add to the whitelist to yarn.
 Who cares? It's all Apache Hadoop. Users have an
expectation that this stuff will work out of the box and
be consistent. *snip*
 There was pushback to remove it because of the
desire to keep Yarn and MR separate.
補足: HADOOP_MAPRED_HOMEの追加がデフォルトにならない理由

27. 27
2系では、HADOOP_CREDSTORE_PASSWORDのみ消去
 そのため、3系のようにMapReduceを動作させるための追加
設定は不要
2系では互換性を考慮した修正がなされている
+ // Remove all env vars from the Builder to prevent
+ // leaking of env vars from the parent process.
+ if (!inheritParentEnv) {
+ // branch-2: Only do this for HADOOP_CREDSTORE_PASSWORD
+ // (snip)
+ builder.environment().remove(
+ AbstractJavaKeyStoreProvider.CREDENTIAL_PASSWORD_NAME);
+ }

28. 28
技術的に面白く、世の中に情報が出ていない話を2つ紹介
 YARN NodeManagerの脆弱性について
 脆弱性修正の裏側を話せる範囲で紹介
 先進的研究成果の取り込みについて
 Hitchiker erasure codingの紹介
今回は技術的に面白い話がしたい

29. 29
http://www.cs.cmu.edu/~nihars/publications/Hitchhiker_SIGCOMM14.pdf
この論文を紹介します

30. 30
本論文のサマリ
Erasure Codingでは、data blockの欠損を復旧するために必要
なデータ量が多い
 RS(10,4)の場合、必要なデータは欠損したデータの10倍
この問題を回避するため、以下の3手法を提案
 Hitchhiker-XOR
 Hitchhiker-XOR+
 Hitchhiker-nonXOR
復旧に必要なデータ量を35%削減
今回はApache Hadoopで実装されているHitchhiker-XORを紹介

31. 31
Erasure Codingとは (簡単に)
 データをk個のdata unitに分割し、r個のparity unitを生成
 k+r個のunitのうち、任意のk個からデータを復旧可能
 parity生成にはReed-Solomon(RS)がよく利用される
 RS(k=10,r=4)の場合、実データの1.4倍のディスク消費
 HDFSの通常の3-replicationなら3倍
unit 1 unit 2 unit 3 unit 4 unit 5 unit 6 unit 7
unit 8 unit 9 unit 10 unit 11 unit 12 unit 13 unit 14

32. 32
Erasure Codingでの障害復旧における課題
例: unit 6故障時の復旧パターン
unit 1 unit 2 unit 3 unit 4 unit 5 unit 7
unit 8 unit 9 unit 10 unit 11 unit 12 unit 13 unit 14

33. 33
Erasure Codingでの障害復旧における課題
例: unit 6故障時の復旧パターン
任意の10 unitのデータを取得
unit 1 unit 2 unit 3 unit 4 unit 5 unit 7
unit 8 unit 9 unit 10 unit 11 unit 12 unit 13 unit 14
unit 1 unit 2 unit 3
unit 4 unit 5 unit 7
unit 8 unit 10 unit 12 unit 14

34. 34
例: unit 6故障時の復旧パターン
任意の10 unitのデータを取得
unit 6を生成
Erasure Codingでの障害復旧における課題
unit 1 unit 2 unit 3 unit 4 unit 5 unit 7
unit 8 unit 9 unit 10 unit 11 unit 12 unit 13 unit 14
unit 1 unit 2 unit 3
unit 4 unit 5 unit 7
unit 8 unit 10 unit 12 unit 14
unit 6

35. 35
例: unit 6故障時の復旧パターン
任意の10 unitのデータを取得
unit 6を生成
Erasure Codingでの障害復旧における課題
unit 1 unit 2 unit 3 unit 4 unit 5 unit 7
unit 8 unit 9 unit 10 unit 11 unit 12 unit 13 unit 14
unit 1 unit 2 unit 3
unit 4 unit 5 unit 7
unit 8 unit 10 unit 12 unit 14
unit 6
失ったデータの10倍の
データを読み込む必要がある！
(ディスク、NWに負荷)

36. 36
Hitchhiker-XOR
通常のRSに一工夫加える
a1 b1
...
...
a10 b10
f1(a) f1(b)
f2(a) f2(b)
f3(a) f3(b)
f4(a) f4(b)
1 byte 1 byte
unit 1
unit 10
unit 11
unit 12
unit 13
unit 14
...
a1 b1
...
...
a10 b10
f1(a) f1(b)
f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3
f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6
f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10
1 byte 1 byte
RS (10, 4) Hitchhiker-XOR for RS (10, 4)
元データ(a1, a2, ... , a10, b1, b2, ... , b10)

37. 37
Hitchhiker-XORでの障害復旧
例: unit 1の故障
unit 1
unit 10
unit 11
unit 12
unit 13
unit 14
...
a1 b1
...
...
a10 b10
f1(a) f1(b)
f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3
f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6
f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10
1 byte 1 byte

38. 38
Hitchhiker-XORでの障害復旧
例: unit 1の故障
b2～b10, f1(b)から
b1を復旧
unit 1
unit 10
unit 11
unit 12
unit 13
unit 14
...
a1 b1
...
...
a10 b10
f1(a) f1(b)
f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3
f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6
f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10
1 byte 1 byte
read
read
read

39. 39
Hitchhiker-XORでの障害復旧
例: unit 1の故障
b2～b10, f1(b)から
b1を復旧
b1～b10,
f2(b)⊕a1⊕a2⊕a3,
a2, a3から
a1を復旧
unit 1
unit 10
unit 11
unit 12
unit 13
unit 14
...
a1 b1
...
...
a10 b10
f1(a) f1(b)
f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3
f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6
f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10
1 byte 1 byte
read
read
read
read
a2, a3のみread

40. 40
Hitchhiker-XORでの障害復旧
例: unit 1の故障
b2～b10, f1(b)から
b1を復旧
b1～b10,
f2(b)⊕a1⊕a2⊕a3,
a2, a3から
a1を復旧
unit 1
unit 10
unit 11
unit 12
unit 13
unit 14
...
a1 b1
...
...
a10 b10
f1(a) f1(b)
f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3
f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6
f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10
1 byte 1 byte
read
read
read
read
a2, a3のみread
2bytesの復旧に13bytesで充分
RS(10, 4)だと20bytesなので、
35%のデータを削減

41. 41
Hitchhiker-XORの短所
単一障害に特化している
 2重障害の場合、復旧に必要なデータを削減できない
 Facebookによると、98.08%は単一障害なので問題はない
unit 7～10を復旧する場合、13ではなく14bytes必要
 これを13にするため、Hitchhiker-XOR+やnonXORがある
 詳しくは論文を読もう
 Apache Hadoopには現状実装されていない
unit 11～14を復旧する場合、20bytes必要
 仕方ない。諦める

42. 42
"Hop-and-Couple": ディスクI/O効率を高める工夫
単純に並べていくのは非効率
a1 b1
...
...
a10 b10
f1(a) f1(b)
f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3
f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6
f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10
c1 d1
...
...
c10 d10
f1(c) f1(d)
f2(c) f2(d) ⊕ c1 ⊕ c2 ⊕ c3
f3(c) f3(d) ⊕ c4 ⊕ c5 ⊕ c6
f4(c) f4(d) ⊕ c7 ⊕ c8 ⊕ c9 ⊕ c10

43. 43
"Hop-and-Couple": ディスクI/O効率を高める工夫
単純に並べていくのは非効率
 復旧時に1byteおきに読み込む必要がある
a1 b1
...
...
a10 b10
f1(a) f1(b)
f2(a) f2(b) ⊕ a1 ⊕ a2 ⊕ a3
f3(a) f3(b) ⊕ a4 ⊕ a5 ⊕ a6
f4(a) f4(b) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10
c1 d1
...
...
c10 d10
f1(c) f1(d)
f2(c) f2(d) ⊕ c1 ⊕ c2 ⊕ c3
f3(c) f3(d) ⊕ c4 ⊕ c5 ⊕ c6
f4(c) f4(d) ⊕ c7 ⊕ c8 ⊕ c9 ⊕ c10

44. 44
"Hop-and-Couple": ディスクI/O効率を高める工夫
シーケンシャルI/Oになるよう並べ替える
 下図は2byteおきだが、実際はもっと大きい値にする
a1 b1
...
...
a10 b10
f1(a) f1(b)
f2(a) f2(b)
f3(a) f3(b)
f4(a) f4(b)
c1 d1
...
...
c10 d10
f1(c) f1(d)
f2(c) ⊕ a1 ⊕ a2 ⊕ a3 f2(d) ⊕ b1 ⊕ b2 ⊕ b3
f3(c) ⊕ a4 ⊕ a5 ⊕ a6 f3(d) ⊕ b4 ⊕ b5 ⊕ b6
f4(c) ⊕ a7 ⊕ a8 ⊕ a9 ⊕ a10 f4(d) ⊕ b7 ⊕ b8 ⊕ b9 ⊕ b10

45. 45
数値実験の結果と考察
RSに比べ、エンコードは遅いが再構築は速い
 エンコード時間はおよそ72%増加
 単一障害時の再構築時間はおよそ35%減少
再構築の速度のほうが重視されるべき
 エンコード処理は1回きり、バックグラウンドで実行可
 再構築は何回でも起こる、読み込みのレイテンシに影響
ただし、この値をうのみにしてはいけない
 論文の実装とApache Hadoopの実装が同じとは限らない
 本当の値を知るには自分で試すべし

46. 46
今回のまとめ
YARN NodeManagerの脆弱性について
 脆弱性の修正および報告もコミッタおよびPMCの仕事
 本件の報告は私が担当
先進的研究成果の取り込みについて
 Hitchhiker-XOR以外でも、研究成果が次々と実装されている
 Mercury(USENIX 2015): YARN-2877で実装済
 Copysets(USENIX 2013): Ozone(HDFS-7240)で実装予定
 ソースコードだけではなく、論文を読むことも時として必要
Hadoop 3.1の話(特にOzone)については、次のソースコードリー
ディングなどで紹介したい

47. Copyright © 2017 NTT DATA Corporation
お問い合わせ先：
株式会社ＮＴＴデータ システム技術本部
OSSプロフェッショナルサービス
URL: https：//oss.nttdata.com/
メール： hadoop@kits.nttdata.co.jp TEL： 050-5546-9000

48. 48© 2017 NTT DATA Corporation
本資料中に記載されている会社名、商品名、ロゴは、各社の商標または登録商標です。