YARNアプリケーションセキュリティ

YARNアプリケーションへのトークンの取得と追加

YARNアプリケーションに必要な委任トークンは、認証されたユーザーとして実行されているプログラムから取得する必要があります。 YARNアプリケーションの場合、これはアプリケーションを起動するユーザーを意味します。これを行う必要があるのは、YARNアプリケーションのクライアント側部分です。

1. UserGroupInformationを介してログインします。
2. 取得する必要があるすべてのトークンを識別します。
3. これらのトークンを特定のHadoopサービスから要求します。
4. すべてのトークンをバイトバッファーにマーシャルします。
5. ApplicationSubmissionContext内のContainerLaunchContextに追加します。

どのトークンが必要ですか？通常、少なくともHDFSにアクセスするためのトークンが必要です。

アプリケーションは、対話する予定のすべてのファイルシステム（クラスタのメインFSを含む）から委任トークンを要求する必要があります。 FileSystem.addDelegationTokens(renewer, credentials)を使用してこれらを収集できます。これは、トークンを発行しないファイルシステム（Kerberos化されていないHDFSクラスタを含む）ではnoopです。

Apache HBaseやApache Hiveなどの他のサービスと通信するアプリケーションは、これらのサービスのライブラリを使用して委任トークンを取得し、これらのサービスからトークンを要求する必要があります。すべてのトークンを同じ認証情報のセットに追加してから、送信用にバイトバッファーに保存できます。

アプリケーションタイムラインサーバーも委任トークンが必要です。これは、AM起動時に自動的に処理されます。

AM内のトークンの抽出

アプリケーションマスターが起動され、ユーザーログインをトリガーするUGI/Hadoop操作のいずれかが呼び出されると、UGIクラスは、環境変数HADOOP_TOKEN_FILE_LOCATIONで名前が付けられたファイルに保存されているすべてのトークンを自動的にロードします。

これは、セキュアクラスタとともに非セキュアクラスタで、およびアプリケーションでkeytabが使用されている場合でもセキュアクラスタで発生します。なぜですか？ YARN RMでアプリケーションを認証するために必要なAM/RMトークンは、常にこの方法で提供されるためです。

これは、セキュアクラスタと非セキュアクラスタで比較的同様のワークフローがあることを意味します。

1. AMの起動中に、Kerberosにログインします。 UserGroupInformation.isSecurityEnabled()の呼び出しは、この操作をトリガーします。

2. UserGroupInformation.getCurrentUser().getCredentials()の呼び出しを通じて、現在のユーザーの認証情報を列挙します。

3. AMRMトークンをフィルタリングして、新しい認証情報のセットを作成します。非セキュアクラスタでは、認証情報のリストは空になります。セキュアクラスタでは、それらに含まれます

4. 起動するすべてのコンテナの認証情報を、この（空の場合もある）認証情報のリストに設定します。

5. 更新するトークンのフィルタリングされたリストが空でない場合は、それらを更新するスレッドを起動します。

トークンの更新

トークンは期限切れになります。つまり、有効期間が限られています。この有効期限を過ぎてトークンを使用したいアプリケーションは、トークンの有効期限が切れる前にトークンを更新する必要があります。

Hadoopは、必要な場合に委任トークン更新スレッドであるDelegationTokenRenewerを自動的に設定します。

AMRMトークンとタイムライントークン以外のすべてのトークンを更新するのは、アプリケーションの責任です。

異なる戦略は次のとおりです

1. トークンの更新が必要ないほどアプリケーションの有効期間が短いことに依存しないでください。有効期間が常に数分または数十​​分で測定できるアプリケーションの場合、これは実行可能な戦略です。

2. トークンを定期的に更新するために、バックグラウンドスレッド/Executorを起動します。これは、ほとんどのYARNアプリケーションが行うことです。

AM/RMトークンの更新

AM/RMトークンは自動的に更新されます。RMは、allocateメッセージ内で新しいトークンをAMに送信します。プロセスを確認するには、AMRMClientImplクラスを参照してください。AMコードはこのプロセスを気にする必要はありません

AM再起動時のトークン更新

アプリケーションがトークンを定期的に更新している場合でも、AMが失敗して再起動した場合、元のApplicationSubmissionContextから再起動されます。そこにあるトークンは期限切れになっている可能性があるため、他のサービスと通信するための認証情報を発行する前でさえ、ローカライズが失敗する可能性があります。

この問題はどのように解決されますか？ YARNリソースマネージャーは、必要な場合、ノードマネージャーの新しいトークンを取得します。

より正確には

