Curve 安全加固：基于Kerberos的鉴权系统

Curve 系统鉴权的思路基于 Kerberos 认证协议，为了便于对后续认证过程的理解，首先对 Kerberos 进行简要介绍，协议中主要有三种角色：

1. client：发送请求的一方

2. server: 接收请求的一方

3. KDC(Key Distribution Center):秘钥分发中心，一般由三部分组成

• AS(Authentication Server): 认证服务器，用于认证客户端的身份，并发放客户端用于访问 TGS(Ticket Granting Server)的TGT(Ticket Granting Ticket)
• TGS: 发放整个认证过程和客户端访问服务端时所需的服务授予票据（Ticket）
• DB: 一个用于存储认证信息的数据库

如何证明“我就是我”？

1. 认证的第一次通信

client 使用 CT_SK 解密获取与 server 通信的 session key(CS_SK)，最后向 server 发送图示两部分内容进行最后的验证。

整个 kerberos 认证的过程较为复杂，三次通信中都使用了密钥，且密钥的种类一直在变化，并且为了防止网络拦截密钥，这些密钥都是临时生成的 Session Key, 即他们只在一次 Session 会话中起作用，即使密钥被劫持，等到密钥被破解可能这次会话都早已结束。

同样首先考虑核心三种角色：

• Client: curve-client、tools、mds、chunkserver
• Server: mds、chunkserver、snapshotcloneserver

• KDC: 考虑到目前 Curve 自身的架构，可以在 MDS 中新增 AuthServive, 让 MDS 兼任 KDC 的角色并合并 AS 和 TGS 的功能，密钥和用户身份信息可存储在 ETCD 中。

加密算法

client 和server 端之间的认证信息传递和认证有两种方式：

• 优点：比较灵活，可适应使用不同 rpc 框架的 client 和 server。
• 缺点：每个请求都需要进行验证，性能会有一定损耗。

2.使用 brpc 框架提供的基于连接的认证，用户只需要继承实现 Authenticator 即可。

• 优点：基于连接的认证在 TCP 连接建立后，会发送验证包，认证通过后该连接的后续请求不需要再验证，对性能损耗较小。
• 缺点：不够灵活，一般只能携带本机的静态信息，且不能适应不同框架间的通信（rpc client是 grpc 而 rpc server 是 brpc）。

<原创作者，王海，Curve maintainer>

关于 Curve 

Curve 是一款高性能、易运维、云原生的开源分布式存储系统。可应用于主流的云原生基础设施平台：对接 OpenStack 平台为云主机提供高性能块存储服务；对接 Kubernetes 为其提供 RWO、RWX 等类型的持久化存储卷；对接 PolarFS 作为云原生数据库的高性能存储底座，完美支持云原生数据库的存算分离架构。

Curve 亦可作为云存储中间件使用 S3 兼容的对象存储作为数据存储引擎，为公有云用户提供高性价比的共享文件存储。

• GitHub：https://github.com/opencurve/curve
• 官网：https://opencurve.io/
• 用户论坛：https://ask.opencurve.io/
  微信群：搜索群助手微信号 OpenCurve_bot