Azkaban 3. 授权介绍

1. 授权介绍

Azkaban 的授权主要用来控制用户在系统中能做什么事情。

一个调度系统通常不只是自己使用，实际环境中会有开发、测试、运维、数据分析等多类用户。如果所有人都能创建项目、上传任务、执行任务、修改定时调度，就很容易出现误操作。

所以 Azkaban 中需要区分：

• 谁可以登录系统
• 谁可以创建项目
• 谁可以查看项目
• 谁可以上传或修改任务
• 谁可以执行工作流
• 谁可以配置定时调度
• 工作流最终可以代理成哪个系统用户执行

Azkaban 的权限控制可以分成两层：

层级	说明
全局角色权限	通过 azkaban-users.xml 中的 role 控制用户在整个 Azkaban 中的权限
项目权限	在具体 Project 中给用户或用户组分配 READ、WRITE、EXECUTE、SCHEDULE、ADMIN 等权限

简单理解就是：

全局角色权限：控制用户在整个 Azkaban 系统中的能力
项目权限：控制用户在某个具体项目中的能力

2. 用户管理配置

Azkaban 默认使用 XmlUserManager 管理用户。

在 azkaban.properties 中可以看到类似配置：

user.manager.class=azkaban.user.XmlUserManager
user.manager.xml.file=azkaban-users.xml

也就是说，默认情况下用户、组、角色都配置在 azkaban-users.xml 中。

azkaban-users.xml 的基本结构如下：

<azkaban-users>
  <user username="admin" password="admin" roles="admin" groups="admin" />
  <user username="test" password="test" roles="readall" groups="dev" />

  <group name="admin" roles="admin" />
  <group name="dev" roles="readall" />

  <role name="admin" permissions="ADMIN" />
  <role name="readall" permissions="READ" />
</azkaban-users>

其中有三个核心标签：

标签	作用
user	定义可以登录 Azkaban 的用户
group	定义用户组
role	定义角色以及角色拥有的全局权限

3. 用户配置

用户通过 user 标签定义。

示例：

<user username="zhangsan"
      password="123456"
      roles="readall"
      groups="data_dev" />

常用属性如下：

属性	是否必须	说明
username	是	登录用户名
password	是	登录密码
roles	否	用户拥有的角色，多个角色用逗号分隔
groups	否	用户所属用户组，多个组用逗号分隔
proxy	否	用户可以代理执行的系统用户

例如一个用户属于多个组：

<user username="lisi"
      password="123456"
      roles="readall"
      groups="data_dev,data_test" />

这种配置表示 lisi 用户既属于 data_dev 组，也属于 data_test 组。

4. 用户组配置

用户组通过 group 标签定义。

示例：

<group name="data_dev" roles="readall" />

组的作用主要有两个：

1. 在全局层面给一组用户统一分配角色。
2. 在项目权限中给一组用户统一授权。

比如有一个项目需要让整个开发组都可以查看和执行，就可以在项目权限页面中给 data_dev 组分配 READ 和 EXECUTE 权限，而不是给每个用户单独配置。

用户组配置示例：

<azkaban-users>
  <user username="dev01" password="123456" groups="data_dev" />
  <user username="dev02" password="123456" groups="data_dev" />

  <group name="data_dev" roles="readall" />
</azkaban-users>

5. 角色配置

角色通过 role 标签定义。

示例：

<role name="admin" permissions="ADMIN" />
<role name="readall" permissions="READ" />

角色和项目权限不一样，角色是全局权限。

例如：

<role name="readall" permissions="READ" />

表示拥有 readall 角色的用户，可以在全局范围读取项目和执行日志。

Azkaban 官方文档中列出的全局角色权限如下：

权限	说明
ADMIN	拥有 Azkaban 中的所有权限
READ	可以读取所有项目和执行日志
WRITE	可以上传文件、修改 job 属性、删除项目
EXECUTE	可以执行任意 flow
SCHEDULE	可以添加或删除 flow 的调度
CREATEPROJECTS	当项目创建被限制时，允许用户创建项目

比较常见的配置如下：

<role name="admin" permissions="ADMIN" />
<role name="readall" permissions="READ" />
<role name="developer" permissions="READ,WRITE,EXECUTE" />
<role name="scheduler" permissions="READ,EXECUTE,SCHEDULE" />

6. 项目权限

项目权限是在具体项目中配置的。

当用户创建一个 Project 后，创建者默认会拥有这个项目的 ADMIN 权限。项目管理员可以进入项目页面，点击权限配置按钮，为其他用户、用户组或者代理用户添加权限。

项目权限主要包括：

权限	说明
ADMIN	管理项目，可以配置权限、删除项目
READ	查看 job、flow、执行日志
WRITE	上传项目文件、修改 job 文件
EXECUTE	执行、暂停、取消 flow
SCHEDULE	添加、修改、删除 flow 调度

这里要注意，项目权限是项目级别的。

比如用户 dev01 在 project_a 中有 EXECUTE 权限，只表示他可以执行 project_a 中的 flow，不代表他能执行其他项目。

7. 用户权限和组权限

