This documentation is for an unreleased version of Apache Flink. We recommend you use the latest stable version.

移譲トークン #

このドキュメントは、Flinkで使われる移譲トークンを説明し、分かりやすくすることを目的としています。詳細に入る前に、高レベルのアーキテクチャー図を次に示します:

移譲トークンとは何ですか？どうしてそれを使うのですか？ #

移譲トークン(これ以降はDT)は、一部のサービスで有効期間の長い資格情報を置き換えるために使われる認証トークンです。 long-lived credentials. Hadoopエコシステムの多くのサービスはDTをサポートしています。有効期間の長い資格情報に比べて、非常に望ましい利点がいくつかあります。

有効期間の長い資格情報を配布する必要がない #

分散アプリケーションでは、有効期間の長い資格情報を配布するのは困難です。さらに、悪意のある攻撃者にとって追加の攻撃対象になるため、全てのユーザがアプリケーションデータの一部としてネットワーク経由で配布することを望んでいるわけではありません。

DTs allow for a single place e.g. the JobManager (JM from now on) to require long-lived credentials. That entity can then distribute the DTs to other parts of the distributed application e.g. TaskManagers (TM from now on), so they can authenticate to services.

認証には、サービスごとに1つのトークンが使われます。 #

Kerberos認証が使われた場合、各クライアントがサーバに接続するたびに、キー配布センター(KDC)にアクセスして、サービスチケットを生成する必要があります。分散システムでは、クライアントプロセス(例えば、TMs)の数とサービスプロセス(例えば、HDFSデータノード)の数の積に比例して、サービスチケットの数が急速に膨れ上がる可能性があります。これにより、KDCに不必要な余分な負荷が発生し、KDC管理者が設定した使用制限に達する可能性もあります。

移譲トークンは認証にのみ使われます。 #

有効期間の長い資格情報と異なり、DTsは発行された特定のサービスに対する認証にのみ使えます。既存のDTを使って新しいDTsを作成したり、別のサービス用のDTsを作成することはできません。

つまり、DTsは有効期間の長い資格情報ではありません。これらは、(おそらく実装の詳細を除けば)認証の仕組みに結び付けるものは何もありませんが、Kerberos認証や他の形式の認証を置き換えるために多くのサービスで使われます。

移譲トークンのライフサイクル #

DTは、一部の有効期間の長い資格情報と異なり、サービス固有です。サービスのDTを作成するために連絡する集中的な場所はありません。ですので、DTを取得するために必要な最初のステップは、該当のサービスに認証できるようにすることです。Hadoopエコシステムでは、これは一般的にKerberosを使って行われます。

これには、アプリケーションが付ける場所で有効期限が長い資格情報を利用できる必要があります。ユーザは通常これらの資格情報を提供する責任があります。これには、KDCにログインすることで(例えば、kinitを使って)行われるのが最も一般的です。これは、チケット付与チケット(TGT)を含む"資格情報キャッシュ"が生成され、これを使ってサービスチケットをリクエストできます。

TGTを取得する方法は他にもありますが、最終的にはプロセスをブートストラップするためにTGTが必要になります。

TGTが利用可能になると、ターゲットサービスのクライアントライブラリを使ってサービスに対する認証を行い、移譲トークンの作成を要求できます。このトークンを他のプロセスに送信し、そのサービスに属する様々なデーモンの認証に使えるようになります。したがって、DTの最初の欠点が明らかになります: DTを作成して使うには、サービス固有のロジックが必要です。

Flinkは(ある程度)プラグイン可能な内部DT作成APIを実装しています。新しいサービスのサポートは、アプリケーションの移譲トークンを生成する時に移譲トークンマネージャーいよって呼び出されるDelegationTokenProviderを実装することで追加できます。

作成されると、DTの操作方法のセマンティクスもサービス固有になります。ただし、一般手金はKurberosトークンのセマンティクスに従おうとします。

