如何打造一套线上kafka集群安全环境

1.kafka安全简介

kafka社区在0.9.0.0版本正式添加了安全特性，并且在0.10.0.0版本中进一步完善。
Kafka的安全特性有如下几个方面：
1.连接认证。服务端与客户端、服务端之间、等等。支持两种认证机制SSL（等价于我们经常使用的TLS）和SASL
2.Zookeeper 与服务端的认证。
3.基于SSL的连接通道数据传输加密
4.客户端读写权限
5.支持可插拔的授权服务和与外部授权服务的集成。

认证(authentication)和授权(authorization)

• 认证：证明自己的过程，对于kafka的认证你必须显示地提供者自己的身份信息来证明自己的身份时合法的。

• 授权：验证认证过的用户可以访问那些资源。

现实的场景中认证和授权我们都是结合使用的。

认证机制分类：

-认证机制-	-引入版本-	-适用场景-
SSL	0.9.0	SSL做信道加密比较多，SSL认证不如SASL所以一般都会使用SSL来做通信加密
SASL/GSSAPI	0.9.9	主要是给 Kerberos 使用的。如果你的公司已经做了 Kerberos 认证（比如使用 Active Directory），那么使用 GSSAPI 是最方便的了。因为你不需要额外地搭建 Kerberos，只要让你们的 Kerberos 管理员给每个 Broker 和要访问 Kafka 集群的操作系统用户申请 principal 就好了。
SASL/PLAIN	0.10.2	简单的用户名密码认证，通常与SSL结合使用，对于小公司来说，没必要搭建公司级别的Kerberos，使用它就比较合适
SASL/SCRAM	0.10.2	PLAIN的加强版本，支持动态的用户增减
SASL/OAUTHBEARER	2.0	OAuth 2框架的集成
Deleation Token	1.1	Delegation Token 是在 1.1 版本引入的，它是一种轻量级的认证机制，主要目的是补充现有的 SASL 或 SSL 认证。如果要使用 Delegation Token，你需要先配置好 SASL 认证，然后再利用 Kafka 提供的 API 去获取对应的 Delegation Token。这样，Broker 和客户端在做认证的时候，可以直接使用这个 token，不用每次都去 KDC 获取对应的 ticket（Kerberos 认证）或传输 Keystore 文件（SSL 认证）。

ACL规则（kafka授权机制）

Principal P is[Allow/Denied] Operation O Fom Host H On Recourse R

Principal Kafka user

Operation 操作类型 比如 WRITE READ DESCRIBE

Host：kafka ip地址

resourse ：资源 TOPIC CLUSTER GROUP 等等

权限列表：

2.使用SASL/PLAIN + ACL搭建内网kafak集群安全机制

由于SASL/PLAIN 创建用户时静态创建的，所以如果新增用户需要修改配置，然后重启kakfa集群。

2.1.创建KafkaServer (jass.config)

KafkaServer{
org.apache.kafka.common.security.plain.PlainLoginModule required
username="admin"
password="admin"
user_admin="admin"
user_reader="reader"
user_writer="writer";
};

1.需要注意两个“；”的位置，一定不