身份认证是 Ozone 组件识别用户身份的过程,Apache Ozone支持使用Kerberos和security tokens的强身份认证。
Ozone 依靠 Kerberos 来保证集群的安全,要在 Ozone 集群中启用安全,必须设置以下参数:
Property | Value |
---|---|
ozone.security.enabled | TRUE |
hadoop.security.authentication | kerberos |
下图说明了服务组件,例如 Ozone Manager (OM)、Storage Container Manager (SCM)、DataNode 和 Ozone Client,如何通过 Kerberos 相互进行身份认证:
每个服务都必须配置有效的 Kerberos Principal Name和相应的keytab文件,服务使用该文件在服务启动时以安全模式登录。 相应地,Ozone 客户端必须提供有效的 Kerberos ticket或security token才能访问 Ozone 服务,例如访问OM中的元数据或者读写DataNode中的block。
由于 Ozone 每秒处理数千个请求,每次通过 Kerberos 进行身份认证可能会造成负载过重且效率低下。 因此一旦身份认证完成,Ozone 就会向用户或客户端应用程序发出delegation和block token,以便他们可以对集群执行指定的操作,就好像他们拥有有效的 kerberos ticket一样。
当 OM 收到来自客户端的带有delegation token的请求时,它会通过使用其公钥检查签名来验证令牌。delegation token可以转移到其他客户端进程。 当令牌过期时,原始客户端必须请求新的delegation token,然后将其传递给其他客户端进程。delegation token操作:例如获取、更新和取消,只能通过 Kerberos 身份认证的连接执行。
Block token和delegation token类似,它们都是由OM发行/签名的。block token允许用户或客户端应用程序读取或写入 DataNode 中的block,与通过获取、更新或取消API请求的delegation token不同,block token透明地向客户端提供有关key或block位置的信息。当 DataNode 收到来自客户端的读/写请求时,DataNode 使用颁发者 (OM) 的证书或公钥来验证block token。客户端无法更新block token,当block token过期时,客户端必须检索key/block位置以获取新的block token。
Ozone 通过 Ozone S3 Gateway支持 Amazon S3 协议。在安全模式下,OM 向经过 Kerberos 身份验证的用户或使用 S3 API 访问 Ozone 的客户端应用程序颁发 S3 secret key。可以将access key ID secret添加到 Ozone 的 AWS 配置文件中,以确保特定用户或客户端应用程序可以访问 Ozone bucket。S3 token由 Amazon S3 客户端创建的 S3 secret keys进行签名,Ozone S3 gateway为每个 S3 客户端请求创建token。用户必须拥有 S3 secret key才能创建 S3 token,与block token类似,S3 token对客户端来说是透明处理的。
Ozone的安全使用基于证书的方法来验证安全令牌,这使得令牌更加安全,因为共享密钥永远不会通过网络传输。下图说明了 Ozone 安全令牌的工作原理:
在安全模式下,SCM 将自身引导为证书颁发机构 (certifying authority,CA),并创建自签名 CA 证书,OM 和 DataNode 必须通过证书签名请求 (Certificate Signing Request,CSR) 向 SCM CA 注册。SCM通过Kerberos验证OM和DataNode的身份并签署组件的证书,然后OM 和 DataNode 使用签名的证书来证明其身份,这对签名和验证delegation或block token。
对于block token,OM(token issuer,令牌发行者)使用其私钥对令牌进行签名,并且 DataNode(token validator,令牌验证者)使用 OM 的证书来验证block token,因为 OM 和 DataNode 信任 SCM CA 签名的证书。
对于delegation token,当 OM(既是令牌颁发者又是令牌验证者)在高可用性 (HA) 模式下运行时,有多个 OM 实例同时运行。当leader OM实例发生变化时,OM instance 2可以验证OM instance 1颁发和签名的delegation token,因为这两个实例都信任 SCM CA 签名的证书。
Ozone的服务例如Storage Container Manager(SCM)、Ozone Manager (OM) 和 DataNodes之间的身份验证是使用证书实现的,并确保 Ozone 集群中的安全通信。 证书由 SCM 在安装过程中颁发给其他服务。下图说明了 SCM 如何向其他 Ozone 服务颁发证书:
HA环境中的primordial SCM使用自签名证书启动根证书颁发机构 (Certificate Authority,CA),primordial SCM 向其自身以及其他bootstrapped SCM 颁发签名证书。primordial SCM 还有一个subordinate CA,具有来root CA 的签名证书。当 SCM 引导时(bootstrapped),它会从primordial SCM 接收签名证书并启动其自己的从属(subordinate) CA。 成为leader的任何 SCM 的从属 CA 都会向 Ozone 集群中的 Ozone Manager和 DataNode 颁发签名证书。
授权是指定对Ozone资源的访问权限的过程,用户通过身份验证后,授权能够指定用户可以在 Ozone 集群中执行哪些操作。 例如,允许用户读取卷、存储桶和key,同时限制他们创建卷。Ozone 支持通过 Apache Ranger 插件或原生的访问控制列表 (ACL) 进行授权。
Ozone 的原生ACL 可以独立使用,也可以与 Ozone ACL 插件(例如 Ranger)一起使用。 如果启用 Ranger 授权,则不会校验原生 ACL。Ozone原生ACL 是 POSIX 和 S3 的超集,ACL 的格式为object:who:rights
。
1.object,在 ACL 中,对象可以是以下内容:
2.who,在ACL中,who可以是以下内容:
3.rights,在ACL中,right可以是以下内容:
4.用于使用 Ozone ACL 的 API,Ozone 支持一组 API 来修改或操作 ACL,支持的API如下:
Apache Ranger 提供了一个集中式安全框架,通过用户界面管理访问控制,确保跨 Cloudera Data Platform (CDP) 组件进行一致的策略管理。使用Cloudera Manager可以方便的将Ranger和Ozone集成并使用,如果启用 Ranger 授权,则会忽略原生的ACL。下表列出了各种 Ozone 操作对应的 Ranger 权限:
Operation / Permission | Volume Permission | Bucket Permission | Key Permission |
---|---|---|---|
Create Volume | CREATE | ||
List Volume | LIST | ||
Get Volume Info | READ | ||
Delete Volume | DELETE | ||
Create Bucket | READ | CREATE | |
List Bucket | LIST, READ | ||
Get Bucket Info | READ | READ | |
Delete Bucket | READ | DELETE | |
List Key | READ | LIST, READ | |
Write Key | READ | READ | CREATE, WRITE |
Read Key | READ | READ | READ |