说到Redis的TLS加密配置,很多开发者第一反应可能是”这玩意儿配置起来一定很麻烦吧?”——说实话,我也是这么想的,直到去年被迫帮客户处理Redis安全加固时不得不硬着头皮研究。事实上,Redis 6.0开始内置的TLS支持比想象中友好得多,但其中的一些小陷阱还是让我栽了几个跟头。比如证书格式问题就卡了我一整天,最后还是看源码才找到原因…
TLS配置的核心三要素
配置Redis TLS其实就围绕三个核心文件展开:证书、私钥和配置文件。我建议先用OpenSSL生成自签名证书测试(生产环境一定要用CA签发),执行这个命令时要注意密钥长度:openssl req -x509 -newkey rsa:2048 -days 365 -nodes -keyout redis.key -out redis.crt
。记得把生成的redis.crt和redis.key放到安全目录,比如/etc/redis/certs/,权限设置为600。
第一次配置时我犯了个低级错误——直接把证书路径写成相对路径,结果Redis死活找不到文件。后来发现必须用绝对路径,这坑现在想来都好笑。配置文件中关键的三行是这样的:
tls-port 6380
tls-cert-file /etc/redis/certs/redis.crt
tls-key-file /etc/redis/certs/redis.key
那些容易踩的坑
测试时发现三个典型问题:一是证书链不完整导致验证失败(特别常见于Let’s Encrypt证书);二是忘记开放TLS端口防火墙;最头疼的是兼容性问题——老版本redis-cli居然不带TLS支持!这时候要么升级客户端,要么就得用stunnel中转。
查看TLS连接状态有个实用命令:redis-cli --tls --cert ./redis.crt --key ./redis.key --cacert ./redis.crt PING
。有次客户报障说加密连接总断开,就是用这个方法发现他们的ELB在30秒超时,而Redis默认timeout是0(表示永不超时),两边配置不一致导致的。
性能考量与时髦方案
TLS确实会带来性能损耗,但实测发现比想象中好。在8核机器上,加密连接吞吐量大约下降15%-20%。如果特别在意性能,可以启用tls-session-caching
参数,重用会话能提升30%左右性能。现在比较时髦的玩法是用Redis+Envoy,让Envoy负责TLS卸载,既安全又减轻Redis负担。
最后说个冷知识:Redis的TLS实现其实支持SNI(服务器名称指示),意味着单实例可以承载多域名证书。不过这个功能在cluster模式下有特殊限制,我上次做多租户方案时就栽在这里…看来安全配置真是个需要不断踩坑的活啊!
评论