1. ローカライズのためにRMからNMに渡されるトークンは、必要に応じて更新/更新されます。
2. アプリケーションで使用するためのアプリ起動コンテキスト内のトークンは、更新されません。つまり、古いHDFSトークンがある場合、そのトークンは更新されません。これは、Hive、HBaseなどのトークンにも当てはまります。
3. したがって、トークンの有効期限が切れた後のAMの再起動を回避するには、AMがNMにkeytabをローカライズさせるか、（何らかの形で）クライアントから新しいトークンが渡されるまでHDFSにアクセスしないようにする必要があります。

これは主に、長期稼働サービス（下記を参照）の問題です。

非管理型アプリケーションマスター

非管理型アプリケーションマスターは、RMおよびNMによって設定されたコンテナで起動されないため、起動時にAM/RMトークンを自動的に取得できません。 YarnClient.getAMRMToken()APIを使用すると、非管理型AMはAM/RMトークンを要求できます。詳細については、UnmanagedAMLauncherを参照してください。

セキュアでないクラスタでのID: HADOOP_USER_NAME

セキュアでないクラスタでは、アプリケーションはノードマネージャーのアカウント（yarnやmapredなど）のIDとして実行されます。デフォルトでは、アプリケーションはHDFSにそのユーザーとしてアクセスし、異なるホームディレクトリを持ち、監査ログやファイルシステムの所有者属性では異なるユーザーとして識別されます。

これは、クライアントがアプリケーションが実行されるべきHDFS/HadoopユーザーのIDを識別することで回避できます。これはOSレベルのユーザーや、ローカルマシンに対するアプリケーションのアクセス権には影響しません。

Kerberosが無効になっている場合、Hadoopは最初に環境変数HADOOP_USER_NAMEから、次にOSレベルのユーザー名（例えば、システムプロパティuser.name）からユーザーのIDを取得します。

YARNアプリケーションは、この環境変数を設定することにより、アプリケーションを起動したユーザーのユーザー名を伝播する必要があります。

Map<String, String> env = new HashMap<>();
String userName = UserGroupInformation.getCurrentUser().getUserName();
env.put(UserGroupInformation.HADOOP_USER_NAME, userName);
containerLaunchContext.setEnvironment(env);

この環境変数は、hadoopライブラリを介してHDFSと通信するすべてのアプリケーションで取得されることに注意してください。つまり、設定されている場合、この環境変数が設定されているYARNコンテナの環境内で実行されるHBaseやその他のアプリケーションによって取得されるIDになります。

Oozieの統合とHADOOP_TOKEN_FILE_LOCATION

Apache Oozieは、関連するすべてのクレデンシャルを取得し、ローカルファイルシステムのファイルに保存してから、このファイルへのパスを環境変数HADOOP_TOKEN_FILE_LOCATIONに設定することにより、セキュアなクラスタでアプリケーションを起動できます。これはもちろん、YARNが起動されたコンテナに渡す環境変数と同じであり、同様の内容（クレデンシャルを含むバイト配列）が含まれます。

ただし、ここでは、環境変数はYARNクライアントを実行する環境に設定されます。このクライアントは、独自のトークンを取得する代わりに、指定されたファイルに保存されたトークン情報を使用する必要があります。

トークンファイルの読み込みは自動的に行われます。UGIがユーザーログイン時に行います。

クライアントは、同じクレデンシャルをAM起動コンテキストに渡す責任があります。これは、現在のクレデンシャルを渡すだけで簡単に行うことができます。

credentials = new Credentials(
    UserGroupInformation.getCurrentUser().getCredentials());

タイムラインサーバーの統合

アプリケーションタイムラインサーバーは、セキュアなサービスとしてデプロイできます。その場合、アプリケーションは認証のために関連するトークンが必要になります。このプロセスは、セキュアなクラスタでATSが有効になっている場合、YarnClientImplで自動的に処理されます。同様に、AM側のTimelineClient YARNサービスクラスは、ATSのSPNEGO認証されたREST APIを介してトークン更新を自動的に管理します。

Oozie経由でYARNアプリケーションを起動するために委任トークンのセットを準備する必要がある場合は、タイムラインクライアントAPIを介して行うことができます。

try(TimelineClient timelineClient = TimelineClient.createTimelineClient()) {
  timelineClient.init(conf);
  timelineClient.start();
  Token<TimelineDelegationTokenIdentifier> token =
      timelineClient.getDelegationToken(rmprincipal));
  credentials.addToken(token.getService(), token);
}

トークンのキャンセル

アプリケーションは、AMを終了するときに保持しているトークンをキャンセルする場合があります。これにより、トークンが無効になります。

