1. Kafka Security Component

  • Kafka Security Documentation

  • Confluent Security Documentation

  • 标准的Kafka设置，任何用户或应用均可向任何主题写入任何消息，也可从任何主题读取数据；

  • 随公司转向共享租户模式(shared tenancy model)，即多个团队和应用使用同一个Kafka集群，
    或Kafka集群开始引入(onboarding)关键(critical)或机密(confidential)信息；

* A：Encryption of Data In Flight via SSL/TLS：

  • 允许数据在producer与kafka，consumer与kakfa之间加密，
    这是很常见的模式，即Https中的s，即网站上绿色的小锁；

  • B：Authentication via SSL或SASL，用SSL或SASL身份验证：

  • 这允许生产者和消费者向Kafka集群进行身份认证，此为安全方式，
    使客户端认可一个身份(enable client to endorse identity)，
    此操作为授权for authorization；

  • C：Authorization via ACL，使用ACL的授权：一旦客户端经过身份认证，
    broker就可根据ACL运行它们，以确定特定客户端是否有权写入或读取某些主题或任何Kafka资源；

2. Encryption SSL

KafkaSslEncryption

  • Encryption解决中间人(MITM)攻击的问题，因当数据包被路由到Kafka集群时，
    它会在网络中传播(travel)，并从A机器跳到B机器(hop from A to B)；

  • 若数据是PLAINTEXT(Kafka默认)，则这些路由器router中
    的任何一个都可读取我们发送的数据的内容：

  • 现在可通过启用加密来设置SSL证书，数据现可加密并通过网络安全传输，
    使用SSL，只有第一台和最后一台机器能解密发送的数据包；

  • 此类加密是有代价的：Kafka客户端和broker都利用CPU来加密和解密数据包，
    SSL安全性以性能为代价，但很低，甚至可忽略不计low to negligible；

  • 若使用Jdk11+，那在SSL将获得显著的性能改进；

  • 注：encryption only in-flight，数据仍未加密的存储在broker磁盘上；

3. Authentication SSL SASL

KafkaAuthentication

3.1. SSL Authentication

  • SSL身份认证(双向身份认证)：即向客户颁发由证书颁发机构签署的证书，
    这将允许broker验证(verify)客户的身份(identity)；

  • issue certificate to client，sign by certificate authority，
    allow broker to verify client identity；

3.2. SASL Authentication

  • SASL：Simple Authorization Service Layer，简单授权服务层，

  • 即将身份认证(authentication)机制与kafka protocol分离，
    这在大数据系统很流行，如Hadoop利用Kerberos；

  • SASL支持多种状态(shape)和形式(form)：SASL PLAINTEXT，
    SASL SCRAM，SASL GSSAPI (Kerberos)，SASL OAUTHBEARER；

  • SASL PLAINTEXT：经典的用户名和密码组合；

  • 用户名和密码必须提前存储在broker，每次更改都需触发滚动重新启动
    (trigger rolling restart)，很烦人(annoying)，不推荐此类安全措施；

  • 若使用SASL/PLAINTEXT，请确保还启用SSL encryption，
    这样credential不会在网络上以PLAINTEXT形式发送；

  • SASL SCRAM：用户名和密码 + 盐(salt)，更安全，

  • 用户名和密码存储在Zookeeper，Zookeeper被移除会存储在Kafka主题中；

  • 这允许在不重新启动broker情况下，扩展安全性；

  • 若使用SASL/SCRAM，请确保启用SSL encryption，
    这样credential不会在网络上以PLAINTEXT形式发送；

  • SASL GSSAPI (Kerberos)：基于Kerberos ticket机制，此为非常安全的认证机制；

  • Microsoft Active Directory是Kerberos最常见的实现方式；

  • SASL/GSSAPI是大型企业的绝佳选择，设置Kafka与Kerberos相对最困难，但值得；

  • SASL OAUTHBEARER：允许利用Oauth2 Token进行身份认证，
    目前据说因使用不安全的Json Web Token，还没准备好上生产；

4. Authorization ACL

KafkaAcl

  • 一旦Kafka客户端通过身份认证，Kafka就需能决定他们可做啥和不能做啥，
    这是授权的作用，由ACL控制；

  • ACL是我们所期望的：用户A能/不能从主机D对资源C执行操作B，
    因新的AclAuthorizer，规则现在支持前缀prefix；

  • https://kafka.apache.org/documentation/#security_authz

  • 如A主题需仅从客户端或主机的子集写入，我们希望防止普通用户向这些主题写入任何内容，
    从而防止任何数据损坏或反序列化错误，若有敏感数据，且需向监管机构(regulator)
    证明prove只有某些应用或用户才能访问这些数据，那ACL非常适应；

  • kafka-acls.sh Command

./kafka-acls.sh --topic product-price --producer \
	--bootstrap-server 192.168.0.123:9092 \
	--add --allow-principal User:elf

  • 不要将选项—​authorizer-properties zookeeper.connect=192.168.0.123:2181
    与kafka-acls命令合用，因zookeeper正在被移除，现在broker直接支持处理admin Api命令；

  • 目前ACL存储在Zookeeper，即目前需保护Zookeeper的安全，并确保只有broker才被允许写入
    Zookeepper(Zookeeper.set.acl=true)，否则任何用户都可进入并编辑ACL，从而破坏安全性；