“更新可能期間” (TGTの"lifetime"に相当)は、DTが更新されるまでの有効期間を表します。
“最大の生存期間” (TGTの"更新可能な生存期間に相当)は、DTが更新されるまでの有効期間を表します。

トークンが"最大有効期限"に達すると、適切なサービスに連絡して、上記のプロセスを再起動して, 新しいトークンを作成する必要があります。

移譲トークンの更新と更新者 #

これはDT処理の最も分かりにくい部分であり、その原因の1つはシステムの多くが他のサービスや仕組みにも拡張されているにも関わらず、Apache Hadoop YARNを念頭に置いて設計されているためです。

上記のように、DTは最終的に有効期限が切れるまで定期的に更新する必要があります。この例は、HDFSサービスのデフォルト設定です: 移譲トークンは最大7日間有効で、24時間ごとに更新する必要があります。トークンが更新されないまま24時間が経過すると、トークンはもう使用できません。7日を過ぎるとトークンはもう更新できなくなります。

これにより、だれがトークンを更新するのか？という疑問が生じます。そして長い間その答えはYARNでした。

YARNアプリケーションが送信されると、DTのセットも一緒に送信されます。YARNは(UserGroupInformation APIによって設定された規則を使って)これらのトークンをコンテナに配布し、アプリの実行中にトークンを更新し続けます。これらのトークンはアプリケーションによって使われるだけでなく、ログの収集や集計などの機能を実装するためにYARN自身によっても使われます。

ただし、これにはいくつかの注意点があります。

誰がトークンを更新しますか？ #

YARNの場合、これはHadoopライブラリによってほとんど透過的に処理されます。一部のサービスにはトークン"更新者"の概念があります。この"更新者"は、DTを更新することができるサービスプリンシパルの名前です。YARNに送信する場合、それがYARNサービスを実行しているプリンシパルになります。つまり、クライアントアプリケーションはその情報を知る必要があります。

その他のリソースマネージャーの場合、更新を行うサービスがないため、更新者はほとんど問題ありません。

どのトークンが更新されますか？ #

おそらくこれが一番大きな注意点です。

前のセクションで説明したように、DTはサービス固有で、作成と更新にはサービス固有のライブラリが必要です。これは、YARNがアプリケーショントークンを更新できることを意味し、YARNは次のものを必要とします:

アプリケーションが使っている全てのサービスのクライアントライブラリ
アプリケーションが使っているサービスに接続している方法に関する情報
そららのサービスに接続するための権限

ただし、実際には、ほとんどの場合、YARNは単一のHDFSクラスタにアクセスし、それがそのDTの更新機能の範囲になります。YARNに送信されたその他のトークンはコンテナに配布されますが、更新はされません。

これは、他のコードがトークンんを更新しない限り、これらのトークンは最大有効期限の前に期限切れになることを意味します。

また、全てのクライアントライブラリがトークンの更新を実装しているわけではありません。Flinkでサポートされているサービスの例を使うと、HBaseトークンのrenew()メソッドは何も行われません。したがって、HBaseトークンを"更新"する唯一の方法は新しいトークンを作成することです。

トークンが永久に期限切れになった場合はなにが起きるのか？ #

最後の注意点は、更新に関係なくDTには最大有効期限があるということです。そして、その期限が過ぎたら、サービスに接続できるようにするために新しいトークンを作成する必要があります。つまり、移譲トークン無しでサービスに接続できる必要があり、そのためDTとは別になんらかの形式の認証が必要になります。

これは監視無しで実行される長時間実行アプリケーションにとって特に重要です。数日ごとに誰かがログインしてパスワードを入力しなくても、作業を継続できなければなりません。

移譲トークンの更新 #

上記で説明した問題のため、Flinkは更新を行う別の方法を実装しています。The 解決策は妥協です: これは最小公倍数、つまり実際のトークン更新をサポートしていないHBaseのようなサービスを対象としています。次の例では、Hadoopエコシステムコンポーネントを全ての基盤をカバーするために強調表示することで議論を進めることがよくあります。これはHadoopエコシステムはAWS S3のような他のコンポーネントと比較して認証の観点からより複雑になる傾向があるからです。

Flinkでは、DTの"更新"は、アプリケーションに有効期限が長い資格情報(keytab)を与えることによって有効になります。 keytabは、プレーンテキストに書き込まれたKerberosパスワードと同等です。そのため、非常に機密性が高くなります: 誰かがそのkeytabファイルを入手できた場合、keytabに格納されている資格情報がKDCで有効な限り、そのユーザと任意のサービスに対して認証できます。

keytabを持つことにより、Flinkは有効なKerberous TGTを無期限に維持できます。

有効期間の長い認証情報が利用可能なため、Flinkは古いサービスの有効期限が切れると、設定されたサービス用に新しいDTsを作成します。従って、Flinkは前のセクションで説明したようにトークンを更新しません: 代わりに更新間隔ごとに新しいトークンを作成し、それらのトークンをMTに配布します。

これには、HBaseなどのサービスのサポートに加えて、外部更新サービス(YARNなど)への依存関係が無くなるという別の利点もあります。こうすることで、アプリケーションに長期間有効な資格情報がある限り、Flinkの更新時機能をKubernetesなどのDTに対応しないリソースマネージャーで使えます。

移譲トークンとProxyユーザ #

“Proxy users"はHadoop用語で偽装のことです。これにより、サービスで許可されている場合、ユーザAがサービスに接続する時にユーザBになりすますことができます。

Flinkはアプリケーションを送信する際のなりすましを許可していません。Sparkは偽装をサポートしますが、トークンの更新は許可していません。 but doesn’t allow token renewal. Flinkは主にストリーミングワークロード用に設計されているため、この機能を追加してもあまりメリットはありません。

外部で生成された移譲トークン #

FlinkはUserGroupInformation (UGI) APIを使ってHadoop資格情報を管理します。これは、FlinkがファイルからDTsを自動的にロードする機能を継承していることを意味します。Hadoopクラスは、HADOOP_TOKEN_FILE_LOCATION環境変数が定義されている場合、それが指すトークンキャッシュをロードします。

この機能は主に、ユーザに代わってワークロードを開始するサービスによって使われます。通常のユーザは、Flinkの外部でトークンを取得する方法を理解する必要があるため、この機能を使うことはほとんどありません。

Flink自体がDTを取得できることに注意してください。UGIが特定のサービスのDTを含み、Flinkがそのサービス用のトークンを取得するように設定されている場合、トークンが最初にロードｓれ、Flinkのロードの仕組みによって上書きされます。

移譲トークンサポートの制限 #

DTsについて話す時には、留意すべき特定の制限があります。

全てのDTが実際に更新期間を公開しているわけではありません。これは、通常はクライアントに公開されないサービス設定です。このため、一部のDTプロバイダでは更新期間を提供できません。したがって、サービスの設定がその情報を提供する別のサービスと何らかの方法で同期されている必要があります。そもそもDTが必要な時に一般的に利用できるHDFSサービスは、この情報を提供するため、一般的にDTを使う全てのサービスが更新期間中にHDFSと同じ設定を使うことをお勧めします。
Flinkはユーザアプリケーションコードを解析しないため、どの移譲トークンが必要になるか分かりません。つまり、Flinkが利用可能な設定に基づいて可能な限り多くの移譲トークンを取得しようとすることを意味します。つまり、HBaseトークンプロバイダが有効になっているが、アプリが実際にはHBaseを使っていないため、DTがまだ生成されます。その場合、ユーザは前述のプロバイダを明示的に無効にする必要があります。
DTを"オンデマンド"で作成するのは困難です。Flinkはトークンを事前に取得/配布し、定期的い再取得/再配布します。ただし、適切な設定が利用可能な場合、FlinkはDTを透過的に処理するため、ユーザコードがDTについて心配する必要がないという利点があります。
同じサービスに対して二勝を行う外部システムプラグインがあります。良い例の1つは、s3-hadoopとs3-prestoです。どちらもS3に対して認証されます。サービス名は異なりますが、同じサービスのトークンを取得しているため、意図しない結果が生じる可能性があります。同じサービスのトークンを取得しているため、これらのトークンは同じ場所に格納されます。同じ資格情報を一緒に使う場合、トークンはシングルスレッド方式(単一ユーザに属する)で相互に上書きされるため、問題がないことは簡単に分かります。たあし、プラグインが異なるユーザ資格情報で設定されている場合、データ処理用のトークンは、非決定論的な任意のユーザに属する可能性があります。