Kubernetes集群中如何代理出站LDAP连接并转换为LDAPS连接

OpenLDAP 默认的服务端 slapd 虽然支持代理模式，但配置复杂度高，更适合做LDAP协议层的路由、权限管控，不是类似Nginx做HTTP→HTTPS无感知升级场景的最优选择，下面按适配度从高到低列可行方案：

方案1：Stunnel 透明代理（最推荐，和Nginx反向代理逻辑完全一致） #

Stunnel 是专门做TCP流量TLS封装/卸载的轻量代理，逻辑和你用Nginx处理HTTP升HTTPS完全对等：

• 代理端在集群内监听明文LDAP默认端口389，接收集群内客户端的明文LDAP请求
• 代理端主动和外部LDAP服务器建立LDAPS(636)的TLS加密连接，把客户端请求转发到加密通道
• 收到外部LDAP服务器的加密响应后，解密回传给内网明文客户端，整个过程客户端无感知，不需要修改任何业务侧的LDAP连接配置

K8s 部署步骤：

• 以Deployment形式部署Stunnel，暴露ClusterIP类型的Service，端口映射389
• 配置核心Stunnel配置文件，参考最小可用示例：

# /etc/stunnel/stunnel.conf
foreground = yes
pid = /var/run/stunnel.pid
log = /dev/stdout
debug = 2

[ldap-proxy]
# 监听所有网卡的389明文端口
accept = 0.0.0.0:389
# 替换为实际外部LDAP服务的LDAPS地址
connect = external-ldap.your-domain.com:636
# 生产环境建议开启上游证书校验，避免中间人攻击
verify = 2
CAfile = /etc/stunnel/certs/ldap-ca.pem

• 配置NetworkPolicy或节点层iptables规则，拦截集群内所有发往外部网段389端口的出站流量，重定向到Stunnel Service的389端口即可。

方案2：OpenLDAP slapd 代理模式（不推荐，仅适合需要LDAP层管控的场景） #

OpenLDAP 确实支持纯代理部署模式，不需要存储本地目录数据，通过back_ldap后端实现请求转发，核心配置参考：

# /etc/openldap/slapd.conf
include /etc/openldap/schema/core.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

# 仅监听明文389端口
listen ldap://0.0.0.0:389

# 配置LDAP代理后端
database ldap
# 替换为你的LDAP目录后缀
suffix "dc=your-company,dc=com"
# 上游走LDAPS加密连接
uri ldaps://external-ldap.your-domain.com:636
# 上游TLS证书配置
tls_cacert /etc/openldap/certs/ldap-ca.pem
tls_require_cert allow
# 配置代理绑定身份
idassert-bind bindmethod=simple binddn="cn=proxy-auth,dc=your-company,dc=com" credentials="your-proxy-password"

这个方案的缺点是需要手动配置目录后缀路由、访问权限、绑定认证规则，对LDAP协议知识要求高，仅做加密升级的话投入产出比很低。

方案3：服务网格原生流量升级（适合已部署Istio/Linkerd的集群） #

如果你的集群已经部署了服务网格，不需要额外部署代理组件，直接通过网格的Sidecar配置TCP流量规则：拦截到外部LDAP 389端口的出站流量，配置上游端点为外部LDAP的636端口并自动发起TLS握手，即可实现无感知的连接加密升级，导流和拦截逻辑由网格侧自动完成。

落地注意：所有方案都需要配套配置出站流量拦截规则，避免业务Pod绕过代理直接发起明文LDAP连接，和你之前部署Nginx反向代理时的流量管控逻辑一致。

内容的提问来源于stack exchange，提问作者Rudy