本文档介绍了如何在服务注册表中实现安全性
在未启用 Kerberos 的 Hadoop 集群中，注册表根本不提供任何安全性：注册表对所有人可写。
因此，本文档仅与安全集群相关。
注册表的安全性模型旨在满足安全注册表的以下目标：1. 在安全的 ZK 安装上提供功能性安全性。1. 允许 RM 为注册空间创建按用户划分的区域 1. 允许属于用户的应用程序将注册表条目写入到其空间部分。这些可能是短期的或长期的 YARN 应用程序，或者可能是静态应用程序。1. 阻止其他用户写入其他用户的注册表部分。1. 允许系统服务注册到注册表的 /services 部分。1. 为注册表的客户端提供读取访问权限。1. 允许将来支持 DNS 1. 允许将来支持注册对用户私有的数据。这允许服务发布绑定凭据（密钥等），以便客户端使用。1. 不需要在 YARN 集群中每个用户的 home 目录上使用 ZK 密钥表。这意味着 YARN 应用程序无法使用 kerberos 凭据。
ZK 安全性使用 ACL 模型，在 Zookeeper 和 SASL 中记录。其中，可以使用不同的身份验证方案来限制对不同 znode 的访问。这允许注册表使用混合 Kerberos + 私有密码模型。
RMRegistryOperationsService）使用 Kerberos 作为 YARN 本身的认证机制。(username,password) 密钥对创建。这种方案有什么限制？
注册表管理器不能依赖于客户端始终设置 ZK 权限。至少，他们不能依赖于客户端应用程序为系统服务的帐户错误地传递无意的值
解决方案：最初，这里使用注册表权限。
在 Kerberos 域中，Kerberos 客户端可以从本地用户的 Kerberos 凭据（用于与 YARN 或 HDFS 通信）中确定集群的领域。
这可用于为系统帐户自动生成具有正确领域的帐户名称，从而有助于获得有效常量。
这允许注册表支持 hadoop.registry.system.accounts 的默认配置值
"sasl:yarn@, sasl:mapred@, sasl:hdfs@, sasl:hadoop@";
另一种策略是在注册表的根目录中有一个 ServiceRecord，该记录实际上定义了注册表，包括在 data 字段中列出那些默认绑定值。
某些内容（可能是 RM）可以扫描用户部分的注册表并检测到一些 ACL 问题：IP/world 访问过于宽松，管理员帐户设置错误。它无法查看或修复 ACL 权限，除非它具有 ADMIN 权限，但至少可以检测到这种情况。鉴于 RM 必须在堆栈中进一步向上具有 DELETE 权限，因此它将能够删除树的错误部分，尽管这可能是一种破坏性的过度反应。