4.3 动态性与安全控制

4.3 动态性与安全控制

本节摘要：两个"进阶必答题"：机器列表如何跟随环境自动变化（动态清单的三个来源），秘密数据如何在仓库与执行链路中保持密文（Vault 的四种用法与提权策略）。本节的目标状态很明确：仓库可以给全团队看，秘密只出现在该出现的地方。

动态清单的三级演进

静态清单文件在机器列表稳定时够用，环境一旦"活"起来就要升级。第一级，静态文件拆分：按环境与租户拆多个清单文件、清单目录合并加载（3.1 节的布局）——解决的是组织问题，不是新鲜度问题。第二级，动态清单插件：配置文件声明来源与筛选条件，运行时实时拉取。第三级，对接 CMDB 或内部资产系统：机器的业务属性（负责人、服务等级、维护窗口）从资产系统来，自动化系统不再自建机器档案。

以主流云的动态清单插件为例，配置声明"按标签筛选实例并按标签自动分组"：

# inventory/aws.yml —— 动态清单插件配置（示意）
plugin: amazon.aws.aws_ec2
regions:
  - cn-north-1
filters:
  instance-state-name: running
  tag:Env: prod
keyed_groups:
  - key: tags.Role        # 按角色标签自动建组
    prefix: role
  - key: tags.Env
    prefix: env
compose:
  ansible_host: private_ip_address
​

运行 ansible-inventory -i inventory/aws.yml --graph 即可验证分组结果。三个实践要点：一是 compose 字段把云属性映射成连接参数，免去在云控制台与清单之间双份维护；二是 keyed_groups 的分组规则要与剧本的 hosts 模式对齐（剧本写 role:web，清单就按 tags.Role 分组）；三是动态清单的缓存——插件的缓存窗口内重复运行不会反复拉 API，既省配额也提速，但排障时要记得 --no-cache 强刷一次。

Vault：仓库里的秘密管理

Vault 是引擎自带的加密体系，不引入外部组件即可实现"明文仓库、密文秘密"。四种用法按粒度递进。

用法一，整文件加密：ansible-vault create secrets/prod.yml 创建即加密，编辑用 edit，查看用 view。整文件方式简单直接，缺点是 diff 完全失效——评审时看不出改了什么，适合改动稀少的大块秘密文件。

用法二，加密单个变量（加密字符串）：变量级加密让同一文件里明文与密文共存，diff 部分可用：

ansible-vault encrypt_string 'S3cret!Value' --name db_password
​

把输出的密文块粘进 group_vars 文件，普通变量照常明文。这是日常最推荐的方式。

用法三，变量引用加密文件：明文变量文件里用 lookup 引用密文文件，阅读者看得到变量名与结构，看不到值：

# group_vars/prod/db.yml —— 明文
db_password: "{{ lookup('ansible.builtin.file', 'secrets/prod-db.txt') }}"
​

用法四，只加密真正敏感的部分并配合外部秘密系统：Vault 体系之外的正规路线是把秘密放进专门系统（如企业已有的密钥管理服务），剧本运行时通过 lookup 插件拉取。仓库里连密文都不存，权限与审计交给专门系统——大型组织的推荐终态。

口令管理是 Vault 实践的另一半：加密口令从哪来？开发机用口令文件（权限 600，不进仓库），CI 用环境变量传入。生产环境的口令轮换策略要有书面约定——加密不是备份策略的替代品，密文文件丢了就是真丢了。

提权与身份：become 的工程化用法

受管机上的操作权限通过 become 体系表达。基础用法是全局或任务级 become: true，默认以 root 执行。工程化关注三点。其一，提权身份精确化：become_user 指定具体用户（如应用属主），而不是一律 root；配合受管机上 sudoers 的细粒度授权（允许 deploy 用户免密以 appuser 身份执行特定命令），把"能做什么"限制在剧本真实需要的范围。其二，提权口令：sudo 需要密码的环境用 --ask-become-pass 交互输入，自动化流水线里则走免密 sudo 授权。其三，连接身份与提权身份分离：SSH 登录用个人账号（审计可归因），提权用服务账号——出事故时日志里查得到"谁在什么时候提权做了什么"。

图 4-3：秘密数据从仓库到目标机的加密路径

动态与安全的交叉检查

把本节两半合起来的一组自检问题，建议纳入季度例行审查：动态清单的筛选条件会不会把不该管的机器卷进来（标签打错的实例）？加密文件的口令在多少地方有副本（口令扩散面）？提权授权的最小化是否还成立（sudoers 文件随时间膨胀是常态）？debug 任务有没有可能把秘密值打印进日志（debug 输出会进 CI 日志存档，no_log: true 用于含秘密的任务）？

一份安全自检的剧本化清单

安全控制散在前面各节，这里收拢成一份可执行的季度自检清单，每项都注明工具与判据。第一项，明文秘密扫描：在仓库全量文本中扫描高熵字符串与常见密钥格式（私钥头、连接串模式），命中即处理——加密体系防的是未来的明文，扫描防的是已发生的。第二项，提权面审计：汇总所有受管机的 sudoers 授权，与剧本实际用到的提权操作对照，多出的授权逐个追问来源。第三项，口令轮换核验：加密文件与口令文件的最近修改时间、轮换记录台账三方对表。第四项，动态清单边界核验：抽查清单筛选条件覆盖与排除的机器样本，确认没有误纳管（打错标签的开发机混进生产组是经典事故）。第五项，no_log 覆盖检查：grep 全部含敏感参数的任务，确认已加 no_log。五项全部可以脚本化，其中扫描与审计两项建议直接进流水线例行跑。安全工作的形态从来不是一次性的坚固，而是周期性的自证——清单化的意义就是让自证的成本低到不会跳过。