このドキュメントでは、サービスレジストリにセキュリティがどのように実装されているかについて説明します。
Kerberosが有効になっていないHadoopクラスターでは、レジストリはまったくセキュリティを提供しません。レジストリは全世界で書き込み可能です。
したがって、このドキュメントは、セキュアなクラスターにのみ関連します。
レジストリのセキュリティモデルは、セキュアなレジストリとして次の目標を満たすように設計されています。1. セキュアなZKインストールで機能的なセキュリティを提供します。2. RMが登録スペースのユーザーごとの領域を作成できるようにします。3. ユーザーに属するアプリケーションが、スペース内の自身の部分にレジストリエントリを書き込めるようにします。これらは、短命または長命のYARNアプリケーションである場合もあれば、静的なアプリケーションである場合もあります。4. 他のユーザーが別のユーザーのレジストリの一部に書き込むのを防ぎます。5. システムサービスがレジストリの/servicesセクションに登録できるようにします。6. レジストリのクライアントに読み取りアクセスを提供します。7. 将来のDNSのサポートを許可します。8. 将来のユーザーにプライベートなデータの登録のサポートを許可します。これにより、サービスはクライアントが使用するバインディング認証情報（キーなど）を公開できます。9. YARNクラスター内のすべてのユーザーのホームディレクトリにZKキータブを必要としないようにします。これは、Kerberos認証情報をYARNアプリケーションで使用できないことを意味します。
ZKセキュリティは、ZookeeperとSASLで文書化されているACLモデルを使用します。このモデルでは、さまざまな認証スキームを使用して、さまざまなznodeへのアクセスを制限できます。これにより、レジストリは、混合Kerberos +プライベートパスワードモデルを使用できます。
RMRegistryOperationsService）は、YARN自体の認証メカニズムとしてKerberosを使用します。(ユーザー名、パスワード)キーペアで作成されます。このようなスキームの制限は何ですか？
レジストリマネージャーは、クライアントが一貫してZKアクセス許可を設定することに依存できません。少なくとも、システムサービスのアカウントに対するクライアントアプリケーションの意図しない誤った値に依存することはできません。
解決策：最初は、レジストリのアクセス許可がここで使用されます。
Kerberosドメインでは、Kerberos化されたクライアントが、YARNまたはHDFSとの通信に使用されるローカルユーザーのKerberos認証情報から、実行時にクラスターのレルムを判断することができます。
これは、システムアカウントの正しいレルムを持つアカウント名を自動生成するために使用でき、したがって、有効な定数を取得するのに役立ちます。
これにより、レジストリはhadoop.registry.system.accountsのデフォルト構成値をサポートできます。
"sasl:yarn@, sasl:mapred@, sasl:hdfs@, sasl:hadoop@";
別の戦略として、レジストリのルートに、実際にはレジストリを定義するServiceRecord（dataフィールドにこれらのデフォルトのバインディング値をリストすることを含む）を持たせることもできます。
（おそらくRM）がユーザーのレジストリの部分をスキャンし、いくつかのACLの問題を検出する可能性があります。IP/世界アクセスが緩すぎる、管理者アカウントの設定が間違っている。ただし、ADMINアクセス許可がない限り、ACLアクセス許可を表示または修正することはできませんが、少なくともその状況は検出できます。RMはスタックの上位にDELETEアクセス許可を持っている必要があるため、誤ったツリーの部分を削除できる立場にあります。ただし、これは破壊的な過剰反応である可能性があります。