Kibana Docker容器启动时报--tls-min-v1.0在NODE_OPTIONS中不允许的解决方法

为什么升级Node到12.3.1没有解决问题 #

很多人对Node的NODE_OPTIONS机制有认知偏差：
Node对可以通过NODE_OPTIONS环境变量传入的参数有严格的白名单校验，不是所有node CLI参数都能通过环境变量传递。--tls-min-v1.0直到Node.js 14.0.0版本才被正式纳入白名单范围，哪怕你把容器内的Node从10.x升到12.x的任意版本，只要参数被放在NODE_OPTIONS里，就会被直接拦截抛出“not allowed”的错误，和你之前了解的“Node高于12就支持该参数”的说法不匹配。

快速复现验证 #

启动容器时直接清空NODE_OPTIONS环境变量，跳过原有配置加载：

docker run -e NODE_OPTIONS="" <你的Kibana镜像标签>

如果用这个命令能正常启动Kibana，就可以100%确认问题来源是被注入到环境变量中的非法TLS参数。

常见问题根源排查 #

• 检查自定义Kibana镜像的Dockerfile：找一下历史构建步骤里是不是残留了ENV NODE_OPTIONS="--tls-min-v1.0"的配置，这类残留基本都是早年为了兼容旧TLS版本连Elasticsearch时，跟着旧教程加的，本身用法就是错的。
• 检查容器启动的环境变量透传：确认有没有用--env-file或者--env参数从宿主机向容器传配置，很多在宿主机做Node开发的人会配置全局NODE_OPTIONS，启动Docker的时候如果没做隔离，这些参数就会被透传进容器触发报错。
• 检查Kibana镜像的entrypoint启动脚本：部分旧版Kibana的官方镜像entrypoint里，会自动检测Node版本并尝试注入TLS兼容参数到NODE_OPTIONS里，一旦检测到的Node版本不匹配白名单规则，就会抛这个错。

需要旧TLS版本兼容的正确操作方式 #

如果你确实需要Kibana支持TLS 1.0的兼容能力，不要把参数塞到NODE_OPTIONS里：

• 直接修改容器内/usr/share/kibana/bin/kibana启动脚本，在调用node执行Kibana主程序的那一行，把--tls-min-v1.0作为直接传给node的CLI参数，而不是通过NODE_OPTIONS环境变量传递，就能直接绕过NODE_OPTIONS的白名单校验。
• 如果用的是Kibana 7.11及以上版本，官方已经默认将最低TLS版本设为1.2，完全不需要手动添加这类旧版本兼容参数。

内容的提问来源于stack exchange，提问作者Charlie Benger-Stevenson