背景
目前集群开启kerberos大概分为两种:一种是在创建集群的时候,同步开启kerberos认证;还有一种就是集群部署完成之后,再手动开启kerberos认证。随着kerberos认证在现场中使用频率愈来愈高,问题也是频发不断。最近有客户反馈集群开启了kerberos认证,zookeeper的sasl安全管理存在问题。
问题大概描述如下:
1. zookeeper client进行sasl认证,如果jaas文件和keytab文件及principal都ok,可以连接成功,正常使用。
2. zookeeper client进行sasl认证,如果jaas文件和keytab文件及principal有不ok的,连接不成功,不能正常使用。
3. zookeeper client不进行sasl认证,直接连接,可以连接成功,正常使用。
问题定位
关于这一块的疑问,社区也是讨论了一波。认证的目的肯定是为了做权限管理,不认证也能连接,怎么进行权限管理?有人说这是bug,社区并不予以支持。详细的描述在ZOOKEEPR-1736中,比较关键的一段描述如下:
https://issues.apache.org/jira/browse/ZOOKEEPER-1736
Because ZK authentication is pluggable (therefore, SASL is only one possible option out of several) and auth method is specified per ACL, it is strictly speaking incorrect to reject connections that don't auth with SASL, because they might be able to auth with another method to access znodes that do not have "sasl" auth specified as auth method. This was the thinking when SASL integration for ZK was developed. Otherwise we would have wrapped the whole connection with SASL, not tunneled SASL auth inside the ZK protocol.So this not a "security issue" as such - it is a deliberate design choice.On the other hand, providing some additional configuration toggle to enforce SASL authentication exclusively can be done. If the ZK devs want to commit it. TLS authentication doesn't work this way. When you use TLS if you can't auth at connection setup it doesn't matter what auth methods are specified by ACLs. In this sense, security design in ZK is inconsistent.
大概意思就是说zookeeper认证是插件化的,sasl只是认证方式中的一种,zookeeper sasl认证允许匿名用户登录,意思就是说这玩意就是这么设计的。认证肯定是用来对zookeeper做权限管理的。但是对于指定节点目录的权限管理,还需要结合其对应的ACL配置使用。
比如:在开启kerberos集群中,kafka服务在zookeeper中使用的一些节点目录,其ACL直接设置为anyone可以读(r),但是只有进程sasl认证的kafka用户才有全部权限(cdrwa)。从这一点来讲,kafka用zookeeper保存的内容也实现了权限管理的效果。
准确的说,所有zookeeper client都进行了sasl认证,只不过不加载jaas文件时候,是sasl认证失败,自动跳过转为尝试直接连接的方式。
不停的去检测认证虽然对功能没有什么影响,但是比较耗费服务器性能,可以通过设置系统参数(zookeeper.client.sasl)为false来禁用sasl认证。
这一点在社区的ZOOKEEPER-1657有详细的描述 https://issues.apache.org/jira/browse/ZOOKEEPER-1657