精读笔记（RHCA 英文教材）· DO447 Chapter 7 Managing Access with Users and Teams

大约 7 分钟

精读笔记（RHCA 英文教材）· DO447 Chapter 7 Managing Access with Users and Teams

教材原文：RHCA 官方英文教材（教材第 259~284 页）（OCR 整书版已从本站移除，本页为章节精读）关联知识：02-08-Ansible自动化（RH294DO447）、上一章 6.1 Tower 的 RBAC 特性；本系列配套 00-RHCA教材精读-导航与学习法.md 章节结构：7.1 创建与管理 Tower 用户（RBAC/Organization/用户类型/组织角色）→ 7.2 用团队高效管理用户（Team 角色/tower-cli）→ Lab Managing Access with Users and Teams

Chapter Goal / Objectives（原文+译）

GOAL: Create user accounts and organize them into teams, and manage user and team permissions to administer and access Ansible Tower resources.（创建用户账号并把它们组织成团队；管理用户/团队对 Tower 资源的管理与访问权限）
OBJECTIVES：① 在 Web UI 创建用户，解释 Tower 的三种用户类型；② 在 Web UI 创建团队、把用户加入团队，解释可分配给用户的角色；③ 用 Organization/Team/用户类型/角色体系落地最小权限。

7.1 Creating and Managing Ansible Tower Users（创建与管理用户）

RBAC 基础（Why）

不同人需要不同层级访问：有人只需“运行既有 job template”，有人要改 inventory/模板/playbook，个别人可改任何配置。
内置超级用户 admin：拥有整个 Tower 配置的 superuser 权限；管理员用 admin 建各人账号，避免共用 admin。
权限载体：**角色（role）**决定用户/团队能否看（view）、用（use）、改（change）、删（delete）某个对象（Inventory/Project/Job Template/Credential 等）；角色可授予单个用户，也可授予 Team，团队所有成员继承。

Organization（组织）

定义：Teams、Projects、Inventories 的逻辑集合；所有 User 必须属于一个 Organization（安装时自动创建 Default Organization）。
作用：大型企业按部门隔离——某部门只能用自己该用的清单/剧本；在 Organization 层面统一管理“哪些用户/团队能碰哪些 Tower 资源”。
建新 Organization：admin 登录 → 左侧 Organizations → “+” → 填名称/可选描述 → SAVE。

三种用户类型（考点：singleton 角色）

用户类型	权限	说明
System Administrator（Superuser）	对全 Tower 读写	singleton 角色：对所有 Organization 的所有对象都有读-写；安装器建的 admin 就是它，只应给管理员用
System Auditor	对全 Tower 只读	singleton 角色：可审计一切但不能改
Normal User	初始最小权限	无 singleton 角色；只继承“所属 Organization 分配的角色”（创建时默认给 Member）

IMPORTANT：System Administrator 继承每个 Organization 的 Admin 角色；System Auditor 继承每个 Organization 的 Auditor 角色。

创建 / 编辑用户

创建：admin 登录 → Users → “+” → 填 First/Last name、Email、唯一 Username、Organization（放大镜选择）、Password/Confirm Password、User Type → SAVE。
编辑：Users 页点用户名 → 改字段 → SAVE。注意 Edit User 只能改“用户类型”与“所属 Organization”；完整角色管理要走 Organization → Permissions 页。

Organization 上的四个角色 + 细分 Admin（重点）

Organization 对象本身可分配四个角色： | 角色 | 权限 | | --- | --- | | Admin（Organizational Admin） | 管理该组织一切：读写 Organization、增删其中的 User/Team | | Auditor | 对该组织只读 | | Member | 可看该组织与成员列表；不继承组织内任何资源权限（≈ Read） | | Read | 只读组织本身，能看成员及其角色；不继承资源权限 |
资源/管理细分角色（给 Admin 减负的一组“更受限”角色）： | 角色 | 能力 | | --- | --- | | Project Admin | 增删改查组织内 Project；配合 Inventory Admin 才能建 Job Template | | Inventory Admin | 增删改查组织内 Inventory；配合 Job Template/Project Admin 可完全控制 job template | | Credential Admin | 管理共享凭据 | | Notification Admin | 分配通知 | | Workflow Admin | 创建 workflow | | Job Template Admin | 改 Job Template 的非敏感字段；要改影响作业运行的字段还需 Job Template 的 Admin + 相关 Project 的 Use + 相关 Inventory 的 Use | | Execute | 执行组织内的 Job Template / Workflow Job Template |
角色管理入口：Organizations → 某组织 → Permissions → Add Users/Teams 勾人 → Select Roles 下拉加角色（可多次添加）→ SAVE；角色前点 X 可移除。角色定义可用 KEY 按钮查看。

Guided Exercise 1 要点（lab: tower-users）

以 admin 建 3 个用户（均属 Default）：

sam：Normal User（Sam Simons）；
sylvia：System Auditor（Sylvia Simons）；
simon：System Administrator（Simon Stephens）；密码均 redhat123 → 观察三种类型在继承角色上的差异 → finish。

