Linux 运维权限分级设计方案

不能直接用root做日常运维，因其权限过高易致误操作引发故障，且无法审计操作人、违反最小权限原则与合规要求；应禁用root远程登录，全员使用个人账号+sudo提权，并通过sudoers细粒度管控命令白名单、强制日志审计、容器与云环境适配权限策略。

为什么不能直接用 root 做日常运维

root 权限等于系统完全控制权，任何误操作（比如 rm -rf /、删错配置文件、改错 SElinux 上下文）都可能引发服务中断或数据丢失。更关键的是，多人共用 root 无法审计具体是谁执行了哪条命令，违反最小权限原则和等保/合规基本要求。

实操建议：

• 禁用 root 远程 ssh 登录：修改 /etc/ssh/sshd_config 中的 PermitRootLogin no，然后 systemctl restart sshd
• 所有运维人员必须使用个人账号登录，再通过 sudo 提权执行特定命令
• 不设置 root 密码，或仅在应急恢复盘中保留离线备份

如何用 sudoers 实现细粒度命令白名单

sudoers 不是简单给用户加 ALL=(ALL) ALL，而是按角色定义可运行的命令集合。例如数据库管理员只能重启 mysql、查看慢日志，但不能 touch 系统配置或杀任意进程。

实操建议：

• 用 visudo 编辑，避免语法错误锁死 sudo 功能
• 用 Cmnd_Alias 分组命令，例如：

  Cmnd_Alias MYSQL_CMD = /bin/systemctl restart mysql, /usr/bin/mysqladmin ping, /bin/journalctl -u mysql

• 为角色分配别名：

  %dba ALL=(root) NOPASSWD: MYSQL_CMD

  （注意 NOPASSWD 仅对可信高频操作启用）

• 禁止 shell 逃逸：显式拒绝 /bin/bash、/bin/sh、/usr/bin/python 等交互式环境

哪些场景必须配合 sudo + 日志审计才能闭环

光有权限分级不够，得知道“谁在什么时候干了什么”。默认 sudo 日志只记到 /var/log/secure 或 /var/log/auth.log，但内容简略，且容易被高权限用户清除。

实操建议：

• 强制记录命令参数：在 /etc/sudoers 加 Defaults log_input, log_output，并配置 Defaults iolog_dir=/var/log/sudo-io/%{user}
• 把日志发到远程 syslog 服务器（如 rsyslog + TLS），防止本地篡改
• 用 sudo -l 定期检查各账号实际可用命令，避免 alias 被覆盖或配置漂移
• 对敏感命令（如 /usr/bin/passwd、/sbin/usermod）启用双人复核机制，即需两个授权账号先后输入密码

容器与云环境下的权限分级怎么不踩坑

传统 sudo 方案在容器里失效——容器内通常没 systemd、没完整 sudoers、甚至没 /etc/sudoers。K8s 的 RBAC 也只管 API 层，不管容器内进程权限。

实操建议：

• 宿主机仍用严格 sudo 分级；容器内用非 root 用户启动（USER 1001），必要时用 securityContext.runasUser 限制
• 避免在容器中安装 sudo；如真需提权（如调试），挂载只读的 /host/usr/bin 并限定路径白名单
• 云平台（如阿里云 RAM、AWS IAM）要和本地 sudo 角色对齐：例如 IAM 中的 “DBA” 策略，对应本地 %dba 组的 sudo 权限
• ansible 等自动化工具必须用普通用户连接，提权走 become_method: sudo，且 become_user 明确指定为服务账户（如 mysql），而非 root

权限分级不是一劳永逸的配置，真正的难点在于持续同步——人员变动、服务迁移、新组件上线都会绕过原有规则。最常被忽略的是日志留存周期和跨系统角色映射，这两处一旦松动，整个分级体系就只剩形式。