项目权限页面中通常可以配置两类权限：

类型	说明
User Permission	给单个用户授权
Group Permission	给整个用户组授权

如果是多人协作的项目，更建议使用组权限。

例如：

data_dev 组：READ、WRITE、EXECUTE
data_ops 组：READ、EXECUTE、SCHEDULE
admin 用户：ADMIN

这样后续有新人加入开发组时，只需要在 azkaban-users.xml 中把用户加入 data_dev 组，不需要挨个项目修改权限。

8. Proxy User 代理用户

Proxy User 用来控制工作流最终可以以哪个系统用户身份执行。

在数据平台中，Azkaban Web 用户不一定等于 Linux 用户或 Hadoop 用户。例如：

Azkaban 登录用户：zhangsan
实际执行用户：hadoop

如果开启了代理用户能力，项目中需要配置允许代理的用户。这样可以避免任意用户随便代理成高权限系统用户执行任务。

示例：

<user username="zhangsan"
      password="123456"
      roles="readall"
      groups="data_dev"
      proxy="hadoop,hive" />

这表示 zhangsan 可以代理成 hadoop 或 hive 用户。

项目权限页面中也可以添加 Proxy User，用来限制某个项目可以代理哪些用户执行。

9. 常见授权场景

9.1 管理员

管理员一般拥有全局 ADMIN 权限：

<user username="admin" password="admin" roles="admin" groups="admin" />
<group name="admin" roles="admin" />
<role name="admin" permissions="ADMIN" />

管理员可以：

• 查看所有项目
• 创建和删除项目
• 上传任务
• 执行任务
• 配置调度
• 修改项目权限

9.2 只读用户

只读用户适合查看任务状态和日志：

<user username="viewer" password="viewer" roles="readall" />
<role name="readall" permissions="READ" />

只读用户一般只能：

• 查看项目
• 查看 flow
• 查看执行日志

不能执行任务，也不能修改任务。

9.3 开发用户

开发用户通常需要上传任务和手动执行任务：

<user username="dev01" password="123456" groups="data_dev" />
<group name="data_dev" roles="readall" />

然后在项目权限中给 data_dev 组配置：

READ
WRITE
EXECUTE

这样开发用户可以查看、上传和执行项目，但不能随意修改项目权限。

9.4 运维调度用户

运维调度用户通常需要执行任务和配置调度：

READ
EXECUTE
SCHEDULE

这类用户不一定需要 WRITE，因为调度人员可能只负责执行和定时，不负责修改 job 文件。

10. 常见问题

10.1 看不到 Create Projects 按钮

如果用户登录后看不到创建项目按钮，可能是项目创建被限制了。

这种情况下，需要给用户或用户组增加：

CREATEPROJECTS

示例：

<role name="project_creator" permissions="READ,CREATEPROJECTS" />
<user username="dev01" password="123456" roles="project_creator" />

10.2 用户看不到某个项目

可能原因：

1. 用户没有这个项目的 READ 权限。
2. 用户所在组没有这个项目的 READ 权限。
3. 用户没有全局 READ 或 ADMIN 角色。

处理方式是在项目权限页面中给用户或用户组增加 READ 权限。

10.3 用户不能执行 Flow

如果用户能看到项目，但是不能执行 flow，通常是缺少：

EXECUTE

需要在项目权限中给用户或用户组增加 EXECUTE 权限。

10.4 用户不能配置定时调度

如果用户可以执行 flow，但是不能配置 schedule，通常是缺少：

SCHEDULE

需要在项目权限中增加 SCHEDULE 权限。

10.5 修改 azkaban-users.xml 后不生效

XmlUserManager 会在启动时解析 azkaban-users.xml。如果修改后不生效，可以先重启 Azkaban Web Server。

同时检查：

azkaban.properties 中 user.manager.xml.file 是否指向正确文件
azkaban-users.xml XML 格式是否正确
用户、组、角色名称是否写错

11. 配置建议

生产环境中建议遵循几个原则：

1. 不要给普通用户全局 ADMIN。
2. 项目权限优先按组授权，不要大量按个人授权。
3. 开发用户一般给 READ、WRITE、EXECUTE，是否给 SCHEDULE 要看团队分工。
4. 只读用户只给 READ。
5. Proxy User 要谨慎配置，不要让普通用户随意代理高权限系统账号。
6. 修改 azkaban-users.xml 后要备份配置，并记录变更原因。

12. 总结

Azkaban 3 的授权可以抓住三条主线：

用户和用户组：决定谁登录、谁属于哪个团队
角色：决定用户在全局范围有哪些能力
项目权限：决定用户在某个项目中能做什么

项目权限中的几个常见权限可以这样记：

权限	记忆方式
READ	能看
WRITE	能改、能上传
EXECUTE	能执行
SCHEDULE	能定时
ADMIN	能管理项目和权限

如果只是团队内使用，最简单的方式是：

管理员使用 ADMIN
开发组使用 READ + WRITE + EXECUTE
调度组使用 READ + EXECUTE + SCHEDULE
查看人员使用 READ

这样权限边界比较清楚，也比较容易维护。