一、什么是认证机制？
所谓认证，又称“验证” “鉴权”，英文是authentication，是通过一定的手段，完成对用户身份的确认。认证的主要目的是确认当前声称某种身份的用户确实是所声称的用户。注意不要与授权（authorization）混淆。授权一般是指对信息安全或计算机安全相关的资源定义与授予相应的访问权限。
简单来区分就是，认证要解决的是你证明你是你的问题，授权要解决的则是你能做什么的问题。
二、kafka的认证机制
自0.9.0.0版本开始，kafka正常引入了认证机制，用于实现基础的安全用户认证，这是将kafka上云或进行多租户管理的必要步骤。目前来说，kafka支持基于SSL和SASL的安全认证机制。
基于SSL的认证主要是指broker和客户端的双路认证。SASL可以用作客户端认证，SASL是提供认证和数据安全服务的框架。kafka支持的SASL机制有5种，分别在不同的版本引入的，可以通过使用的kafka版本来选择使用哪种认证机制。
1、 GSSAPI： 也就是kerberos使用的安全接口，是在0.9版本中引入的；
2、 PLAIN: 是使用简单的用户名/密码认证的机制，在0.10版本引入；
3、 SCRAM: 主要用于解决PLAIN机制安全问题的新机制，是在0.10.2版本中引入的；
4、OAUTHBEARER: 基于OAuth2认证框架的新机制，在2.0版本中引进；
5、Delegation Token: 补充现有的SASL机制的轻量级认证机制，是在1.1.0版本被引入的；
三、各种认证的对比
SSL一般用来通信加密，SASL用来做kafka的认证实现，GBase8a MPP涉及的主要也是SASL相关的认证，我们来详细分析一下SASL认证机制的不同特点。
1、 SASL/GSSAPI: 主要是给Kerberos使用的，如果你的环境已经启用了Kerberos认证，那么使用GSSAPI是最方便的了，因为不需要额外搭建Kerberos，只需要Kerberos管理员给每个broker和要访问Kafka集群的服务（GBase8A MPP）申请principal和keytab即可。也就是说，GSSAPI适用于本身已经做了Kerberos认证的场景，这样的SASL/GSSAPI可以实现无缝集成。
2、 SASL/PLAIN: 一个简单的用户名/密码认证机制，通常与SSL加密搭配使用。PLAIN和PLAINTEXT是两回事，PLAIN是一种认证机制，PLAINTEXT指的是未使用SSL时的明文传输。对于一些小公司来说，搭建公司级的Kerberos可能没有什么必要，系统本身也不复杂，特别是访问kafka集群的用户也不是很多，这对于SASL/PLAIN就是一个比较合适的方案，配置和运维成本较小，适合小型公司的kafka集群。
3、 SASL/SCRAM: SCRAM解决了PLAIN的一个弊端，SASL/PLAIN 不能动态地增减认证用户，必须重启kafka集群才能使变更生效。因为所有认证用户的信息都保存在静态文件中，只有重启broker，才能重新加载变更后的静态文件。SASL/SCRAM 解决了这个问题，通过将认证信息保存在Zookeeper中，避免了动态修改需要重启Broker的弊端。可以使用Kafka提供的命令动态地创建和删除用户，无需重启整个集群。
4、 SASL/ OAUTHBEARER: 引入该认证机制主要是为了与OAuth2框架的集成。0Auth是一个开发标准，允许用户授权第三方应用访问该用户在某网站上的资源，而无需将用户名和密码提供给第三方应用。Kafka不提倡单纯使用OAUTHBEARER，因为它生成的不安全的JSON Web Token，必须配以SSL加密才能使用在生产环境中，目前实际使用案例不多。
5、 SASL/ Delegation Token： 一种轻量级的认证机制，主要是为了补充SASL或SSL认证。如果要使用Delegation Token，你需要先配置好SASL认证，然后再利用kafka提供的API去获取对应的Delegation Token。这样，Broker和客户端在做认证的时候，可以直接使用这个Token，不用每次都去KDC获取对应的ticket（Kerberos认证）或者Keystore文件（SSL认证）。
四、GBase8A MPP的认证支持
目前来说，南大通用GBase 8a MPP和kafka环境适配，主要支持SASL/GSSAPI 用于接入Kerberos认证环境。提供两个参数去对principal和keytab进行配置。
分别为gbase_kafka_keytab 和 gbase_kafka_principal。
