Kafka安全机制的最新进展

截至目前版本（0.8.2），kafka并没有提供任何安全机制，在未来的0.9.0版本，kafka即将开始支持可选的安全机制，主要包括认证和授权。

总览

以下是目前apache社区对kafka security的实现目标

1、支持consumer/prodcuer与broker连接时的身份认证
2、支持连接后各种操作的授权
3、支持通信加密
4、支持安全令牌，分别可以代表交互用户、用户组和长运行服务
5、安全机制在安装时候是可选的，用户可以选择不使用以上特性
6、保留向后兼容性，特别是保证现有第三方库依然可以使用

功能范围

1、SSL&Kerberos认证

2、安全审计

3、类UNIX用户、权限和ACL的授权机制

4、通信加密（可选）

5、API友好的使用方式

认证

支持的认证方式
1、SSL（必须）
2、Kerberos（必须）
3、Hadoop委托令牌：在MapReduce、Samza或其他框架中访问Kafka（可选）
4、LDAP用户名/密码（可选）
5、任何未通过认证的连接将会被赋予一个伪装用户（如nobody、josephk或其他），管理员可以选择取消伪装用户

Kerberos是最常见的认证机制，而SSL是更通用的方式，Kafka Broker服务器会同时支持这两种认证机制，与此同时，也可以保留无需认证的连接。将来kafka会支持更多的SASL认证机制。

LinkedIn安全团队建议给SSL、所有支持SASL机制的以及无须认证的三种连接分别分配专用的端口。

一个为SSL专用的连接端口解决了对那些需要使用kafka特殊的协议信令，如认证开始和协商认证机制（因为这些是隐含在客户端连接端口过程中），客户端只需要简单的使用标准的SSL消息进行连接即可。这样做有两个好处：

1、SSL握手提供消息完整性

2、客户端可以使用标准的SSL库取建立连接

专用的SSL连接端口需要一对新的Kakfa Request/Response，作为提供给特殊应用的一种协商机制。但是，这就可能会增加”降级攻击“（攻击者可以拦截发送给服务端的请求消息并篡改消息中的认证机制，使其重新发起另一种较弱的认证机制的请求）的风险，为了避免这个风险，可以通过设计一种在客户端上单次只能发起一种认证机制的请求，这时，企图降级攻击将会导致SSL握手失败。基于这种协议，甚至可以支持在SASL端口上接收无须认证的连接。

简单描述下协议的过程：

1、客户端连接到SASL端口

2、服务端接受，读取新连接请求

3、客户端发送包含一个数值标示（暗示认证机制的类型）的认证请求

4、如果客户端的认证机制与请求中的认证机制不一致，服务端会拒绝请求。如果一致，则返回SASL响应数据

5、客户端回复SASL相应数据

Kafka集群管理员可以选择在配置中禁用认证机制。这需要在集群元信息中进行维护，然后客户端才可以选择连接到对应的端口。

安全认证的特性需要服务端与客户端API层协作，在API层需要处理认证请求，并且在连接中需要关联上用户名，一种实现方式是在增加一个Session Object的概念，Session Object会包含用户名并维护在连接中。Session将会存储在服务端上下文中，并且端口关闭时会摧毁所有Session。Session将会伴随请求一同传递到API层，并且服务端会使用类似session.authenticatedAs()获取用户名并且做一些认证操作，同时会记录下Session中安全相关信息以便于在授权中使用。

后续的授权检查全部是基于Session信息。

授权

以下是目前达成一致的结论

无论使用以上任何一种认证机制，检查权限的机制完全是相同的。一个成功的使用客户端证书的SSL连接或其他成功连接后，服务端会从连接中保存用户的信息，请求对象会伴随在后续的每个请求中。

安全必须是可控的基于每个主题的基础上与某种粒状授权。如果没有这一点，你将为每个应用程序对应一个kafka集群，这违背了使用消息队列集群的目的。因此在大组织中，你需要使用权限和可管理的方式。

计划是针对每个topic使用类UNIX权限级别。

授权机制将会在kafka业务逻辑层进行实现，API会类似如下

PermissionManager.isPermitted(Subject subject, InetAddress ip, Permissions permission, String resource)

比如说进行一个生产操作请求，你将会使用类似如下

PermissionManager.isPermitted(session.subject(), session.peerIpAddress(), Permissions.WRITE, topicName)

在所有请求中都会产生这类的检查，所以明显是需要非常高效的，将会被缓存起来。

主要是基于用户名或识别一个尝试进行一些操作的用户。这些会通过认证后建立，比如一些读或写操作。

请求发起方的IP地址也许在某些情况下比较有用，如黑名单。

关于权限，会有以下几种：

READ - 读取topic

WRITE - 写入topic

DELETE - 删除topic

CREATE - 创建topic

CONFIGURE - 修改topic

DESCRIBE - 获取topic信息

REPLICATE - 增加topic副本

权限没有进行分层是因为topic同样是没有层级关系的。