问题描述

Viper (本文环境是 Viper 1.1.0)是 Go 应用程序的完整配置解决方案,在很多项目中都有应用。etcd是一个分布式 KV 存储,最直接的应用是配置中心。

Viper 除了支持从文件中读取配置,还支持从远程的配置中心读取配置,使用下面的代码进行配置。

viper.AddRemoteProvider("etcd",
        "http://127.0.0.1:2379",
        "conf.toml")
viper.SetConfigType("toml")
err := viper.ReadRemoteConfig()
if err != nil {
    panic(err)
}

运行后报错panic: Remote Configurations Error: No Files Found,检查后发现 etcd 开启了 tls,所以需要用 https 协议访问 etcd 的 API,更新代码如下。

viper.AddSecureRemoteProvider("etcd",
        "https://127.0.0.1:2379",
        "conf.toml",
        "key_path")
viper.SetConfigType("toml")
err := viper.ReadRemoteConfig()
if err != nil {
    panic(err)
}

使用AddSecureRemoteProvider方法替换AddRemoteProvider方法,问题依旧。

定位问题

跟踪源码发现,最终像 etcd 发送请求的是go-etcd包(目前 go-etcd 已经不维护),在 go-etcd 的 requests.go 文件中找到了相关的源码,go-etcd 调用了 net/http 包向 etcd 发送请求。

这个时候忽然想到 etcd 的证书是自签名的,访问自签名证书的 https 接口应该会报错啊,怎么会请求到内容呢?如下图,在 Chrome 中访问 etcd 的自签名 https 接口,会提示证书无效。

我们自己使用 go 实现一段请求 etcd https 接口的代码,看看到底是什么回事,代码如下。

resperr := http.Get("https://127.0.0.1:2379/v2/keys/conf.toml?quorum=false&recursive=false&sorted=false")
    if err != nil {
        // handle error
        fmt.Println(err)
    }
    defer resp.Body.Close()
    bodyerr := ioutil.ReadAll(resp.Body)
    if err != nil {
        fmt.Println(err)
    }
    fmt.Println(string(body))

果然不一样,我们的代码会报错x509: certificate signed by unknown authority,因为是自签名证书,客户端无法验证证书真假,所以这个报错是可以理解的,go-etcd 代码和我们的测试代码表现不一致,一定是我们落下了什么,重新梳理 go-etcd 源码终于发现了原因。

在 client.go 文件的 initHTTPSClient 方法中,发现允许绕过证书验证,这就可以解释为什么证书无效也能获取到数据了,绕过了证书的验证环节,相当于不管证书真假都拿来用。现在可以解释使用AddRemoteProvider方法访问 https 接口为什么可以获取到内容,但是无法解释AddSecureRemoteProvider方法为什么无法从 https 接口获取内容,因为两个方法在发送 http 请求阶段的代码是一致的,都忽略了证书验证。

查看AddSecureRemoteProvider的注释,发现了原因。

原来…AddSecureRemoteProvider这个 Secure 指的并不是使用安全链接 https,而是在请求到内容后加了一个解密的步骤(Secure 指请求的是加密过的内容,而不是使用加密链接请求),最后一个参数接收的也并不是客户端证书,而是解密的 gpg key… 根据 viper 的文档,这个 gpg key 是可选的,我们这个例子中,如果给 gpg key 传入一个空字符串,也是可以正常执行的…

必须吐槽一下 viper 的命名,哪里是AddSecureRemoteProvider,明明应该叫AddEncryptedRemoteProvider

总结

出现这个问题,主要是误会了AddSecureRemoteProvider接口表达的意思,并且 go-etcd 允许忽略证书验证,也让问题变得更加离奇。

当然 go-etcd 的这种配置是非常合理的,内部系统使用自签名证书是一个很正常的行为。