mysql如何为CI/CD流水线创建账号_分配自动化部署专用权限

MySQL CI/CD 自动化部署账号权限配置最佳实践：遵循最小权限原则，保障数据库安全

MySQL 创建最小权限部署账号要避开 root 和 ALL PRIVILEGES

为 CI/CD 流水线直接分配 root 账号或使用 GRANT ALL PRIVILEGES 授权，等同于将数据库最高控制权暴露在构建日志中，是严重的安全隐患。一旦配置泄露或构建服务器被入侵，数据库将面临巨大风险。自动化部署账号的核心权限应严格限定于“执行预定义的 SQL 变更脚本”和“查询必要的版本或状态信息”，任何超出此范围的权限都应被禁止。

• 严格限制网络访问来源：仅授权来自本地（localhost）或指定堡垒机/跳板机的 IP 地址进行连接。务必避免使用类似 'deploy'@'%' 的通配符授权，防止来自任意主机的连接尝试。
• 彻底剥离高危管理权限：诸如 CREATE USER、GRANT OPTION、DROP DATABASE、FILE 等具备账户管理、权限授予或数据破坏能力的权限，绝对不可授予部署账号。自动化脚本不应拥有创建用户或删除数据库的能力。
• 精确匹配迁移工具所需权限：若使用 Flyway、Liquibase 等数据库迁移工具，应仅授予其对目标数据库内特定对象（如表、视图、存储过程）的必要权限，如 SELECT、INSERT、UPDATE、CREATE、ALTER 等，并精确到对象名称。
• 审慎授予系统状态查询权限：当部署前置检查需要执行 SHOW DATABASES 或查询 SELECT VERSION() 时，需显式授予对 mysql 系统库中特定表（如 db、user）的 SELECT 权限。但必须确保不授予访问密码哈希字段（如 authentication_string）的权限。

GRANT 语句必须按对象粒度写，不能靠 database.* 模糊授权

使用 GRANT SELECT, INSERT ON myapp.* TO 'ci_deploy'@'10.20.30.40' 这类数据库级通配符授权，虽然简化了操作，却严重违背了最小权限原则。未来在 myapp 数据库下新增的任何表都会自动继承授权，导致权限范围不可控。CI/CD 账号能操作的具体数据库对象，必须通过显式授权明确列出。

• 为版本元数据表单独授权：针对 Flyway 使用的 flyway_schema_history 表，需单独授予 SELECT、INSERT、UPDATE 权限，确保迁移历史记录可正常读写。
• 严格控制业务表操作权限：对 users、orders 等核心业务表，仅授予迁移脚本实际执行所需的 DML 权限（通常是 SELECT、INSERT、UPDATE）。DELETE 权限仅在脚本明确包含数据回滚逻辑时才考虑授予。
• 精确授予存储过程执行权：若部署涉及存储过程，需使用 EXECUTE 权限，并精确指定到过程名，例如：GRANT EXECUTE ON PROCEDURE myapp.calc_revenue TO 'ci_deploy'@'10.20.30.40'。
• 避免不必要的权限刷新：在 MySQL 5.7 及以上版本中，执行 GRANT 语句后权限通常立即生效。手动执行 FLUSH PRIVILEGES 可能掩盖授权语句本身的语法错误，非必要不建议使用。

密码管理别硬编码，用 MySQL 8.0+ 的 caching_sha2_password 插件 + 外部凭据注入

在 CI/CD 配置文件中硬编码数据库密码是极高风险行为。同时，MySQL 5.7 默认的 mysql_native_password 认证插件可能与新版客户端驱动存在兼容性问题。最佳实践是强制使用 MySQL 8.0 引入的更安全认证插件 caching_sha2_password，并配合外部凭据管理机制。

• 创建账号时指定安全插件：创建用户时即强制使用新式认证：CREATE USER 'ci_deploy'@'10.20.30.40' IDENTIFIED WITH caching_sha2_password BY '临时占位密码'。
• 实现凭据完全外部化：在 CI/CD 流程中，通过环境变量（如 MYSQL_DEPLOY_PASSWORD）或 secrets 管理工具传递真实密码，由流水线任务动态注入数据库连接配置，确保密码不写入任何配置文件、代码仓库或日志文件。
• 集成平台秘密管理服务：在 GitHub Actions 中应使用 secrets；在 Jenkins 中应使用 Credentials Binding 插件或 HashiCorp Vault 集成。务必验证密码不会通过 env 命令或调试信息泄露。
• 预先测试连接与兼容性：在配置完成后，使用部署账号及注入的凭据测试数据库连接。可添加 --connect-expired-password 等参数，验证密码过期策略是否会影响自动化流程。

权限验证要用真实部署流程跑，不是只连上就完事

仅通过 mysql -u ci_deploy -p 成功连接数据库，远不足以证明权限配置正确。实际部署中常因缺少对特定元数据表的查询权限而失败，例如 Flyway 报错 Access denied for INSERT into flyway_schema_history。验证权限有效性的唯一可靠方法，是模拟完整的 CI/CD 部署链路进行端到端测试。

• 执行完整的部署模拟测试：在独立的测试环境或 CI 服务器上，使用配置好的部署账号，完整运行一次数据库迁移命令（如 flyway migrate -user=ci_deploy 或 liquibase update），观察全流程是否出现权限不足的错误。
• 启用数据库查询日志进行诊断：在测试期间，临时启用 MySQL 通用查询日志（SET GLOBAL general_log = 'ON'），捕获部署工具实际执行的所有 SQL 语句。这有助于发现那些工具隐式执行的、容易被忽略的元数据查询（如 SHOW CREATE TABLE、SELECT FROM INFORMATION_SCHEMA），并据此补充授权。
• 注意环境配置差异的影响：检查并确保 CI 环境与生产环境的 SQL 模式（sql_mode）、时区等设置一致。例如，CI 环境中若启用了 STRICT_TRANS_TABLES，可能导致数据插入因字段超长而失败，这种错误容易被误判为权限问题。

一个至关重要且极易遗漏的授权项是：授予对 information_schema 数据库的 SELECT 权限。绝大多数 ORM 框架和数据库迁移工具在运行时，都会查询此系统库以获取表结构、列信息等元数据。由于 information_schema 不属于用户数据库，需要单独授权：GRANT SELECT ON information_schema.* TO 'ci_deploy'@'10.20.30.40'。在本地使用高权限账号开发时一切正常，但在权限受限的 CI 环境中，缺少此授权往往会导致工具静默失败或行为异常，需特别关注。