Zeppelin Credentials机制是支持隐藏开发过程中诸如数据库帐密之类的一系列的敏感信息的一个特性。该特性目前有两大应用场景：

  • 对于JDBCInterpreter，支持不同用户之间使用不同的帐密信息访问诸如Mysql、HIve之类支持JDBC访问的服务
  • 从Zeppelin 0.9版本开始，还支持对Paragraph代码中的敏感信息进行脱敏

准备工作

  • 由于Zeppelin Credentials作用域为user级别，不同用户间允许定义同名的Credentials，它们之间相互隔离；所以使用Credentials机制前还需要开启Zeppelin的身份认证。

Credentials配置及应用

Credentials配置

image.png

如上图所示，登陆Zeppelin Web页面后可点击右上角的下拉框跳转到Credentials配置页面。然后定义自己的Credentials信息。

  • 注意：Credentials Entity名称推荐使用[InterpreterGroupName].[InterpreterName] 格式(例如, 用于保存Hive登陆信息的Credentials Entity名称定义为jdbc.hive)。这样做是为了能在JDBCInterpreter中用它作为当前登陆用户的JDBC身份认证凭据。

将Credentials用于JDBCInterpreter认证凭据

Zeppelin JDBCInterpreter创建连接时获取用户身份认证信息的策略是先检查JDBCInterpreter配置中user和password信息，若JDBCInterpreter配置中没有user相关信息则尝试从当前用户的Credentials列表中获取Entity名称为jdbc.InterpreterName的Credentials的user和password信息来作为当前解释器连接远端数据源的认证凭据。这也是上文推荐使用[InterpreterGroupName].[InterpreterName]作为Credentials Entity名称的原因。（特别提醒：JDBC解释器获取Credentials的逻辑变得比较频繁，截止2021/05/21为止，0.9最新版本的JDBC解释器是直接使用InterpreterName作为Credentials名称的，也就是无需再设置[InterpreterGroupName].前缀，详情请看Zeppelin-0.9最新版本JDBC解释器Credentials应用）
所以，要想使用Credentials来实现JDBCInterpreter用户登陆权限的隔离，只需要在配置对应的JDBC解释器时删掉相应的全局帐密信息，然后通知需要使用该解释器的各用户自建名为jdbc.InterpreterName的Credentials Entity即可。
image.png

  • 需要注意的是，这种场景目前存在一个小bug：在运行段落时若没有显式在第一行通过”%InterpreterName”的方式声明解释器，则无法使用用户自己定义的Credentials作为访问解释器数据源的认证凭据，从而导致段落运行报错。

    该问题0.9版本发布时应该会修复，0.9之前的版本可显式声明使用的解释器来规避这个问题。

image.png

将Credentials用于Paragraph脱敏

借助Credentials对Paragraph中的敏感信息进行脱敏是 Zeppelin 0.9版本才引入的新特性，0.9之前的老版本不支持。如果自定义的Credentials只用于此场景，不用作JDBCInterpreter的认证凭据的话，Credentials Entity名称也可以随意定义，只要保证同一用户环境下不重名即可。

  • 使用自定义Credentials对Paragraph脱敏也只需简单的两步:
    • 只需要在Paragraph中将对应的敏感信息用{CredentialsName.user}和{CredentialsName.password}替换掉即可(Zeppelin 0.9-preview1版本替换为{user.CredentialsName}和{user.CredentialsName}，需要注意的是这些CredentialsName需要换成你自己定义的Credentials名称)
    • 将需要脱敏的段落对应的解释器配置属性injectCredentials设为true：在解释器全局配置中配置或运行段落是临时声明都支持

image.png
image.png

  • 脱敏案例（这里使用的是zeppelin 0.9-preview1，新版本改用{CredentialsName.user}和{CredentialsName.password}来注入用户Credentials即可)

image.png

安全性保障

用户间的Credentials是相互隔离的，这就意味着A用户并不能访问B用户创建的Credentials信息。这保证了使用Credentials来进行数据源访问权限隔离以及Paragraph脱敏时的安全性。

补充

Zeppelin-0.9最新版JDBC解释器Credentials应用

  • 使用场景1: 在jdbc解释器组下使用前缀方式区分多种Jdbc解释器时（例如在已有的jdbc解释器组下为mysql配置mysql.前缀的连接配置信息，为hive配置hive.前缀的hive连接配置信息，那么可以通过%jdbc(mysql)或者%jdbc(db=mysql)的方式指定使用mysql解释器，同样可以使用%jdbc(hive)或者%jdbc(db=hive)的方式指定使用hive解释器，只指定%jdbc时使用default.前缀配置信息对应的解释器，我们暂且将%jdbc(mysql)、%jdbc(db=mysql)、%jdbc(db=hive)和%jdbc(hive)解释器声明信息中的mysql、hive称为解释器选择属性值)

    • 这种情况下如果使用credentials配置JDBC解释器认证凭据的话，credentials名称需要和解释器选择属性值一致，也就是对于%jdbc(mysql)、%jdbc(db=mysql)，credentials名称必须为mysql才能生效；对于%jdbc(db=hive)、%jdbc(hive)，credentials名称必须为hive才能生效。

  • 使用场景2: 对每一种JDBC解释器单独配置时，credentials名称必须和解释权名称一致才能正常使用。比如假设我们为presto服务配置了一个名为presto、解释器组为jdbc的解释器后，我们可以通过%presto的方式声明presto解释并通过它交互式执行presto sql，这种场景下如果我们需要使用credentials机制进行presto权限隔离的话，credentials entity名称必须和解释器名称一致，对于当前这个案例，credentials entity名称必须为presto才能生效。