★ FEATURED ARTICLE 上周安全扫描报告递到手里的时候我才意识到问题比想象中严重内网一台机器上跑着的Kettle到MySQL的3306端口竟然有人在链路上抓到了明文SQL。查了半天根因问题根本不在什么高深漏洞就是Kettle默认没有开启MySQL的SSL加密连接。当天我就把整改任务领了从证书生成、MySQL服务端配置到Kettle侧的驱动参数完整走了一遍。这篇就是基于那次实操整理出来的专门写给用Kettle做数据抽取同步、又需要过安全审计或等保要求的朋友。不管你是刚接触Kettle的新手还是已经被各种SSL报错磨了几个小时的苦主按下面的步骤走基本能少踩一半的坑。1. 先搞清楚Kettle连MySQL时SSL到底在保护什么1.1 MySQL SSL连接的握手过程很多搞ETL的同事一听“SSL”就头疼觉得这是DBA的事。其实拆开看不复杂。MySQL的SSL加密连接本质就是客户端Kettle跑的Java进程和MySQL服务器在TCP三次握手之后再做一次TLS握手协商出一个只有双方知道的会话密钥之后的通信全部用这个密钥加密。这个过程你可以在脑子里过一遍第一次见面互验身份证验完身份之后商量一个暗号之后全程用暗号说话。落在MySQL的具体场景里就是客户端向服务端请求建立TLS连接服务端把自己的数字证书发给客户端客户端要么用系统信任库里的CA要么用连接参数里指定的CA去验证这张证书的真伪验证通过后双方协商加密算法生成会话密钥。MySQL从5.7开始其实是默认支持SSL的甚至服务端一旦配置了SSL相关证书新连接会自动协商TLS。这里有个常见误区服务端支持SSL不等于客户端一定走SSL。到底走不走、走的话严格到什么程度完全取决于客户端驱动里的sslMode配置。Kettle默认不自带这个参数所以很多环境里服务端明明开了SSLKettle的连接还是明文。1.2 “结果集加密”是错觉Kettle的SSL边界在哪里有一个认知必须先摆正SSL加密的是Kettle这台机器到MySQL服务器之间的网络传输链路而不是MySQL表空间里的数据更不是Kettle后续把数据推到目标库的那段链路。如果你的Kettle转换是“MySQL源库 → 目标库”你要搞清楚的是源连接要配一套SSL目标连接也要单独配一套SSL。两边是两条独立的链路各管各的不存在一个“全局加密开关”能把你整条数据链路的网都包住。再一个容易误解的点是“结果集”。Kettle跑批时执行SELECT、INSERT这些SQL语句本身要走网络大批量的结果集也一样要走网络。只要驱动配置的是高等级的sslMode这批流量全部是密文。反过来如果你用的还是老版本驱动比如Kettle 8.x自带的mysql-connector-java 5.1.x系列默认行为可能是useSSLfalse的隐式状态那Kettle在客户端上发出的SQL就是明文的结果集同样也是明文的。所以别以为登录密码传输能加密就够了。MySQL客户端做账号认证时密码本身有单独的加密机制但SQL语句、查询结果这些真正敏感的数据如果没有SSL全都是在网络里裸奔的。1.3 什么场景必须上SSL这个不是玄学是安全评估时的实际考量。下面是我整理的常见场景判断表基本覆盖了现实中会遇到的情况场景我的建议Kettle所在机器与MySQL跨公网、跨机房、混合云互通必须开SSL并且建议用VERIFY_CA以上级别等保、金融、行业合规审计明确要求传输链路加密必须开SSL审计报告里要能拿出证据同一机房但网络属于多租户共享、有被抓包风险强烈建议开代价很小Kettle和MySQL都在同一台机器localhost可以不开本机回环流量出不了网卡独立封闭内网VLAN网络设备和管理都可控视风险评估能开还是开省得以后补课顺带提醒一句安全合规不只是“防外部攻击”很多时候是“防内网横向嗅探”。明文流量的风险往往就来自内部某台机器被攻破后的进一步动作。这一步省下来的成本可能远低于后面一次数据泄露事故的代价。2. 服务端准备证书签发、MySQL启用与账号约束2.1 用自建CA签出一张能被Kettle信任的服务端证书生产环境用云厂商的托管数据库通常证书直接在控制台下载不用自己动手签。但自建MySQL或者测试环境最常见的做法是自己做一个私有CA然后用这个CA签服务端证书。这样做的核心好处是客户端只需要信任那一张CA证书就能校验所有由这个CA签发的服务端证书后续轮换服务端证书都不用动客户端。整个过程用OpenSSL完成大概四步。第一步生成CA私钥和CA自签名证书openssl genrsa 2048 ca-key.pem openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca-cert.pem \ -subj /CNmy-private-ca第二步生成MySQL服务端的私钥和证书签名请求CSRopenssl req -newkey rsa:2048 -nodes \ -keyout server-key.pem -out server-req.pem \ -subj /CNmysql-server第三步非常关键千万别漏生成证书请求时一定要带上SANSubject Alternative Name也就是把Kettle连接MySQL时实际使用的主机名或IP地址写进去。否则后面用VERIFY_IDENTITY做主机名校验时会直接报错。cat san.cnf EOF [v3_req] basicConstraints CA:FALSE keyUsage digitalSignature, keyEncipherment extendedKeyUsage serverAuth subjectAltName alt_names [alt_names] DNS.1 mysql.internal.example.com IP.1 10.10.0.5 EOF第四步用CA签发出服务端证书openssl x509 -req -in server-req.pem -days 3650 \ -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 \ -out server-cert.pem -extfile san.cnf -extensions v3_req签出来的三个文件要落到MySQL服务器的目录里server-cert.pem是服务端证书server-key.pem是服务端私钥ca-cert.pem是CA证书。建议统一放在/etc/mysql/ssl/下并且把私钥权限收一下通常是chown mysql:mysql chmod 600不然MySQL进程可能读不了启动时直接报错或者打了告警日志你都没察觉。2.2 MySQL开启SSL并强制账号使用加密服务端证书就位后在MySQL配置文件my.cnf的mysqld段里加三段路径[mysqld] ssl-ca/etc/mysql/ssl/ca-cert.pem ssl-cert/etc/mysql/ssl/server-cert.pem ssl-key/etc/mysql/ssl/server-key.pem重启MySQL之后验证是否真的加载了SSLSHOW VARIABLES LIKE have_ssl;正常情况下这个值应该是YES。如果还是DISABLED别急着往下走先回去查文件权限、路径拼写和MySQL错误日志。这一步没确认好后面所有配置都是空中楼阁。服务端SSL生效之后如果只是“支持加密”MySQL还是允许账号用明文连接的。要强制指定账号必须走SSL就执行ALTER USER kettle% REQUIRE SSL;改成这样之后凡是这个账号发起的非SSL连接都会被MySQL直接拒绝。这个动作我建议做因为测试环境经常有人漏配客户端你会发现少了这个约束很多人会不知不觉继续用明文连上等于安全整改白做了。2.3 JVM信任库与驱动版本这两个边角Kettle本体是Java程序所以还牵涉两个容易忽略的边角。第一个是JVM信任库。如果你打算在Kettle里用VERIFY_CA或VERIFY_IDENTITY就必须让Kettle的Java进程信任你自建的CA证书。老版本的MySQL Connector/J 5.1.x没有sslCA这种友好参数只能走Java系统信任库操作就是keytool -importcert -alias mysql-ca \ -file /etc/mysql/ssl/ca-cert.pem \ -keystore $JAVA_HOME/lib/security/cacerts \ -storepass changeit -noprompt但是用Connector/J 8.0.x系列就灵活得多连接URL里可以直接指定sslCA指向CA证书文件相当于驱动单独信任这个CA不污染JVM全局信任库。我强烈推荐这种做法尤其是Kettle有多个环境引用不同CA的时候全局信任库会把你绕晕。第二个边角是驱动版本。Kettle 9.0自带的还是mysql-connector-java 5.1.x系列拿来连MySQL 8.0会遇到一堆兼容问题包括但不限于时区报错、caching_sha2_password认证插件不识别等。我当时的做法是直接把Kettle自带的旧驱动卸掉换成mysql-connector-java 8.0.33。驱动放哪个目录和Kettle版本有关Kettle 8.x一般是libext/JDBC目录Kettle 9.x之后统一放在lib目录下。换完驱动必须重启Spoon否则加载的还是老的。3. Kettle侧的配置实操选项页签与自定义URL3.1 入口一在“选项”页签里透传JDBC参数Kettle配置数据库连接时界面上的“选项”页签是很多人没注意到的入口。它的本质是把你在表格里添加的键值对原封不动地透传给底层JDBC驱动。也就是说MySQL Connector/J支持的所有连接参数都可以在这个页签里维护。在数据库连接窗口里选择MySQL类型填好主机名、数据库名、端口、用户名、密码之后切到“选项”页签添加下面几个键值对参数值sslModeVERIFY_CAsslCA/etc/mysql/ssl/ca-cert.pem这里注意一个细节不同Kettle版本的“选项”页签位置不太一样9.x里有时是个小标签需要在连接对话框中切换视图才看得到。我当时第一次找这个页签就找了半天最后才确认它不是固定的Tab而是需要点一下才展开的面板。填好之后点“测试”看到连接成功再保存。“选项”页签的好处是直观不用拼一长串URL。坏处是参数多了不好维护而且有些版本对参数名大小写敏感比如sslMode写成了SSLMODE驱动不认还不会报错只是悄悄退回明文。3.2 入口二用自定义连接URL一次性写全如果你想对连接行为有完全的控制力或者需要在多个环境之间复制配置更推荐用自定义连接URL。在Kettle的MySQL连接界面里选中“自定义连接URL”单选项然后填下面这种完整的形式jdbc:mysql://10.10.0.5:3306/etl_db?sslModeVERIFY_CAsslCA/etc/mysql/ssl/ca-cert.pemsocketTimeout60000connectTimeout10000逐个参数说清楚sslModeVERIFY_CA强制启用SSL并验证CA证书。sslCA/etc/mysql/ssl/ca-cert.pem指定CA证书文件让驱动直接信任这个CA。connectTimeout和socketTimeout建议都写上尤其在网络抖动明显的跨机房环境里没有超时的话Kettle很容易一直挂着作业调度被卡住。如果Kettle所在机器上Java进程和MySQL之间还有负载均衡或者域名映射URL里的主机名一定要和证书SAN里写的保持一致。你是用IP连的证书里就要有对应IP的SAN项用域名连的证书里就要有对应DNS的SAN项。3.3 sslMode四个档位到底该怎么选这是整个配置里最容易让人纠结的地方。MySQL Connector/J 8.x的sslMode有四个档位区别我整理成了表档位行为适用场景PREFERRED服务端支持TLS就加密不支持就自动退回明文开发环境、对安全无要求。不推荐用于生产REQUIRED必须加密但不校验服务器证书真伪能防窃听防不了中间人攻击VERIFY_CA必须加密且校验服务器证书是否由受信CA签发自建CA、私有环境的标准选择VERIFY_IDENTITY在VERIFY_CA基础上再校验主机名与证书SAN匹配严格合规Kettle连接域名/IP稳定时适用我给出的建议是合规场景下VERIFY_CA打底如果你的网络架构稳定、证书SAN覆盖到位直接上VERIFY_IDENTITY最严格审计时也最好看。REQUIRED这个档位看着好像很安全实际上只是“加密了但不知道对面是谁”省不掉证书验证我基本不推荐除非你实在搞不定证书先把链路从明文改成密文再说。还有一个小细节SSL和Kettle的连接池可以一起开。Kettle的数据库连接“高级”页签里有连接池配置把初始池大小和最大池调高一点批处理场景下能明显减少反复握手带来的额外开销这一点放到后面性能部分再说。4. 踩坑记录从“连接都点不通”到稳定跑批的排障过程4.1 Public Key Retrieval is not allowed的连锁反应我配置过程中第一个遇到的报错其实还不是SSL本身的错而是Kettle的MySQL连接里很经典的“Public Key Retrieval is not allowed”。现象很统一Kettle里点“测试”连接直接失败弹窗把这句话原样丢给你。我当时第一反应是SSL配错了排查了半天发现不是。这个报错的根源在MySQL 8.0的默认认证插件。MySQL 8.0开始默认用caching_sha2_password客户端第一次认证的时候需要向服务端获取RSA公钥。如果连接没有走SSLMySQL默认不允许客户端直接拉取公钥于是就需要你在连接URL里显式加上allowPublicKeyRetrievaltrue驱动才会自动取公钥。排查链路可以这么梳理先查驱动版本是否还是老5.1.x再查账号的认证插件SELECT user, host, plugin FROM mysql.user WHERE userkettle;如果结果是caching_sha2_password再确认连接URL里是否带了SSL参数。这里最容易绕进去的一个点是允许公钥检索是非SSL连接下的补救措施一旦你把SSL真正配好了这个参数其实是不需要的因为认证过程中的密钥交换会走加密通道。所以在最终生产配置里我建议把allowPublicKeyRetrieval去掉保持SSL连接参数纯净也逼着自己确认链路确实已经加密了。4.2 SSL connection error 2026证书与权限排查第二个坑是报错误号2026当时真是把能试的都试了一遍。现象比第一个更扎心明明按文档配好了所有SSL参数测试连接时MySQL直接回一句“SSL connection error: unknown error number 2026”。我最初直觉是证书文件内容出了问题但反复检查证书没问题后来才发现罪魁祸首是私钥文件权限——MySQL进程根本没权限读私钥SSL功能根本没真正生效。完整的排查顺序应该是这样的按这个顺序来能快速定位先在MySQL服务端确认have_ssl变量是否为YES不是的话后面全别看了。再看MySQL错误日志找“SSL error”或者“cannot load certificate”这类关键字。检查证书、私钥、CA三个文件的属主和权限私钥至少要保证mysql用户能读。确认账号确实被REQUIRE SSL约束同时客户端连接URL中的sslCA指向了正确CA路径。最后如果你是用Kettle所在机器的Java版本较新而MySQL比较老比如5.6、5.7有可能遇到“No appropriate protocol”的报错这是Java 11以后默认禁用了TLSv1/TLSv1.1协议。补救方式是连接URL加enabledTLSProtocolsTLSv1.2或者直接把MySQL的TLS配置提升到TLSv1.2以上后者更治本。顺带说一句别小看证书文件权限这一点很多自建MySQL的SSL故障都出在这里。你配好CA、证书、私钥之后最好先用命令行客户端连一次试试确认能正常走SSL再回去找Kettle的事。4.3 主机名校验失败和驱动不生效这两个衍生坑把2026解决之后我以为大功告成结果用了VERIFY_IDENTITY又炸出一个报错证书的主机名校验不过。原因是Kettle连接MySQL用的主机名或IP和证书SAN里写的名字对不上。比如连接URL写的是10.10.0.5但证书SAN里只写了DNS域名。解决办法是重新生成证书把SAN写全DNS和IP都放进去。这也是我在2.1里专门强调SAN的原因。还有一个衍生坑出在驱动加载上。有些环境里你把8.0.x驱动放进lib目录了Kettle却还是启动老驱动。我当时换完驱动发现连接配置还是旧的行为后来排查才明白lib目录下旧jar没删干净或者Kettle的驱动扫描缓存没刷新。解决方法是把旧的connector jar删掉重启Spoon必要时清一下临时目录。5. 加密是否生效用数据说话5.1 在MySQL服务端确认会话的Ssl_cipher配置完别急着收工先验证加密真的生效了。最直接的方法是从MySQL服务端看当前会话的加密状态。用Kettle跑一个最简单的转换比如执行一次SELECT然后在MySQL里执行SHOW STATUS LIKE Ssl_cipher;如果返回的结果不是空值而是一串类似AES256-GCM-SHA384这样的加密套件名称就说明当前这个会话确实走的是加密连接。如果结果是空字符串说明这个连接是明文的配置还是有问题。在连接池场景下要注意Kettle可能同时维持多个后端会话SHOW STATUS查的是当前所在的这一个会话。想看得更全可以查这张表SELECT s.PROCESSLIST_ID, s.VARIABLE_VALUE FROM performance_schema.session_status s WHERE s.VARIABLE_NAME Ssl_cipher;这样能看到所有会话各自的加密状态方便确认Kettle连接池里的连接全都加密了。5.2 抓包看TLS握手直接证明没有明文SQL对于要过安全审计的场景服务端变量可能还不够有说服力最好直接用抓包工具验证链路。在Kettle所在机器上对MySQL的3306端口做一下流量抓取tcpdump -i eth0 host 10.10.0.5 and port 3306 -w kettle_ssl.pcap然后跑一个Kettle转换抓个几十秒停止抓包。用Wireshark打开pcap文件过滤规则输入tls你会看到TLSv1.2或TLSv1.3的ClientHello、ServerHello、EncryptedHandshakeMessage这些记录。这就证明了连接开始时就协商了TLS加密。想更直观的可以再在后面对比一下不配SSL的时候抓包直接能看到明文的SELECT语句字符串配了SSL之后payload全是密文搜不到任何SQL关键字。我当时把这两份抓包截图放进了安全整改报告里审计那边看了直接就通过了。5.3 SSL对ETL批导性能的影响实测很多人担心加了SSL之后性能下降。我在测试环境用一张200万行的表做全量抽取对比过明文连接和VERIFY_CA连接各跑几遍结论是对于Kettle这种以批量操作为主的ETL场景性能影响基本可以忽略。耗时上的差别大概在1%到3%之间主要开销来自TLS握手。握手过程是一次性成本Kettle跑一个长时间的批处理握手开销摊到整个任务里几乎可以忽略。如果任务特别多、连接频繁开关握手成本就会累积这时候最有效的办法就是开连接池复用连接而不是反复握手。CPU方面现在的服务器基本都有AES-NI硬件加速TLS传输阶段的加解密对CPU的占用很小。真正需要担心的是那种大量短事务、高频写入的场景SSL的额外CPU开销才会变得明显。Kettle这种批导工具说实话不用担心这个。6. 上线之后还要管的几件事轮换、维护与“能不能不上SSL”6.1 证书到期的轮换流程SSL配置完之后千万别把这件事忘了证书是会过期的。自签CA的证书有效期我建议设置得长一点比如十年但服务端证书建议两三年一换。日常运维里常见的问题就是证书到期了Kettle作业大面积连接失败主因是被MySQL的REQUIRE SSL拦住了。轮换分两种情况第一种是只换服务端证书CA不变。Kettle侧什么也不用动因为客户端信任的是CA服务端证书到期换新只要新证书还是同一个CA签的客户端自然信任。MySQL侧替换证书文件、重启MySQL完事。第二种是CA也换了。这时候Kettle连接URL里的sslCA要指向新CA文件如果是走JVM信任库的还要重新keytool导入新CA。我建议把CA文件路径统一放在固定目录比如每台机器上的/etc/kettle/ca-cert.pem轮换时只覆盖文件连接配置里的路径不用变减少操作失误。6.2 替代方案评估SSH隧道、内网隔离与云数据库TLS如果因为种种原因暂时配不了SSL还有几条路可以缓解风险但要分清主次。一是SSH端口转发。思路是先把MySQL的3306端口通过SSH映射到Kettle所在机器的本地端口Kettle连接localhost的映射端口。好处是配置简单不用动证书坏处是多了一跳网络故障面变大而且跳板机本身成为新的单点。这算“明文的临时救火方案”。二是内网隔离。把Kettle和MySQL放进同一个受控VLAN用防火墙规则限制访问来源端口。能显著降低被外部嗅探的风险但在严格的安全审计面前内网隔离不能替代传输加密。审计要的是链路加密的证据不是“我们觉得内网很安全”。三是云上的托管数据库。现在主流的云RDS全部支持开启TLS证书在控制台一键下载Kettle侧配置方式和自建一模一样。如果你们用的是云RDS强烈建议直接开这个能力省掉自己维护证书生命周期的一大摊事。6.3 我的最终建议与维护检查清单配置Kettle连MySQL的SSL加密连接说难不难说简单也有一堆细节。我最终用的是VERIFY_CA加sslCA文件指定没有动JVM全局信任库维护成本最低。版本组合上MySQL 8.0.33、Kettle 9.3、mysql-connector-java 8.0.33这组搭起来很稳。最后分享一个我自己的习惯每次改完Kettle连接配置不要只点一次“测试”就走了。测试只能证明“能连上”不能证明“走的是加密”。我一般测完会再到MySQL里看一眼Ssl_cipher或者直接抓一段包确认一下。把这一步固化成检查习惯基本就不会再让明文连接溜过去了。下面这个小表是我贴在不同环境服务器上的自检清单供你参考检查项操作目的MySQL SSL是否开启SHOW VARIABLES LIKE have_ssl确认服务端支持账号是否强制SSLSELECT user, host, ssl_type FROM mysql.user防止明文连接继续存在客户端连接模式连接URL或选项页签中的sslMode确认不是PREFERRED兜底连接加密是否真实生效SHOW STATUS LIKE Ssl_cipher确认当前会话加密中证书有效期openssl x509 -in server-cert.pem -noout -dates提前安排轮换关于Kettle能不能不上SSL我的观点很明确如果你和数据库之间有半点跨网络、跨机房的成分或者有任何审计要求那就必须上。如果你确定是localhost或者完全封闭的独立内网风险接受度也高可以先跑着但迟早建议补上。毕竟加密这件事补课的成本永远比第一次就做对的成本高。
阅读完成 · 觉得有帮助？
