Isito从懵圈到熟练 - 半夜两点Ca证书过期问题处理惨况总结

11月22号半夜2点,被值班同学的电话打醒。了解下来,大概情况是,客户某一台K8s集群节点重启之后,他再也无法创建Istio虚拟服务和Pod了。

一来对Istio还不是那么熟悉,二来时间可能有点晚,脑子还在懵圈中,本来一个应该比较轻松解决掉的问题,花了几十分钟看代码,处理的惨不忍睹。最终还是在某位大神帮助下,解决了问题。

鉴于此问题,以及相关报错,在网上找不到对应的文章,所以这里分享下这个问题,避免后来的同学,在同样的地方踩坑。另外谨以此篇致敬工作中遇到过的大神!

不断重启的Citadel

Citadel是istio的证书分发中心。证书即某个实体的身份证明,直接代表着实体本身参与信息交流活动。Citadel作为证书分发中心,负责替服务网格中每个服务创建身份证书,方便服务之间安全交流。

这个问题的现象是,Citadel再也无法启动了,导致无法创建新的虚拟服务和Pod实例。观察Citadel,发现其不断重启,并输出以下报错信息。

2019-11-22T02:40:34.814547Z     warn    Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
2019-11-22T02:40:34.815408Z     info    Use self-signed certificate as the CA certificate
2019-11-22T02:40:34.840128Z     error   Failed to create a self-signed Citadel (error: [failed to create CA KeyCertBundle (cannot verify the cert with the provided root chain and cert pool)])

通过代码分析,以及最后一行报错,可以理解问题背后的逻辑:

  1. Citadel不能启动,是因为其无法创建自签名的证书(Failed to create a self-signed Citadel)
  2. Citadel无法创建自签名证书的原因,又是由于它不能创建秘钥和证书(failed to create CA KeyCertBundle)
  3. 而前两条的根本的原因,是因为在验证创建的自签名证书的时候,验证失败(cannot verify the cert with the provided root chain and cert pool)

一般意义上的证书验证

证书的签发关系,会把证书连接成一棵证书签发关系树。顶部是根证书,一般由可信第三方持有,根证书都是自签名的,即其不需要其他机构来对其身份提供证明。其他层级的CA证书,都是由上一层CA证书签发。最底层的证书,是给具体应用使用的证书。

Isito从懵圈到熟练 - 半夜两点Ca证书过期问题处理惨况总结

验证这棵树上的证书,分两种情况:

根证书验证。因为即是签发者,又是被签发者,所以根证书验证,只需要提供根证书本身,一般肯定验证成功。
其他证书验证。需要提供证书本身,以及其上层所有CA证书,包括根证书。

自签名证书验证失败Citadel启动失败的根本原因,是其创建的自签名的证书,无法验证通过。而这一点,也是我处理问题时,卡壳的原因。左思右想,不明白为什么刚刚新建的自签名证书,都验证不通过。

大神定理

有一条定理,就是我们绞尽脑汁,耗费大量时间无法解决的问题,在大神眼里,可能就是几秒钟的事情。11月22号半夜,这条真理再次被验证。
因为实在想不通,但是用户又非常着急,所以最终还是打扰了一位大神,他只大概看了一下报错,就判断是CA证书过期问题。使用istio提供的证书验证脚本,很快证实了他的判断。相关文章见最后参考部分。

Citadel证书体系

问题解决了,这里总结下Citadel证书体系。大多数用户使用Isito的时候,都会选择使用自签名的根证书。自签名根证书,证书,以及证书使用者sidecar三种之间有三种关系:

Isito从懵圈到熟练 - 半夜两点Ca证书过期问题处理惨况总结

  1. 根证书和证书之间的签发关系。这种关系,保证了信任的传递性质。
  2. 证书和sidecar之间的持有和被持有关系。某种意义上,这是给pod/sidecar和证书画上了等号。
  3. 根证书和sidecar之间的信任关系。这与前两条加起来,sidecar就信任所有根证书签发的证书。

以上三条,即可保证,在互相通信的时候,pod/sidecar之间可以完成tls双向认证成功。

犯的错

这个问题排查中,实际上犯了两个错误。一个是代码阅读不仔细,一直盯着自签名证书新建的逻辑看。因为有了这个前提,即新建证书验证失败,所以没有办法理解,为什么新建的自签名证书也会验证失败,所以倾向于认为是底层安全库出了问题;另外一个是,只盯着Citadel不能启动的报错做,忽略了另外一条线索,就是Pod和虚拟服务创建失败。实际上后来发现,pod和虚拟服务创建失败的报错,有更明显的证书过期错误信息。

virtualservices.networking.istio.io "xxxx" could not be patched: Internal error occurred: failed calling admission webhook "pilot.validation.istio.io": Post https://istio-galley.istio-system.svc:443/admitpilot?timeout=30s: x509: certificate has expired or is not yet valid.

后记

在Istio比较早期的版本中,自签名Ca证书有效期只有一年时间,如果使用老版本Istio超过一年,就会遇到这个问题。当证书过期之后,我们创建新的虚拟服务或者pod,都会因为CA证书过期而失败。而这时如果Citadel重启,它会读取过期证书并验证其有效性,就会出现以上Cidatel不能启动的问题。

这个Ca证书在K8s集群中,是以istio-ca-secret命名的secret,我们可以使用openssl解码证书来查看有效期。这个问题比较简单的处理方法,就是删除这个Secret,并重启Citadel,这时Citadel会走向新建和验证自签名Ca证书的逻辑并刷新Ca证书。或者参考以下官网处理方式。

参考

https://istio.io/docs/ops/security/root-transition/

上一篇:K8S从懵圈到熟练:读懂这一篇,集群节点不下线


下一篇:1.3创建项目「深入浅出ASP.NET Core系列」