金融データ分析基盤の構築 - Hadoop（2）

ぷらっく

前回：


今回やること

  1. Hadoopの認証とセキュリティについての調査

  2. Kerberos認証サーバの構築

1. Hadoopの認証とセキュリティについての調査

Hadoopの認証についてはHadoopの公式ドキュメントの以下のようなページに記載されている。

  1. Hadoop in Secure Mode

  2. Service Level Authorization Guide

  3. Authentication for Hadoop HTTP web-consoles

1のページの概要では、Hadoopクラスタを外部に晒して運用する場合にはページ内に書いてある認証とアクセス制御をすることを強く推奨すると書いてある。認証ではKerberosという認証システムを用いる必要があるそう。

Hadoopクラスタのセキュリティに関して調べる前に、KerberosとDNSについての事前知識をある程度頭に入れておけとも書いてある。

Forward and reverse host lookup for all service hosts must be configured correctly to allow services to authenticate with each other. Host lookups may be configured using either DNS or /etc/hosts files. Working knowledge of Kerberos and DNS is recommended before attempting to configure Hadoop services in Secure Mode.

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

Kerberosとは

KerberosはWindows serverでも利用されている認証プロトコルであり、複数のサービスの認証を可能とするSSO（シングルサインオン）などの機能も提供している。また、サービスがクライアントの代わりにリソースなどへアクセスできるように委任認証の機能も備わっている。

Hadoopクラスタを外部に公開して運用する場合は、このKerberosを認証プロトコルとして利用してユーザの認証・認可・権限委任などを行うとドキュメントに記載されている。

Kerberos認証では以下のような要素が必要となる。

  1. KDC（Key Distribution Center）：認証情報を一元管理するデータベース

  2. AS（Authentication Server）：認証サーバ

  3. TGS（Ticket Granting Server）：サーバで利用できるチケット発行サーバ

  4. TGT（Ticket Granting Ticket）：チケット発行の元になるチケット？

  5. プリンシパル：KDCが管理するユーザ、サーバ

  6. レルム：KDCの配下のシステムをグループと定義する論理ネットワーク

DataNodeの認証

Hadoop RPCを利用した通信は基本的にKerberosで認証を行うことができるが、DataNodeがデータを転送するときはHadoop RPCを使わないらしい。その場合、以下の二つの方法で認証をすることができる。

  1. 特権ユーザ認証

  2. SASL（Hadoopバージョン2.6.0以降のみ）

1の特権ユーザの認証では、DataNodeのデーモンの起動の際に特権ユーザでコマンドを実行すると、初めに特権ポートにバインドをしてその後一般ユーザに降格する。それにより、攻撃者が特権ユーザになれない限りは、攻撃者がデータ転送を偽造したり盗聴したりすることが出来なくなる。

2のSASL（Simple Authentication and Security Layer）は、調べてみると既存のプロトコルを再利用しつつ認証や暗号化などの機構を加えるものとなっているらしい。今までDataNodeではHadoop RPCを利用しないためにKerberos認証を行うことが出来なかったが、SASLによってKerberos認証も利用できるようになったらしい。

SASLを有効にする方法は二つあり、一つはdfs.datanode.addressに非特権ポートを指定することで、もう一つはdfs.http.policyにHTTPS_ONLYを設定することだそう。先日構築したバージョン3.4.0ではそもそも特権ユーザでhdfsを起動していないことから、デフォルトでこのSASLになってるようだった（もしくは、認証自体がされない設定なのか）。

データ転送の暗号化

デフォルトでは、データ転送における暗号化は有効にされていないため、dfs.encrypt.data.transferをtrueに設定してあげる必要がある。また、dfs.encrypt.data.transfer.algorighmで3DESまたはRC4を選択することができる。

ドキュメントでは、それらに加えてdfs.encrypt.data.transfer.cipher.suitesの設定をして暗号化アルゴリズムにAESを有効化するように推奨している。鍵交換のアルゴリズムは引き続き3DESまたはRC4だが、通信の暗号化はAESを利用できるようになるらしい。

その中ではAESが暗号強度とパフォーマンスでもっとも良いが、現状では3DESとRC4が一般に使われているそう。

HDFS/ローカルファイルシステムの推奨される権限

HadoopクラスタのHDFSとマシンのローカルファイルにいくつか推奨されるユーザ、グループ、権限などが記載されていた。

ログや一時ファイルなどのディレクトリは775、データディレクトリなどは700で所有者のみになっている（hdfsユーザ以外は直接触らないためだと思う）。

2. Kerberos認証サーバの構築

Hadoopの認証についていくつか調べたが、どれも中核となるのはKerberos認証のシステムとなる。Kerberos認証には認証情報の管理や認証プロセスを担当するサーバが必要となるため、自宅のネットワーク内に立ててみる。正直個人で使う分には認証自体必要ないのだが、勉強のためにKerberos認証の構築もHadoopへの適用もやってみようと思う。

Kerberos認証サーバの構築は以下のページで手順が説明されている。今回は、PXEブート用のサーバを立てているUbuntu severのマシンに同居させる。

以下のコマンドでパッケージをインストールする。

sudo apt install krb5-admin-server krb5-kdc

インストール時に以下の質問がされるので適宜答える。

  1. REALM：HOME

  2. KDCサーバのホスト名：kdc.home

  3. 管理サーバのホスト名：kdc.home

REALMというのは、Kerberos認証で管轄する範囲を決めるもので、基本的にはドメインを大文字にしたものとなる。KDCサーバと管理サーバは小規模のネットワークでは同じマシンに同居させることが多く、KDCサーバは認証、管理サーバはKDCサーバの管理などを担当する。

sudo krb5_newrealm

そうしたら上のコマンドでKDCのデータベースを初期化する。これは更に上で指定したREALMのデータを初期化している。これを行うことでプリンシパル（ユーザやサービスなど）を作ることができるようになる。

一旦これでデーモンが正常に起動するようになり、マシンのポート（750, 88）にKDCサーバ、管理サーバがリッスンするようになる。

その後はプリンシパルをHadoopクラスタ用などに適切に作る。

次やること

  1. HadoopクラスタとKerberos認証の組み合わせ

  2. Hadoopクラスタでの認証ができているか検証する

個人で使う目的なら認証を書けずに、自宅の閉じたネットワーク内でHadoopクラスタを構築して外からはVPN接続するっていう感じが良さそう。だけど、企業で使う場合は認可が必須になると思うのでKerberos認証は理解しておきたい。

この記事が気に入ったらサポートをしてみませんか？