MySQL权限管理可自动化赋权,但须严格区分场景:标准化只读、CI/CD测试、规范命名开发账号可自动;SUPER等高危权限及通配符主机组合必须人工审批,并硬编码拒绝。
能,但必须严格区分场景。自动化赋权不是“写个循环执行 GRANT 就完事”,而是要控制粒度、收敛入口、避免权限扩散。生产环境直接用脚本批量跑 GRANT,90% 的事故源于没校验账号是否存在、权限是否已存在、目标库表是否真实存在。
适合自动化的:标准化只读账号(如 app_ro@'%' 对固定库的 SELECT)、CI/CD 临时测试账号(生命周期明确、IP 受控)、按命名规范生成的开发库账号(如 dev_)。project_name@'10.%.%.%'
必须人工审批的:SUPER、REPLICATION SLAVE、PROCESS、对 mysql 系统库的写权限、任意库的 ALL PRIVILEGES、通配符主机(如 '%')搭配高危权限。
mysql.audit_grant_log),包含操作人、时间、SQL、执行结果GRANT ... ON 的库名或用户名,必须先通过白名单正则校验(例如只允许 ^[a-z][a-z0-9_]{2,30}$)核心是分离“策略定义”和“SQL 执行”。不要让脚本直接连数据库执行 GRANT,而是先输出 SQL 文件供审核,再由 DBA 或 CI 流水线触发执行。
import redef gen_grant_sql(username, host, db_pattern, privs=('SELECT',)):
白名单校验
if not re.match(r'^[a-z][a-z0-9_]{2,30}$', username): raise ValueError('Invalid username format') if not re.match(r"^'[0-9.]+%?'$|^'localhost'$", host): raise ValueError('Invalid host format') if not re.match(r'^[a-z][a-z0-9_]*$', db_pattern): raise ValueError('Invalid db name pattern') priv_list = ', '.join(privs) return f"GRANT {priv_list} ON `{db_pattern}`.* TO `{username}`@{host};"示例:生成只读账号
print(gen_grant_sql('bi_report', "'
10.20.%.%'", 'sales_db'))
输出:GRANT SELECT ON
sales_db.* TObi_report@'10.20.%.%';
mysql-connector-python 或 pymysql 执行语句,避免误执行db_pattern 不接受 * 或 %,防止生成 ON *.*
WITH GRANT OPTION,需显式传参开启,且仅限特定角色角色是实现权限自动化的关键基础设施。比起给每个用户重复赋权,应该先建好角色(如 role_analytics_reader),再把用户加入角色——这样权限变更只需改角色,无需遍历用户。
注意 MySQL 8.0 角色默认不可激活,新用户需显式 SET DEFAULT ROLE,否则登录后无权限:
-- 创建角色并授权 CREATE ROLE IF NOT EXISTS role_analytics_reader; GRANT SELECT ON `analytics_*`.* TO role_analytics_reader;-- 给用户赋予角色(非执行权限!) CREATE USER 'dash_user'@'10.30.%.%' IDENTIFIED BY 'pwd'; GRANT role_analytics_reader TO 'dash_user'@'10.30.%.%';
-- 必须这一步,否则用户登录后权限为空 SET DEFAULT ROLE role_analytics_reader TO 'dash_user'@'10.30.%.%';
role_[a-z]+_[a-z]+)SET DEFAULT ROLE 不能省略,且必须在 GRANT ... TO 之后执行权限自动化最易被忽略的点:权限回收比授予更难自动。没人会写脚本定期删账号,但僵尸账号积累到几十个时,DROP USER 就变成高危操作。真正稳定的自动化,一定包含账号生命周期管理(如对接 LDAP/AD 过期时间、GitLab Group 成员变更 webhook),而不是只做“加法”。