- 动态与公告
- 产品简介
- 购买指南
- 快速入门
- 控制台指南
- 工具指南
- 最佳实践
- 开发者指南
- 数据湖存储
- 数据处理
- 故障处理
- API 文档
- 简介
- 公共请求头部
- 公共响应头部
- 错误码
- 请求签名
- 操作列表
- Service 接口
- Bucket 接口
- Object 接口
- 批量处理接口
- 数据处理接口
- 任务与工作流
- 内容审核接口
- 云查毒接口
- SDK 文档
- SDK 概览
- 准备工作
- Android SDK
- C SDK
- C++ SDK
- .NET(C#) SDK
- Flutter SDK
- Go SDK
- iOS SDK
- Java SDK
- JavaScript SDK
- Node.js SDK
- PHP SDK
- Python SDK
- React Native SDK
- Mini Program SDK
- 错误码
- 常见问题
- 服务等级协议
- 附录
- 词汇表
- 动态与公告
- 产品简介
- 购买指南
- 快速入门
- 控制台指南
- 工具指南
- 最佳实践
- 开发者指南
- 数据湖存储
- 数据处理
- 故障处理
- API 文档
- 简介
- 公共请求头部
- 公共响应头部
- 错误码
- 请求签名
- 操作列表
- Service 接口
- Bucket 接口
- Object 接口
- 批量处理接口
- 数据处理接口
- 任务与工作流
- 内容审核接口
- 云查毒接口
- SDK 文档
- SDK 概览
- 准备工作
- Android SDK
- C SDK
- C++ SDK
- .NET(C#) SDK
- Flutter SDK
- Go SDK
- iOS SDK
- Java SDK
- JavaScript SDK
- Node.js SDK
- PHP SDK
- Python SDK
- React Native SDK
- Mini Program SDK
- 错误码
- 常见问题
- 服务等级协议
- 附录
- 词汇表
概述
Kerberos 是大数据生态系统中广泛应用的统一认证服务，GooseFS 作为大数据和数据湖场景下的加速存储服务，支持集群节点和用户访问接入 Kerberos 认证服务中。本文将详细介绍如何配置 GooseFS 接入 Kerberos 认证服务以及如何使用 Hadoop Delegation Token 认证。
GooseFS 接入 Kerberos 的认证架构
GooseFS Kerberos 认证优势
与 HDFS 接入 Kerberos 的认证架构和流程基本一致，在 HDFS 上启用了 Kerberos 认证流程的应用可以很容易地迁移到 GooseFS。
支持 Hadoop 的 Delegation Token 认证机制，因此可以很好地兼容 Hadoop 生态的应用作业。
配置 GooseFS 接入 Kerberos 认证
前提条件
GooseFS 1.3.0 及以上版本。
确保环境中已存在 Kerberos KDC 服务，并且 GooseFS 以及应用客户端能够正常访问 Kerberos KDC 服务相关端口。
在 Kerberos KDC 中创建 GooseFS 相关的身份信息
首先，我们需要在 Kerberos KDC 中创建 GooseFS 集群 Server 与 Client 相关的 Kerberos 身份信息，然后才能继续后续的接入配置。这里我们在 Kerberos KDC 服务器上借助
kadmin.local 交互式工具来完成创建：注意
kadmin.local 工具需要 root/sudo 权限执行。$ sudo kadmin.local
如果执行成功，则进入了 kadmin 的交互式 shell 环境中：
Authenticating as principal root/admin@GOOSEFS.COM with password.kadmin.local:
其中，
kadmin.local 表示该交互式执行环境的命令提示符。创建 GooseFS Server / Client 相关的身份信息
如下通过一个简单测试集群以及应用场景样例来介绍整个 Kerberos 的配置过程。
1. 集群环境说明
采用单 Master 双 Worker 的 Standalone 部署架构：
Master（JobMaster）：172.16.0.1
Worker1（JobWorker1）：172.16.0.2
Worker2（JobWorker2）：172.16.0.3
Client：172.16.0.4
2. 在
kadmin.local 中创建 Server 和 Client 身份认证相关信息：kadmin.local: addprinc -randkey goosefs/172.16.0.1@GOOSEFS.COMkadmin.local: addprinc -randkey client/172.16.0.4@GOOSEFS.COM
注意
此处使用
-randkey 选项的原因在于 GooseFS 无论 Server 还是 Client 登录均使用 keytab 文件认证，不使用明文密码。若身份信息需要用于 password 登录场景，则可以去掉该选项。3. 生成导出每个身份对应的
keytab 文件：kadmin.local: xst -k goosefs_172_16_0_1.keytab goosefs/172.16.0.1@GOOSEFS.COMkadmin.local: xst -k client_172_16_0_4.keytab client/172.16.0.4@GOOSEFS.COM
配置 GooseFS Server/Client 接入使用 Kerberos 认证
1. 将上述导出
keytab 文件分发到对应的机器上，此处建议的路径是 ${GOOSEFS_HOME}/conf/：$ scp goosefs_172_16_0_1.keytab <username>@172.16.0.1:${GOOSEFS_HOME}/conf/$ scp goosefs_172_16_0_1.keytab <username>@172.16.0.2:${GOOSEFS_HOME}/conf/$ scp goosefs_172_16_0_1.keytab <username>@172.16.0.3:${GOOSEFS_HOME}/conf/$ scp client_172_16_0_4.keytab <username>@172.16.0.4:${HOME}/.goosefs/
2. 在对应机器上，将 Server Principal KeyTab 文件的所属用户/用户组修改为 GooseFS Server 启动时所使用的用户及用户组（其目的是为了让 GooseFS 启动时有足够的权限读取）。
$ chown <GooseFS_USER>:<GOOSEFS_USERGROUP> goosefs_172_16_0_1.keytab$ # 同时修改 Unix 访问权限位$ chmod 0440 goosefs_172_16_0_1.keytab
3. 将 Client 的 KeyTab 的所属用户/用户组修改为发起 GooseFS 请求的客户端账户。其目的同样是为了保证 Client 有足够的权限读取该文件。
$ chown <client_user>:<client_usergroup> client_172_16_0_4.keytab$ # 同时修改 Unix 访问权限位$ chmod 0440 client_172_16_0_4.keytab
Server 和 Client 端 GooseFS 配置
1. Master/Worker Server 的 goosefs-site.properties
# Security properties# Kerberos propertiesgoosefs.security.authorization.permission.enabled=truegoosefs.security.authentication.type=KERBEROSgoosefs.security.kerberos.unified.instance.name=172.16.0.1goosefs.security.kerberos.server.principal=goosefs/172.16.0.1@GOOSEFS.COMgoosefs.security.kerberos.server.keytab.file=${GOOSEFS_HOME}/conf/goosefs_172_16_0_1.keytab
配置完成 GooseFS Server 端的认证配置后，重启整个集群以使得配置生效。
2. Client 的 goosefs-site.properties
# Security properties# Kerberos propertiesgoosefs.security.authorization.permission.enabled=truegoosefs.security.authentication.type=KERBEROSgoosefs.security.kerberos.unified.instance.name=172.16.0.1goosefs.security.kerberos.server.principal=goosefs/172.16.0.1@GOOSEFS.COMgoosefs.security.kerberos.client.principal=client/172.16.0.4@GOOSEFS.COMgoosefs.security.kerberos.client.keytab.file=${GOOSEFS_HOME}/conf/client_172_16_0_4.keytab
注意
Client 端需要指定 Server 的 principal。其原因为在 Kerberos 认证体系中，KDC 需要知道当前 Client 所访问的 Service，而 GooseFS 是通过 Server 的 principal 区分 Client 当前请求的 Service。
至此，GooseFS 接入 Kerberos 的基础认证完毕，后续客户端发起的请求都将经过 Kerberos 进行身份认证。
是
否
本页内容是否解决了您的问题？