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

简介: 11月22号半夜2点,被值班同学的电话打醒。了解下来,大概情况是,客户某一台K8s集群节点重启之后,他再也无法创建Istio虚拟服务和Pod了。一来对Istio还不是那么熟悉,二来时间可能有点晚,脑子还在懵圈中,本来一个应该比较轻松解决掉的问题,花了几十分钟看代码,处理的惨不忍睹。

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证书签发。最底层的证书,是给具体应用使用的证书。

b

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

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

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

大神定理

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

Citadel证书体系

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

c

  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证书。或者参考以下官网处理方式。

目录
相关文章
|
机器学习/深度学习 数据可视化 网络架构
增强深度学习模型的可解释性和泛化能力的方法研究
【8月更文第15天】在深度学习领域,模型的准确率和预测能力是衡量模型好坏的重要指标。然而,随着模型复杂度的增加,它们往往变得越来越难以理解,这限制了模型在某些关键领域的应用,例如医疗诊断、金融风险评估等。本文将探讨如何通过几种方法来增强深度学习模型的可解释性,同时保持或提高模型的泛化能力。
1262 2
|
机器学习/深度学习 人工智能 弹性计算
智能化运维:AI在故障预测与自我修复系统中的应用
随着技术的不断进步,传统的运维模式已逐渐不能满足现代企业的需求。本文将探讨如何通过人工智能技术,特别是机器学习和深度学习算法,实现对IT系统的实时监控、故障预测以及自动化修复。我们将分析AI技术在智能运维中的具体应用案例,并讨论其带来的效率提升和成本节约效果。文章旨在为读者提供一种全新的运维视角,展示AI技术在提高系统稳定性和减少人工干预方面的潜力。
|
域名解析 Kubernetes 负载均衡
在K8S中,外部访问容器服务,比如说提供了一个域名,链路怎么走?数据经过哪些组件?
在K8S中,外部访问容器服务,比如说提供了一个域名,链路怎么走?数据经过哪些组件?
|
API 数据安全/隐私保护 开发者
用 Python 优雅地玩转 Elasticsearch:实用技巧与最佳实践
用 Python 优雅地玩转 Elasticsearch:实用技巧与最佳实践
|
机器学习/深度学习 人工智能 运维
智能化运维:AI在故障预测中的应用
【6月更文挑战第8天】随着人工智能技术的飞速发展,其在IT运维领域的应用也日益广泛。本文将探讨AI技术如何助力运维团队实现故障的智能预测,提高系统稳定性和业务连续性。
|
存储 运维 监控
《SRE实战手册》学习笔记之SRE落地实践
分段判定原则:对于原因较复杂或链路较长的故障,建议分阶段评估,不同阶段有不同的措施。这一原则的出发点是要摒弃“故障根因只有一个”的观点。
《SRE实战手册》学习笔记之SRE落地实践
|
安全 应用服务中间件 测试技术
如何在 Nginx 中启用 HSTS?
如何在 Nginx 中启用 HSTS?
769 1
如何在 Nginx 中启用 HSTS?
|
机器学习/深度学习 人工智能 运维
AIOps与DevOps的区别在哪里
【2月更文挑战第29天】DevOps强调开发和运维的协作,而AIOps则侧重AI对运维的增强。两者在参与人员、工作方式和内容上有区别。随着DevOps的普及,软件开发、人工智能与运维的交叉工作增多,预示着向AIOps的过渡。
|
存储 Kubernetes Cloud Native
云原生|kubernetes|etcd集群详细介绍+安装部署+调优
云原生|kubernetes|etcd集群详细介绍+安装部署+调优
2960 1
|
Kubernetes Cloud Native 容器
开放下载!《深入浅出Kubernetes》
一次搞懂6个核心原理吃透基础理论,一次学会6个典型问题的华丽操作
开放下载!《深入浅出Kubernetes》