容器本身不防sql注入，防护必须在应用层落地：严格使用参数化查询（如preparedstatement）、按容器角色最小化数据库账号权限、对环境变量等所有输入源同样执行类型校验与参数绑定，并通过结构化日志监控实际sql执行行为。
容器内应用必须用参数化查询，不能靠镜像层过滤
容器本身不防SQL注入，它只是运行环境。你把一个拼接SQL的PHP脚本打包进Docker镜像，哪怕加了nginx或mod_security，只要应用代码里还存在"SELECT * FROM users WHERE name = '" + userInput + "'"这种写法，漏洞就还在。参数化查询必须在应用代码层落地，不是靠容器网络策略或中间件拦截能兜底的。
常见错误是以为加了WAF容器（比如coraza/waf）就万事大吉——它只能拦住明显特征的攻击载荷，对布尔盲注、编码绕过、合法字段里的恶意逻辑完全无效。真正起作用的永远是PreparedStatement、cursor.execute("SELECT * FROM t WHERE id = %s", (user_id,))这类绑定行为。
数据库连接账号权限必须按容器角色最小化
每个容器实例连接数据库时，使用的账号权限要和它实际需要的操作严格对齐。比如只读API服务的容器，应使用仅带SELECT权限的账号；后台任务容器若需写入，也只授予对应表的INSERT/UPDATE，绝不能给DROP或EXECUTE。
- 避免所有容器共用一个高权限
root或admin账号 - Kubernetes中通过
Secret挂载不同权限的连接凭证，而不是硬编码在Dockerfile里 - MySQL 8.0+支持角色（
CREATE ROLE app_reader），比直接授予权限更易维护
环境变量传参不等于安全，仍需校验与绑定
有人觉得“我把SQL语句写死在代码里，只把值用os.getenv("USER_ID")传进来，总比前端输入安全吧？”——错。环境变量只是另一种外部输入源，同样可能被篡改（比如kubectl set env误操作、CI/CD流水线注入、配置中心被劫持）。它不自动获得信任豁免。
所以即使参数来自ENV，也要走和用户输入一样的流程：
- 类型检查（比如确认USER_ID是整数）
- 长度限制（避免超长字符串触发缓冲区异常）
- 最终仍必须用参数化方式执行，不能拼接进SQL字符串
日志和监控要区分容器与SQL行为
容器日志（docker logs或kubectl logs）默认看不到SQL实际执行内容。想发现可疑注入尝试，得让应用把PreparedStatement的绑定参数和执行耗时一起打到结构化日志里，再接入ELK或OpenTelemetry做聚合分析。
关键点：
- 不记录原始SQL模板里的占位符（如WHERE id = ?），而要记录绑定后的实际值（id = 12345）
- 对高频失败查询（如WHERE username = 'admin' OR '1'='1'）设告警阈值
- 数据库侧开启general_log太重，建议用slow_query_log配合long_query_time=0抓全部查询，但只保留敏感操作日志
真正的难点从来不在“怎么配容器”，而在于开发阶段是否坚持把每一条SQL都拆成模板+参数两部分——无论输入源是HTTP请求、消息队列、还是环境变量。任何试图在部署层打补丁的做法，都会在某次紧急上线时被绕过。
