首页 体育 教育 财经 社会 娱乐 军事 国内 科技 互联网 房产 国际 女人 汽车 游戏

Kubernetes数字证书体系浅析

2020-01-06

上文咱们介绍了非对称加密算法的一个重要运用——音讯加密。接下来咱们要谈一下该算法的另一个重要运用——数字签名。

虽然RSA算法处理了明文传输的坏处,可是传输内容依然存在着被绑架的或许,那便是 中间人进犯 。简略来讲, 中间人进犯 便是在非对称加密进程中,Client和Server的通讯被第三方绑架,形成的成果便是在整个通讯进程中,两边并没有直接通讯,而都是在跟第三方— 即中间人交互数据,限于篇幅原因,关于中间人进犯的详细原理,感兴趣的朋友能够自行查找维基百科。

图片出处: Who and how is using forged SSL certificates worldwide?

由上图的示例不难看出,呈现中间人进犯的本源在于:在通讯中,Client接纳的实际上是中间人的Server公钥证书,它无法验证接纳的Server公钥是否真的来自于Server。假如想处理这个问题,就需求引进CA认证系统—包括 证书颁布安排 、 数字证书 和 数字签名 这三个概念,即在中间人进犯的比如中,让一个第三方认证安排来验证Server公钥的合法性,这三个概念扼要阐明如下:

证书颁布安排

从维基百科的界说能够看到,CA是担任发放和办理数字证书的权威安排,作为电子商务买卖中受信赖的第三方,承担着公钥系统中公钥的合法性查验的职责。

全球闻名的CA认证安排如下图所示,能够看到,现在各大安排和公司运用的CA厂商根本为国外安排。虽然国内亦有认证安排触及,但事实是,假如常常拜访国内大中型银行的网上银行,你就会发现,现在它们运用的数字证书均是由国外CA认证安排签发。从另一个旁边面来看,咱们日常运用的干流浏览器,如IE、Chrome、Firefox中,都预先内置了许多CA认证安排供给的根数字证书,但并不是一切CA认证安排根证书都会被内置在浏览器中,这些浏览器挑选哪些CA认证安排,或多或少都代表了浏览器厂商关于这些CA认证安排的信赖程度。

图片出处: 维基百科Certificate authority介绍 ,该统计数据来自W3Techs在2018年5月的调研成果

数字证书

介绍完CA,再来看一下CA系统中另一个重要组成部分— 数字证书。结合刚刚说到的 中间人进犯 ,咱们能够看到,只要引进第三方认证安排,Client具有了由CA安排颁布的数字证书,Server公钥的合法性才干得到保证。因为现在互联网网站中大大都的数字证书都是根据 X.509 V3规范,因而X.509证书现已成为互联网数字证书的代名词,本文中假如无特别声明,说到的数字证书都是根据X.509规范。

X.509证书首要包括数据加密和数字签名内容,以供给认证的完成,保证数据的共同性和机密性。下图中以维基百科网站的x509证书为例进行解析,能够看到,里边包括了签发者信息、证书有用信息,主题信息,以及公钥信息和数字签名,还有一些证书扩展信息。

图片出处: 维基百科X.509介绍

数字签名

从刚刚介绍的维基百科的数字证书中,咱们能够看出,数字证书中一般有两大类内容:一是证书数据,一般包括签发安排、有用期、公钥信息及扩展信息等内容;二是结束的数字签名,在这儿,数字签名的效果便是为了证明数字证书中Data File的合法性,然后避免中间人进犯的状况。

数字签名从技能视点,触及两个进程:签名和验证,签名进程由CA认证安排建议,验证进程由需求进行证书验证的实体建议。

从谨慎的视点来讲,需求进行证书验证的实体,或许是需求进行Server验证的Client端,也或许是需求Client验证的Server端。

图片出处: Our choice of digital signature algorithm

签名进程剖析:

Client Auth

Kubernetes环境中,除了首要运用CA认证系统之外,常见认证方法还有其他类型,比如对Service Account进行签名验证,该验证运用的是JWT—JSON Web Token方法,本文中限于篇幅原因暂不打开评论。

初学者在建立Kubernetes的时分,各种CA证书会让人摸不着头脑,信赖许多朋友总有这样一个疑问:Kubernetes集群中到底有几个Root CA,或者说有几套CA的证书链。

笔者经过对Kubernetes的官方材料的研讨及实践,发现在现在干流版别的Kubernetes单集群中,最多存在四条CA信赖链,而在大大都环境中,则至少需求两条CA信赖链,即API Server CA信赖链和etcd CA信赖链。

etcd的CA信赖链因为只触及apiserver的两方通讯,逻辑较为简略,本文中不做打开介绍。

apiserver触及许多中心组件,比较复杂,后续专门开一个末节进行剖析。

apiserver CA信赖链

etcd CA信赖链

extension apiserver CA信赖链

该证书不行与API Server的CA共用,根据官网关于 CA Reusage and Conflicts 的阐明,问题首要出在Kubernetes的架构规划上:client在拜访API Server时,需求参阅以下次序进行证书验证作业:

1、--requestheader-client-ca-file指定的CA证书