これは必須ではなく、YARNアプリケーションの正常なシャットダウンは保証できないため、アプリケーションの終了時にトークンが常にキャンセルされることを保証することはできません。ただし、盗まれたトークンに対する脆弱性の期間を短縮します。

AMおよびコンテナ用の事前インストールされたKeytab

Keytabは、すべてのノードでのアプリケーションの使用のために提供されます。

これは、次の方法で行います。

1. すべてのクラスタノードのローカルファイルシステムにインストールします。
2. 構成オプションでこのパスを提供します。
3. UserGroupInformation.loginUserFromKeytab()を使用してクレデンシャルをロードするアプリケーション。

Keytabは、サービス（およびその他の信頼できるアカウント）のみが読み取ることができる安全なディレクトリパスにある必要があります。配布は、クラスタ運用チームの責任になります。

これは、事実上、すべての静的なHadoopアプリケーションがセキュリティクレデンシャルを取得する方法です。

YARN経由で配布されるAMおよびコンテナ用のKeytab

1. KeytabはHDFSにアップロードされます。

2. AMを起動するとき、KeytabはAMのコンテナにローカライズするリソースとしてリストされます。

3. Application Masterは、Keytabへの相対パスで構成され、UserGroupInformation.loginUserFromKeytab()でログインします。

4. AMがコンテナを起動するとき、KeytabへのHDFSパスをローカライズするリソースとしてリストします。

5. コンテナをローカライズできるように、HDFS委任トークンをコンテナ起動コンテキストに追加します。

6. 起動されたコンテナは、UserGroupInformation.loginUserFromKeytab()を介して自身でログインする必要があります。UGIがログインを処理し、バックグラウンドスレッドをスケジュールして、ユーザーを定期的に再ログインさせます。

7. トークンの作成は、Hadoop IPCおよびREST APIで自動的に処理され、コンテナはKerberosを介してその期間中ずっとログインしたままになります。

これにより、クラスタ全体で特定のサービスのKeytabをインストールする管理タスクを回避できます。

クライアントはKeytabにアクセスする必要があり、分散ファイルシステムにアップロードされるため、適切なパスパーミッション/ACLを介して保護する必要があります。

すべてのコンテナがKeytabにアクセスできるため、コンテナで実行されるすべてのコードは信頼できる必要があります。悪意のあるコード（または何らかの形式のサンドボックスを回避するコード）はKeytabを読み取ることができ、キーが期限切れになるか取り消されるまで、クラスタにアクセスできます。

これは、Apache Slider（incubating）によって実装されている戦略です。

YARN経由で配布されるAMのKeytab。AMはコンテナの委任トークンを再生成します。

1. KeytabはクライアントによってHDFSにアップロードされます。

2. AMを起動するとき、KeytabはAMのコンテナにローカライズするリソースとしてリストされます。

3. Application Masterは、Keytabへの相対パスで構成され、UserGroupInformation.loginUserFromKeytab()でログインします。UGIコードパスは、$HADOOP_TOKEN_FILE_LOCATIONで参照されるファイルも自動的にロードします。これがAMRMトークンが取得される方法です。

4. AMがコンテナを起動すると、そのコンテナに必要なすべての委任トークンを取得し、コンテナのコンテナ起動コンテキストに追加します。

5. 起動されたコンテナは、$HADOOP_TOKEN_FILE_LOCATIONから委任トークンをロードし、更新を含めて、更新できなくなるまでそれらを使用する必要があります。

6. AMは、コンテナが新しい委任トークンのセットを要求できるようにするIPCインターフェースを実装する必要があります。このインターフェース自体は、認証と、できれば有線暗号化を使用する必要があります。

7. 委任トークンが期限切れになる前に、コンテナで実行されているプロセスは、IPCチャネルを介してApplication Masterから新しいトークンを要求する必要があります。

8. コンテナが新しいトークンを必要とするとき、KeytabでログインしたAMは、さまざまなクラスタサービスに新しいトークンを要求します。

（更新操作には別の方向があることに注意してください。AMからコンテナへ、再びAMとコンテナの間で実装されているIPCチャネルを介してです）。アルゴリズムの残りの部分：AMで再生成されたトークンがIPCを介してコンテナに渡されます。

これは、Apache Spark 1.5以降で使用されている戦略で、トークン更新のためにコンテナとAMの間にnettyベースのプロトコルを使用しています。

AMのみがKeytabに直接アクセスできるため、露出が少なくなります。コンテナで実行されているコードは、委任トークンにのみアクセスできます。