7.2 Managing Users Efficiently with Teams（用团队管理用户）

Team 概念与规则

Team = 用户组；把同一组角色授给 Team，成员自动继承，避免逐个用户配角色。
结构规则（易错）：
- 用户是 Tower 全局对象，可在多个 Organization 有角色；
- 一个 Team 只属于一个 Organization，但 System Administrator 可给该 Team 授予“其它 Organization 资源”的角色；
- Team 不能被赋予 Organization 对象上的角色（管理 Organization 只能直接授给具体用户）；
- Team 可以被赋予其所属组织内资源（Project/Inventory/Job Template…）的角色。

创建 Team / 添加成员

创建：admin（或该组织 Admin 角色者）→ Teams → “+” → Name + 可选 Description + 必选 Organization → SAVE。
加成员（默认 member 角色）：Organizations → 组织下 TEAMS → 点 Team → USERS → “+” → 勾选用户 → SAVE。

Team 上的角色（member / admin / read）

角色	能力
member	继承 Team 在资源上的角色；可看 Team 成员与其角色
admin	完全管理该 Team：管成员/成员角色；也可管 Team 在某资源上的角色（仅当该资源也把 admin 角色授给该 Team）
read	看 Team 成员与其角色；不继承 Team 在资源上的角色

嵌套授权规则：要给 Team 授某 Project 的 use 角色，操作者必须同时拥有该 Team 与该 Project 的 admin 角色。
实践建议（教材原话）：多数组织只用 member；admin/read 等 Team 角色用 Web UI 不好配 → 用外部认证管理成员，管理用 Organization Admin/System Administrator，审计用 System Auditor。

tower-cli（Tower 3.4+ 配 Team admin/read 角色的工具）

场景：把用户加为 Team 的 admin 或 read 角色需用 tower-cli 或 REST API（Web UI 从 3.4 起不再直接支持）。
先配置连接：tower-cli config host <主机>、tower-cli config username <用户>、tower-cli config password <密码>；自签证书环境 tower-cli config verify_ssl false。

授角色示例：

tower-cli role grant --user 'joe' --target-team 'Operators' --type 'admin'
tower-cli role grant --user 'jennifer' --target-team 'Architects' --type 'read'

Guided Exercise 2 + Lab 要点（lab: tower-teams / org-review）

GE2（tower-teams）：建 Team Developers（Default）；建 3 个 Normal User：daniel（Daniel George）、donnie（Donnie Jameson）、david（David Jackobs）；把 daniel 加为 Developer 成员；把 donnie 加为 Developer 的 admin（tower-cli）；观察继承差异 → finish。
Lab（org-review）：环境已配好 tower-cli → ① 在 Default 建 2 个 Normal User：oliver（Oliver Stone）与 ophelia（Ophelia Dunham，密码均 redhat123）；② 建 Team Operations；③ oliver 加为 Operations 的 member；④ ophelia 加为 Operations 的 admin；⑤ 登出后用各自账号验证权限差异 → grade/finish。

核心词汇表

英文	中文速记
RBAC	基于角色的访问控制
role	角色（决定对对象的 view/use/change/delete）
Organization	组织（Team/Project/Inventory 的逻辑集合；所有用户必属一个）
Default Organization	安装时自动创建的组织
System Administrator / Superuser	系统管理员 singleton（全 Tower 读写）
System Auditor	系统审计员 singleton（全 Tower 只读）
Normal User	普通用户（最小权限，继承组织角色）
singleton role	单例角色（系统级，全实例唯一生效）
Organization Admin / Auditor / Member / Read	组织上的四个角色
Project/Inventory/Credential/Notification/Workflow/Job Template Admin	组织内资源管理细分角色
Execute	执行作业角色
Team	团队（用户组；属于一个 Organization）
Team member / admin / read	团队角色
tower-cli	Tower REST API 命令行工具（Team 角色管理）
inherited roles	继承的角色（用户继承团队/组织的角色）

本章自测

Organization 是什么？用户、团队、资源在 Organization 上的从属/全局关系？
三种用户类型与两个 singleton 角色？Normal User 建好后默认得到哪个组织角色？
Organization 上四角色（admin/auditor/member/read）差异？为什么 Member≈Read？
资源管理细分角色各管什么？为什么“Project Admin + Inventory Admin 才能建 Job Template”？
Job Template Admin 想改影响作业运行的字段，还需要哪些角色组合？
Team 与 Organization 的关系；为什么 Team 不能有 Organization 对象上的角色？
Team 三角色 member/admin/read 各自权限？授“Team 对 Project 的 use”需要操作者具备什么？
为什么 3.4 起 Team admin/read 用 tower-cli 配？命令怎么写？
Lab 里 oliver(member) 与 ophelia(admin) 在 Operations 团队上能做什么、不能做什么？
SUMMARY 六条要点复述并给出“最小权限落地”的推荐组合（用户类型+组织角色+团队）。