假如Client证书由该CA证书签发,则比照Client证书中的CN—Common Name和--requestheader-allowed-names是否共同,假如共同,拜访恳求经过;反之,则回绝拜访。

2、--client-ca-file指定的CA证书

假如Client证书由该CA证书签发,则经过拜访恳求,并将client证书中的CN—Common Name和O—Organization作为User和Group字段,用于后续RBAC的授权;反之,则回绝拜访。

试想,假如两者运用同一个CA证书,就会使得本来拜访apiserver的client被强制导向到extension apiserver的Client Auth机制上,使得拜访无法经过,最典型的成果,便是control plane的相关组件和kubelet无法同apiserver进行正常通讯。

kubelet CA信赖链

小结一下:

以上这四套CA信赖链,apiserver和etcd是必要的。

extension apiserver的CA信赖链只要在运用时才会用到,但不行与apiserver CA相同。

kubelet的CA信赖链不是必要的,有时根据布置的实际状况,合并到apiserver的CA信赖链中。

详细的CA证书链联系能够参阅笔者总结的思想导图。

注:kubespray默许布置的Kubernetes集群中,证书默许目录为/etc/kubernetes/ssl,不是/etc/kubernetes/pki。

本事例中,CNI plugin运用的是Flannel,假如运用Calico、Weave者其他的Plugin,可参阅相关相似装备。

因为API Server组件是Kubernetes的中心中枢,在与其他组件进行互访时,都需求进行证书验证,毫不夸大的说,研讨Kubernetes的证书系统,根本上便是在研讨API Server与其他组件通讯时彼此证书验证的机制。咱们按照之前的思路,仍是将互信联系分为Server Auth和Client Auth进行介绍。

本事例中,CNI plugin运用的是Flannel,假如运用Calico、Weave者其他的Plugin,可参阅相关相似装备。

Server Auth

API Server运用--tls-cert-file参数指定Server Auth的证书—apiserver.crt。由下图能够看到,其他组件以Client身份拜访apiserver时,因为信赖Root CA,API Server对这些组件来讲,便是一个可信Server。

需求阐明的是,各个组件内寄存该Root CA证书的方法各异,详细不同能够参阅下图中文字阐明。

留神的朋友或许现已注意到,截止现在,Kubernetes的最新版别的官网资源关于 Master Node Communication 的介绍中,API Server在拜访kubelet时,是不需求进行Server Auth验证的。但这种状况假如放在公网环境中,或许导致MITM,因而假如安全方面有要求,能够在apiserver的发动参数中进行指定相关参数完成对kubelet的Server Auth,详细能够参阅下图的阐明。

Client Auth

Client Auth的意图是为了让各组件拜访apiserver时,让apiserver以为自己是可信的。

该机制首要运用于以下三个方面:

上图中呈现的容器渠道用于我行Kubernetes多集群办理,关于单集群Kubernetes可不选用,这儿仅作简略阐明。

咱们在介绍数字证书中,要点说到了一种证书类型—X.509,它是CA认证系统的重要组成部分。在本篇的结束,想必许多朋友还会有一个疑问:那便是为什么X.509证书在Kubernetes环境中广泛运用?

经过对Kubernetes官网中关于 Authentication的机制介绍 ,咱们能够看到,其实Kubernetes集群在认证方法的挑选上,CA认证系统并不是仅有的挑选。Kubernetes集群支撑许多种认证方法:

那么为什么x509证书会在Kubernetes中心组件中广泛运用呢?笔者经过研讨与实践,以为原因有三:

假如您对RBAC Authorization的相关部分不了解,能够经过链接阅览Kubernetes官网的相关章节。

下图是根据kubespray建立Kubernetes环境中,笔者经过剖析各组件Client证书内容,总结的Client Certificate和RBAC授权的联系表,供感兴趣的朋友参阅。

Kubernetes作为CNCF的中心项目,在容器技能蓬勃发展的短短几年里,已然成为了容器编列渠道以及云原生的代名词,不管在国内仍是国外,关于Kubernetes的运用和开发内容,也敏捷成为了近几年云技能评论的热门论题。值得注意的是,在各个社区和公司都重视Kubernetes功用性需求的一起,Kubernetes的安全问题也逐步也成为了摆在容器办理员面前一个不能忽视的论题。

本篇文章中,笔者以HTTPS的相关认证系统为根底,深化解析了Kubernetes内部证书系统中的各层联系,为我行下一步进行容器渠道建造和证书系统改造,供给了详实的技能参阅和根据。别的,笔者也期望经过本文,能够为正在学习、想深化研讨Kubernetes安全认证系统的朋友们抛砖引玉,开辟思路,限于个人技能水平,观念和剖析或许存在片面性或不精确之处,也欢迎感兴趣的朋友在大众号留言及评论。

作者:温啸,任职于民生银行灾备办理中心,10年以上根底架构的规划和运维经历,现在首要致力于异地灾备建造和运维作业,对OpenStack和Kubernetes技能亦有必定的研讨。

原文链接: https://mp.weixin.qq.com/s/iXuDbPKjSc65t_9Y1--bog

热门文章

随机推荐

推荐文章