教材原文：RHCA 官方英文教材（教材第 285~316 页）（OCR 整书版已从本站移除，本页为章节精读） 关联知识：02-08-Ansible自动化（RH294DO447）、上一章 7.x RBAC（用户/团队/组织角色体系是本章资源授权的基础）；本系列配套 00-RHCA教材精读-导航与学习法.md 章节结构：8.1 用 Web UI 创建静态清单（回顾 INI/许可计数/清单角色/变量）→ 8.2 创建机器凭据（Private vs Organization、凭据角色、典型场景）→ Lab Managing Inventories and Credentials（host-review）
- GOAL: Create inventories of machines to manage, and set up credentials necessary for Red Hat Ansible Tower to log in and run Ansible jobs on those systems.（创建要管理的机器清单，并配置好凭据，让 Tower 能登录这些系统并运行 Ansible 作业）
- OBJECTIVES：① 用 Web UI 创建受管主机的静态清单（static inventory）；② 为清单主机创建机器凭据（machine credential），让 Tower 能通过 SSH 在清单主机上运行作业。
- Ansible Playbook 跑在“主机与主机组的清单”上；无 Tower 时清单来自静态文件或外部动态脚本（脚本/插件）；本节聚焦用 Tower Web UI 管理静态清单。
- 教材示例 INI（对应后续要建的 Mail Servers 清单）：
london1.example.com
[southeast]
raleigh1.example.com
atlanta1.example.com
[northeast]
boston1.example.com
[east:children]
southeast
northeast
london1 不属于任何组；southeast/northeast 是普通主机组；[east:children] 是组中组（group of groups）——父组 east 包含 southeast 与 northeast 两个子组。 - 两个隐式组（implicit groups，考点）：
all＝清单内全部主机；ungrouped＝不属于任何其它组的“裸主机”（例中只有 london1）。 - Tower 中清单是对象：每个组织可有多个清单；job template 可指定使用（属于某组织的）某份清单；谁能使用某清单由其在清单上的角色决定（延续第 7 章 RBAC 体系）。
- 许可决定清单里可定义的最大主机数：Settings → License 页查看 HOSTS AVAILABLE（许可支持数）与 HOSTS REMAINING（剩余数）。
- 超出许可 → 无法启动任何 Job；若动态清单同步导致超限，则该次同步失败。
- 多份清单里同名主机（如多个
webserver1）许可只计 1 个节点——与 Dashboard 的 Hosts 计数不同（Dashboard 会把不同清单里的主机分开计数）；计数大小写敏感：webserver1 与 WebServer1 视为两个不同节点。
前置：以“Default 组织具备 Admin 角色”的用户登录。
- 建清单：Inventories → “+” → 选 Inventory → NAME=
Mail Servers、ORGANIZATION=Default（名称与组织必填）→ SAVE。 - 加裸主机：清单详情页 HOSTS → “+” → HOST NAME=
london1.example.com → SAVE。 - 建父组：GROUPS → “+” → NAME=
east → SAVE。 - 建子组：点
east 进组详情 → GROUPS → “+” → New Group → 先建 southeast、再重复建 northeast（组中组结构成型）。 - 往子组加主机：southeast 组内 HOSTS → “+” → New Host → 加
raleigh1.example.com、atlanta1.example.com；northeast 组内同样加 boston1.example.com。 - 完成态：清单总览页看到全部 4 台主机（1 台裸机 + 2 台 southeast + 1 台 northeast）；Groups 视图查看组层级，点 east 能看到两个子组及其成员。
- UI 小抄（考点级操作）：文档栈图标＝把主机/组移动到别的组或清单顶层；主机旁垃圾桶＝直接从该清单所有组中删除；组旁垃圾桶＝删除前二选一：① 删除该组全部子项；② 把子项**提升（promote）**到父级对象（如删 east 时把 southeast/northeast 提升为清单顶层组）。
| 角色 | 能力 |
|---|
| Admin | 清单完全权限（删除/修改），并隐含 Use、Ad Hoc、Update 三种角色权限 |
| Use | 在 job template 资源里使用该清单（控制作业跑在哪份清单上） |
| Ad Hoc | 用该清单执行 ad hoc 命令 |
| Update | 从外部数据源更新动态清单（动态清单章节再展开） |
| Read | 只读查看清单内容 |
- 初始可达性：清单刚创建时，仅“所属组织的 Admin / Inventory Admin / Auditor”能访问；其余访问权限必须显式给用户/团队配置。
- 三级变量都能写 YAML 或 JSON 到 VARIABLES 字段：Inventory 变量作用于清单内所有主机；Group 变量作用于该组所有主机；Host 变量只作用于单台主机。建好后点铅笔（Edit）图标可改。
- IMPORTANT（考点）：job template 的 extra variables 与 playbook 变量优先级都高于 inventory 变量——清单里写的变量可被更高优先级的变量覆盖。（补充：Ansible 常规层级为 host 变量 > group 变量 > inventory 变量；在 Tower 里 job template 层还能再往上覆盖。）
lab host-inventory start 准备环境；admin/redhat 登录 Tower。- 建 Inventory
Prod（Default 组织，描述 Production Inventory）→ 组 prod-servers → 主机 servere.lab.example.com。 - 授 Operations 团队 Admin 角色 on Prod（Inventory → 铅笔 → PERMISSIONS → “+” → TEAMS 勾 Operations → 角色 Admin → SAVE）。
- 用
oliver（Operations 的 Member，redhat123）验证：能查看 Prod 内容，且能在 prod-servers 组里新增主机 serverf.lab.example.com（团队拿到 Admin → 成员可管理）。 - admin 再授 Developers 团队 Use 角色 on Test Inventory；用
daniel（Developers 的 Admin，但清单只拿到 Use）验证：能看不能改 Test Inventory。
- 要点（考点）：团队 Admin ≠ 资源 Admin；daniel 虽是团队 Admin，能用的只是被授的 Use 角色——对应真实场景“开发可查看测试环境主机清单、但不能修改清单”。
- 定义：Credential 是 Tower 用来向远端系统认证的对象，可包含密码、SSH 私钥等 secret 或其它访问所需信息。
- 安全模型：凭据的密码/密钥在存入 Tower 数据库之前加密；Web UI 无法取回明文；用户/团队可被授权“使用”凭据，但看不到其中的 secret → 用户换团队/离职时无需重配 key 或重改系统账号；Tower 在需要时内部解密并把凭据直接交给 SSH 等程序。
- IMPORTANT（考点）：敏感认证数据一旦录入并加密，不能通过 Tower Web UI 再取回解密形式——忘密码只能重建凭据。
| 类型 | 用途 |
|---|
| Machine | 登录受管主机跑 playbook 并做提权（本章主角） |
| Network | 用 Ansible 网络模块管理网络设备 |
| Source Control (SCM) | 供 Project 从远端 VCS（Git/SVN/Mercurial）克隆/更新项目材料 |
| Vault | 解密项目文件中被 Ansible Vault 保护的敏感信息 |
| Inventory（动态源） | 从内置动态清单源拉取更新：AWS、VMware vCenter、Red Hat Satellite 6、CloudForms、GCE、Azure Resource Manager、OpenStack 等各有独立类型 |
| Custom | 管理员用 YAML 定义的自定义凭据类型（详见 Tower User Guide） |
- 任何用户都能创建凭据并成为其 owner；未挂组织 = Private Credential：只有 owner 与 System Administrator / System Auditor 两个 singleton 角色可用（auditor 可看到），其它用户/团队不能被授角色。
- 挂到组织 = Organization Credential：只有 System Administrator 与“该组织 Admin”能创建；组织内用户/团队可被授予角色共享使用。
- 小结：private 只归 owner + 系统 singleton；org credential 才可共享。
- IMPORTANT：Tower Admin 可以把已有 private credential 改挂到一个组织，一步转成 Organization Credential。
| Tower 字段 | 对应概念 | 说明 |
|---|
| NAME | - | 必填；TYPE 下拉选 Machine |
| ORGANIZATION | - | 有组织 Admin 权限才出现该字段；不设＝创建 private credential |
| USERNAME | remote_user | 登录受管主机的用户名 |
| PASSWORD | - | SSH 密码；若用私钥认证可留空 |
| SSH PRIVATE KEY | - | SSH 私钥文本（可粘贴，GNOME3 的 Firefox 可把私钥文件拖进输入框）；保存后显示 ENCRYPTED |
| PRIVATE KEY PASSPHRASE | - | 私钥本身被 SSH 加密保护时的口令，否则留空 |
| PRIVILEGE ESCALATION METHOD | become_method | 提权方式下拉（如 sudo），会联动出现下面两个字段 |
| PRIVILEGE ESCALATION USERNAME | become_user | 提权目标用户（如 root） |
| PRIVILEGE ESCALATION PASSWORD | - | sudo 密码，无密码可留空 |
| 角色 | 能力 |
|---|
| Admin | 凭据完全权限：删除/修改 + 可在 Job Template 中使用 |
| Use | 可在 Job Template 中使用该凭据 |
| Read | 可查看凭据详情，但仍不能解密其 secret |
- 前提：private credential 不能授角色给别人；要共享必须先变 Organization Credential（见上）。
- 新建 Organization Credential 后：初始只有 owner 与“该组织 Admin/Auditor”可访问；保存之后才能继续加角色；角色在凭据编辑器的 PERMISSIONS 里加（也可从用户/团队管理页反向添加）。
- 编辑：Credentials → 铅笔 → 修改字段 → SAVE（创建/编辑的角色要求一致：private＝owner 本人；org＝有该凭据 Admin 角色）。
- 凭据由 Tower 保管、使用者不知道秘密：把“重启 Web 应用恢复服务”委托给 Tier1 支持。支持团队用共享账号
support（带口令私钥 + sudo 密码）跑 playbook；管理员建 Organization Credential 存放 username/私钥/口令/sudo 信息并授 Use 角色——支持人员能跑作业，但永远看不到私钥口令与 sudo 密码。 - 敏感密码不存 Tower、运行时交互提示：财务合规禁止存储账号密码时，用 Private Credential 只存 SSH 用户名，PASSWORD 勾选 Prompt on launch——作业启动时由用户交互输入密码。
- IMPORTANT（考点）：配置为交互提示的凭据不能用于定时作业（scheduled jobs）——Tower 定时无人值守时无法提供交互输入。
- admin 登录 → Credentials → “+” → 建
Operations：Default 组织 / Machine 类型 / USERNAME=devops / PASSWORD=redhat / 提权 sudo→root / 提权密码 redhat → SAVE。 - 授 Operations 团队 Admin 角色 on Operations 凭据 → 用
oliver（Operations Member）登录：能打开凭据并修改（团队拿到 Admin）。 - 授 Developers 团队 Use 角色 on Operations 凭据 → 用
daniel（Developers 团队 Admin）登录：不能修改该凭据（只有 Use）。
- 与 8.1 GE 同一套“团队 Admin ≠ 资源 Admin”的验证逻辑，只是对象换成 Credential。
- 准备：
lab host-review start（如需要重置环境）；admin/redhat 登录 Tower。 - 建 Inventory
Dev（Default）→ 组 dev-servers → 主机 servera.lab.example.com、serverb.lab.example.com。 - 授 Developers 团队 Admin 角色 on Dev Inventory。
- 建 Credential
Developers：Default / Machine / USERNAME=devops / PASSWORD=redhat / 提权 sudo→root / 提权密码 redhat。 - 授 Developers 团队 Admin 角色 on Developers Credential。
- Evaluation：
lab host-review grade，修复报错后重跑直到成功（最后可 lab host-review finish）。
- Inventory 资源用来管理“主机/主机组 + 清单变量”；可配多份清单，用角色控制谁能用、谁能管某份清单；静态清单可在 Web UI 手工配置。
- Credential 存放机器、网络设备、源码控制与动态清单更新的认证信息；Machine Credential 让 Tower 登录受管主机并提权执行 playbook。
- 挂在 Organization 的凭据可通过给用户/团队授角色共享；没挂组织的 private 凭据仅 owner + Tower singleton 角色可用，不共享——除非管理员把它挂到组织。
| 场景 | 操作/命令 |
|---|
| 建清单/组/主机 | Inventories → “+” → Inventory；组内 GROUPS / HOSTS → “+” → New Group/New Host |
| 授清单角色 | Inventories → 铅笔 → PERMISSIONS → “+” → TEAMS/USERS → 选角色 |
| 查看许可节点数 | Settings → License（HOSTS AVAILABLE / REMAINING） |
| 移动/删除清单对象 | 文档栈图标移动；主机/组旁垃圾桶（组删除可删子项或提升子项） |
| 建机器凭据 | Credentials → “+” → TYPE=Machine → 填 USERNAME/PASSWORD/私钥/提权字段 |
| 授凭据角色 | Credentials → 铅笔 → PERMISSIONS → “+” → TEAMS/USERS → Admin/Use/Read |
| 敏感密码交互输入 | 凭据 PASSWORD 勾 Prompt on launch（不可用于定时作业） |
| GE1 环境 | lab host-inventory start |
| 章节 Lab | lab host-review start / grade / finish |
| 英文 | 中文速记 |
|---|
| static inventory | 静态清单（Web UI/文件手动维护的主机与组） |
| host group / child group | 主机组 / 子组（[east:children] 组中组） |
| implicit groups: all / ungrouped | 隐式组：全部主机 / 未分组主机 |
| Inventory object | Tower 里的清单对象（属于某组织） |
| License node counting | 许可节点计数（同名主机算 1、大小写敏感） |
| HOSTS AVAILABLE / REMAINING | 许可可用/剩余主机数 |
| Inventory Admin/Use/Ad Hoc/Update/Read | 清单五角色（Admin 隐含后三者） |
| inventory/group/host variables | 清单/组/主机三级变量（extra vars 与 playbook vars 优先级更高） |
| Credential | 凭据（认证远端系统的 Tower 对象，密文存储） |
| Machine Credential | 机器凭据（SSH 登录 + 提权） |
| Network / SCM / Vault credential | 网络设备 / 源码控制 / Vault 凭据类型 |
| dynamic inventory credential | 动态清单源凭据（AWS/vSphere/Satellite…） |
| custom credential type | YAML 自定义凭据类型 |
| private credential | 私有凭据（仅 owner + System Admin/Auditor） |
| Organization Credential | 组织凭据（可授角色共享） |
| remote_user / become_method / become_user | ansible.cfg 对应：登录用户 / 提权方式 / 提权用户 |
| SSH PRIVATE KEY → ENCRYPTED | 私钥字段保存后显示 ENCRYPTED |
| Credential Admin / Use / Read | 凭据三角色 |
| Prompt on launch | 运行时交互提示密码（不可用于定时作业） |
| scheduled job | 定时作业（不能配合交互提示凭据） |
- 教材 INI 例子里
[east:children] 表示什么？all 与 ungrouped 两个隐式组分别装什么主机？ - License 节点计数：同名主机怎么算？为什么它和 Dashboard 的 Hosts 计数可能不一致？大小写敏感吗？
- 建一份“组中组”清单最少几步？删除一个含子组的组时 UI 给哪两种选择？
- Inventory 五角色各管什么？为什么 Admin 能“用”也能“更新”？新建清单初始谁能访问？
- Inventory / Group / Host 三级变量怎么设？谁可以覆盖 inventory 变量（写清优先级结论）？
- GE1 里 daniel 是 Developers 团队 Admin，为什么在 Test Inventory 上“能看不能改”？这个设计对应什么真实场景？
- Private Credential 与 Organization Credential 的创建者、可见/可用范围、能否授角色有什么区别？private 怎么变成 org credential？
- Machine Credential 字段里 USERNAME、PRIVILEGE ESCALATION METHOD、PRIVILEGE ESCALATION USERNAME 分别对应 ansible.cfg 的哪个参数？
- 两个典型场景分别用哪种凭据策略？为什么“Prompt on launch”的凭据不能用于 scheduled job？
- SUMMARY 七条里，哪几条是“Inventory 管理”、哪几条是“Credential 管理”？用自己的话说明“为什么机器凭据的 secret 不需要因人员变动而重配”。
