Zeppelin安全机制之Credentials使用技巧(补充)
一、Credentials简介
Data source authorization involves authenticating to the data source like a Mysql database and letting it determine user permissions. Apache Zeppelin allows users to use their own credentials to authenticate with Data Sources.
上面这段简介引用自Zeppelin官网的Data Source Authorization部分。正如官方文档所介绍的一样，Zeppelin引入Credentials的初衷是为了方便用户使用各自的凭据连接数据源，而不是所有用户共用一个账号去访问。除了官网文档介绍的内容之外，Zeppelin 0.9还实现了使用用户定义的Credentials来对Paragraph中的敏感信息进行脱敏的特性。总的来说，Zeppelin的Credentials是个非常实用的特性，奈何Zeppelin官网对该特性的介绍不够详细，配置和使用过程中容易走弯路，所以我会在这里详细介绍一下Credentials的使用。
二、Credentials配置
使用Zeppelin的Credentials之前需要在
$ZEPPELIN_HOME/conf/shiro.ini启用Zeppelin Server身份认证以及相关接口的权限检查。若不启用身份认证和权限检查，所有人都可直接通过anonymous对Zeppelin的所有接口进行访问，配置Credentials就没多大意义了。
如何启用Zeppelin身份认证这里不做介绍，只强调一下需要将
/api/credential/** = authc,role[admin]修改为/api/credential/** = authc,以放开/api/credential/**相关接口的权限校验，保证所有用户都能创建自己的Credentials。
启用Zeppelin Server身份认证和权限校验之后，别忘了重启Zeppelin服务
接下来就可以访问配置页面，添加自己的凭据信息,创建Credentials时Entity名称推荐使用
[InterpreterGroupName].[InterpreterName], 后面会说明这样建议的原因
三、Credentials应用场景
上一部分介绍了如何配置Credentials信息，这一部份我们接着介绍Credentials在Zeppelin中的两种主要的应用场景。
场景一: 作为数据源(主要是JDBCInterpreter)的认证凭据
Zeppelin JDBC解释器创建连接时获取用户身份认证信息的策略是先检查JDBC解释器配置中user和password信息，若JDBC解释器配置中没有user相关信息则尝试从当前用户的Credentials列表中获取Entity名称为
jdbc.<当前JDBC解释器名称>的Credentials的user和password信息来作为当前解释器连接远端数据源的认证凭据。这就是为什么第二节中推荐大家在创建凭据信息时使用[InterpreterGroupName].[InterpreterName]作为凭据Entity名称的原因。补充： Zeppelin 0.9 最新分支以及 2020 年 6月 以后发布的安装包的 JDBC 解释器当解释器名称不为 jdbc 时直接使用解释器名称作为 Credentials EntityName 来获取用户认证凭据，当解释器名称为默认的 jdbc 时使用解释器配置前缀为 Credentials EntityName 来获取认证凭据。
所以使用 Zeppelin 0.9 最新分支时若要使用 Credentials 作为 JDBCInterpreter 认证凭据，则 Credentials EntityName应该设置为 InterpreterName，而不再是设置为 InterpreterGroupName.InterpreterName。
看完上一小节的介绍，不难看出如果要使用当前用户创建的Credentials作为数据源的认证凭据，除了需要按相关规则创建Credentials外，还需在配置该数据源对应的解释器时删除掉数据源user相关的配置项，否则就算是配置了Credentials，也只会使用配置数据源解释器时指定的公共用户对数据源进行访问。
⚠️ 这种场景目前存在一个小bug：在运行段落时若没有显式在第一行通过"%InterpreterName"的方式声明解释器，则无法使用用户自己定义的Credentials作为访问解释器数据源的认证凭据，从而导致段落运行报错。该问题0.9版本发布时应该会修复，0.9之前的版本可显式声明使用的解释器来规避这个问题。
场景二: 用于Paragraph中的敏感信息的脱敏
借助Credentials对Paragraph中的敏感信息进行脱敏是 Zeppelin 0.9版本才引入的新特性，由于Zeppelin 0.9还未release，使用方式可能还会有所调整。我这里介绍的是0.9-preview1版本的用法，以后具体该如何使用此特性可以关注Zeppelin 0.9的相关发布信息获取。
若Credentials只用作对Paragraph中的敏感信息进行脱敏的用途，不用作解释器级别的数据源认证凭据，则Credentials凭据Entity名称可以不按
[InterpreterGroupName].[InterpreterName]格式进行定义。这里以第二部分中创建的Entity名为mysql_account_mask的Credentials信息为例简单演示一下如何在Paragraph中使用Credentials进行敏感信息脱敏：上面使用了{user.CredentialsEntity}和{password.CredentialsEntity}的方式来访问当前用户创建的Credentials信息，但社区最新代码已经更新Credentials访问方式为{CredentialsEntity.user}和{CredentialsEntity.password}。最终该如何访问可关注Zeppelin 0.9的发布信息。
用户间的Credentials是相互隔离的，这就意味着A用户并不能访问B用户创建的Credentials信息，这保证了大家使用Credentials来进行数据源访问权限隔离以及Paragraph敏感信息脱敏时的安全性
注意：要使用Credentials对段落中的敏感信息进行脱敏，还需要在配置对应解释器或者运行段落时通过指定injectCredentials为true来启用Credentials注入功能，该功能默认是禁用的，若不启用，则Credentials是不能正常注入的。
四、小结
以上便是Zeppelin Credentials当前支持的两种使用场景及其使用技巧的介绍。我们在使用开源产品时，或多或少都会遇到一些文档更新滞后，非主线功能描述不够详细等问题。遇到这些问题时，有条件的同学可以多动手，到源码中去找答案，正如台湾C++大师侯捷所说：“源码面前，了无秘密”；开发功底弱一些的同学，也可以多在开源技术社区、开源交流群进行互动，一方面可以借助社区的力量来解决自己的疑惑，另一方面也可以让社区关注到当前存在的问题，毕竟众人拾材火焰高嘛。
最后贴一下Apache Zeppelin官方交流群，欢迎大家加入交流，共同推进Zeppelin这一优秀产品的使用和发展。