Linux权限管理是CI/CD流水线中必须卡住的关卡，需嵌入每个环节的动作上下文，按角色+动作+目标三要素锁定权限，禁用明文密钥，强制声明并版本化权限配置，实现可声明、可验证、可审计。
Linux权限管理不是配置项，而是流水线里必须卡住的关卡。它不靠人工检查，而要嵌进CI/CD每个环节的动作上下文里——谁在什么环境、以什么身份、执行什么命令、访问什么路径，全部可声明、可验证、可审计。
权限最小化必须落地到角色与动作绑定
给CI/CD账号配root权限等于交出整套生产系统的物理钥匙。真正有效的做法是把权限切碎，按角色+动作+目标三要素锁定：
- Jenkins中用Role-based Authorization Strategy插件定义dev、release-manager、infra-admin三类角色，每类角色只允许触发明确白名单内的Job
- Terraform执行限定在特定模块：
terraform apply -target=module.nginx，禁止全局apply - Ansible Playbook强制指定
become_method: sudo和become_flags: "-n"，并配合/etc/sudoers.d/ansible-restricted限制可用命令范围 - 敏感操作如数据库迁移、密钥轮转必须设人工审批门禁，且审批人与执行人不能为同一账号
凭证与密钥不走明文传递链路
环境变量里塞AWS_ACCESS_KEY_ID是高危操作——一旦日志开启set -x或debug模式，密钥就裸奔。生产环境必须切断明文注入路径：
- GitHub Actions中不设
secrets.AWS_ACCESS_KEY_ID，改用hashicorp/vault-action@v2获取短期令牌 - AWS场景优先使用
aws_role_arn，Azure场景用azurerm_workload_identity_certificate实现工作负载身份认证 - 本地Ansible调用AWS CLI时，通过
--profile隔离凭证，避免默认profile污染 - 所有密钥类变量统一用
ansible-vault加密，存入group_vars/all/vault.yml
权限声明需纳入IaC与版本控制
权限不是部署后手动chown/chmod，而应作为基础设施代码的一部分，在Terraform或Ansible中显式声明：
- Terraform中为EC2实例附加IAM Role，而非在userdata里写
aws configure - Ansible中用
file模块设置文件属主、属组、mode，并配合owner: www-data、group: www-data、mode: '0644'等字段固化权限状态 - 所有权限相关配置随代码提交Git，变更可追溯、可diff、可回滚
- 用
ansible-lint检查shell模块，拦截rm -rf /、eval $()、curl | bash等危险模式
目录与文件权限需区分作用对象
r/w/x对文件和目录意义完全不同，自动化脚本里常因混淆导致故障：
- 文件的
x表示可执行，目录的x表示可进入（即cd权限），缺了就无法ls子目录内容 - 目录的
w决定能否创建/删除文件，与文件自身权限无关；一个用户即使对某文件有rw权限，若所在目录无w权限，也无法删它 - 部署时常用
copy模块传配置文件，但必须额外加file模块确保/etc/nginx/conf.d/目录有o+x（其他用户可进入），否则Nginx worker进程可能因无法读取子配置而启动失败 - 日志目录如
/var/log/myapp需保证属组可写+setgid（2755），让不同服务进程写入日志时自动继承父目录组