ただし、これらのコンテナはコンテナ起動時に渡されたトークンからHDFSにアクセスできるようになり、AMの起動に使用されるKeytabのコピーにアクセスできるようになります。AMは起動時にそのKeytabを削除できますが、そうすると、YARNが障害後にAMを正常に再起動できなくなります。

クライアント側のトークンプッシュ

この戦略は、厳格な運用チームに受け入れられる唯一の戦略となる可能性があります。Kerberos TGTを保持するアカウントで実行されているクライアントプロセスは、必要なすべてのクラスタサービスと新しい委任トークンについてネゴシエートし、その後、何らかのRPCインターフェースを介してApplication Masterにプッシュされます。

これには、クライアントプロセスを定期的に再実行する必要があります。cronまたはOozieジョブでこれを行うことができます。AMは、更新されたトークンを提供できるIPC APIを実装する必要があります。（Oozieがトークン自体を収集できるため、実行されるたびにアップデーターアプリケーションが行う必要があるのは、AMとのIPC接続を設定し、現在のユーザーのクレデンシャルを渡すことだけであることに注意してください）。

クライアント

[ ] クライアントは、UserGroupInformation.isSecurityEnabled()を介してセキュリティが有効になっているかを確認します。

セキュアクラスターの場合

[ ] HADOOP_TOKEN_FILE_LOCATIONが設定されていない場合、クライアントはローカルファイルシステムの委任トークンを取得し、RMプリンシパルを更新者として設定します。

[ ] HADOOP_TOKEN_FILE_LOCATIONが設定されていない場合、クライアントはYARNアプリケーションで使用される他のすべてのサービスの委任トークンを取得します。

[ ] HADOOP_TOKEN_FILE_LOCATIONが設定されている場合、クライアントは、コンテナ起動コンテキストに追加するすべてのトークンのソースとして現在のユーザーの資格情報を使用します。

[ ] クライアントは、すべてのトークンをAMのContainerLaunchContext.setTokens()に設定します。

[ ] 推奨：クライアントの環境で設定されている場合は、クライアントはAMのコンテナ起動コンテキストで環境変数HADOOP_JAAS_DEBUG=trueを設定します。

非セキュアクラスターの場合

[ ] 環境変数HADOOP_USER_NAMEを介して、ローカルユーザー名をYARN AMに伝播し、それによってHDFS IDを伝播します。

アプリマスター

[ ] セキュアクラスターでは、AMはHADOOP_TOKEN_FILE_LOCATION環境変数からセキュリティトークンを取得します（UGIによって自動的に行われます）。

[ ] トークンセットのコピーは、AM/RMトークンとタイムライントークンを削除するようにフィルタリングされます。

[ ] スレッドを定期的に更新するために、スレッドまたはエグゼキューターが起動されます。

[ ] 推奨：アプリケーションが完了したら、AMはトークンをキャンセルします。

AMによるコンテナ起動

[ ] コンテナに渡されるトークンは、ContainerLaunchContext.setTokens()を介して渡されます。

[ ] 非セキュアクラスターでは、環境変数HADOOP_USER_NAMEを伝播します。

[ ] 推奨：AMの環境で設定されている場合、AMはコンテナ起動コンテキストで環境変数HADOOP_JAAS_DEBUG=trueを設定します。

起動されたコンテナ

[ ] セキュリティ設定をトリガーするには、UserGroupInformation.isSecurityEnabled()を呼び出します。

[ ] スレッドを定期的に更新するために、スレッドまたはエグゼキューターが起動されます。

YARNサービス

[ ] アプリケーション開発者は、トークン更新戦略（共有キータブ、AMキータブ、またはクライアント側のトークン更新）を選択して実装しました。

[ ] セキュアクラスターでは、キータブはすでにHDFSにある（そしてチェックされる）か、クライアントのローカルFSにあります。その場合、ローカライズするリソースのリストにアップロードして追加する必要があります。

[ ] HDFSに保存されている場合、キータブの権限をチェックする必要があります。キータブが現在のユーザー以外のプリンシパルによって読み取り可能な場合は、警告し、実際に起動に失敗することを検討してください（通常のsshアプリケーションと同様）。

[ ] クライアントはHDFS委任トークンを取得し、AMコンテナ起動コンテキストに添付します。

[ ] AMはloginUserFromKeytab()を介してキータブのプリンシパルとしてログインします。

[ ] （AMはHADOOP_TOKEN_FILE_LOCATION環境変数からAM/RMトークンを抽出します）。

[ ] 起動されたコンテナの場合、キータブが伝播されるか、AMは、NMに必要なHDFS委任トークンと一緒に、必要なすべての委任トークンを取得/添付します。