安全化 Ozone
Kerberos
Ozone 集群的安全依赖于 Kerberos。过去 HDFS 支持在隔离的安全网络中运行，因此可以不进行安全化的集群部署。
Ozone 在这方面与 HDFS 保持一致，但不久之后将 默认启用安全机制 。目前，Ozone 集群启用安全机制需要将配置 ozone.security.enabled 设置为 true ，以及将 hadoop.security.authentication 设置为 kerberos 。
| 参数 | 值 |
|---|---|
| ozone.security.enabled | true |
| hadoop.security.authentication | kerberos |
Tokens
Ozone 使用 token 的方法来防止 Kerberos 服务器负载过重，当每秒处理上千个请求时，Kerberos 可能无法很好地工作。所以，每次当用户完成一次认证之后，Ozone 会向用户颁发代理 token 和块 token，应用程序可以使用这些 token 来对集群进行特定的操作，就像它们持有 kerberos 凭据一样，Ozone 支持以下类型的 token。
代理 Token
代理 token 允许应用模拟用户的 kerberos 凭据，它基于 kerberos 的身份认证，由 OM 颁发，当集群启用安全机制时，代理 token 功能默认启用。
块 Token
用户通过块 token 来读写一个块，它的作用是让数据节点知道用户是否有对块进行读和修改的权限。
S3AuthInfo
S3 使用了一种不一样的共享秘密的安全机制，Ozone 支持 AWS Signature Version 4 协议，从用户的角度来看，Ozone 的 s3 感觉与 AWS S3 无异。
S3 token 功能在启用安全机制的情况下也默认开启。
Ozone 的每个服务进程都需要一个 Kerberos 服务主体名和对应的 kerberos keytab 文件。
ozone-site.xml 中应进行如下配置：
Storage Container Manager
SCM 需要两个 Kerberos 主体，以及两个对应的 keytab 文件。
| 配置 | 描述 |
|---|---|
| hdds.scm.kerberos.principal | SCM 服务主体，例如：scm/_HOST@REALM.COM |
| hdds.scm.kerberos.keytab.file | SCM 进程使用的 keytab 文件 |
| hdds.scm.http.auth.kerberos.principal | SCM http 服务主体（当 SCM http 服务器启用了 SPNEGO） |
| hdds.scm.http.auth.kerberos.keytab | SCM http 服务使用的 keytab 文件（当 SCM http 服务器启用了 SPNEGO） |
Ozone Manager
和 SCM 一样，OM 也需要两个 Kerberos 主体和对应的 keytab 文件。
| 配置 | 描述 |
|---|---|
| ozone.om.kerberos.principal | OM 服务主体，例如：om/_HOST@REALM.COM |
| ozone.om.kerberos.keytab.file | OM 进程使用的 keytab 文件 |
| ozone.om.http.auth.kerberos.principal | OM http 服务主体（当 OM http 服务器启用了 SPNEGO） |
| ozone.om.http.auth.kerberos.keytab | OM http 服务使用的 keytab 文件（当 OM http 服务器启用了 SPNEGO） |
S3 网关
S3 网关只需要一个服务主体，配置如下：
| 配置 | 描述 |
|---|---|
| ozone.s3g.kerberos.principal | S3 网关主体，例如：s3g/_HOST@REALM |
| ozone.s3g.kerberos.keytab.file | S3 网关使用的 keytab 文件，例如：/etc/security/keytabs/s3g.keytab |
| ozone.s3g.http.auth.kerberos.principal | S3 网关主体（当 S3 网关 http 服务器启用了 SPNEGO），例如：HTTP/_HOST@EXAMPLE.COM |
| ozone.s3g.http.auth.kerberos.keytab | S3 网关使用的 keytab 文件（当 S3 网关 http 服务器启用了 SPNEGO） |