189 8069 5689

客户端怎样通过Kubernetes集群APIServer认证？

前言

我们提供的服务有：网站设计、成都网站设计、微信公众号开发、网站优化、网站认证、大姚ssl等。为1000+企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的大姚网站制作公司

现在我们上微博、或者网购，操作的其实不是眼前这台设备，而是一个又一个集群。通常，这样的集群拥有成百上千个节点，每个节点是一台物理机或虚拟机。集群一般远离用户，坐落在数据中心。为了让这些节点互相协作，对外提供一致且高效的服务，集群需要操作系统。Kubernetes 就是这样的操作系统。

比较 Kubernetes 和单机操作系统，Kubernetes 相当于内核，它负责集群软硬件资源管理，并对外提供统一的入口，用户可以通过这个入口来使用集群，和集群沟通。

客户端怎样通过Kubernetes集群 API Server 认证？

而运行在集群之上的程序，与普通程序有很大的不同。这样的程序，是“关在笼子里”的程序。它们从被制作，到被部署，再到被使用，都不寻常。我们只有深挖根源，才能理解其本质。

“关在笼子里”的程序

代码

我们使用 go 语言写了一个简单的 web 服务器程序 app.go，这个程序监听在 2580 这个端口。通过 http 协议访问这个服务的根路径，服务会返回 "This is a small app for kubernetes..." 字符串。

package main
import (
        "github.com/gorilla/mux"
        "log"
        "net/http"
)
func about(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("This is a small app for kubernetes...\n"))
}
func main() {
        r := mux.NewRouter()
        r.HandleFunc("/", about)
        log.Fatal(http.ListenAndServe("0.0.0.0:2580", r))
}

使用 go build 命令编译这个程序，产生 app 可执行文件。这是一个普通的可执行文件，它在操作系统里运行，会依赖系统里的库文件。

# ldd app
linux-vdso.so.1 => (0x00007ffd1f7a3000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f554fd4a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f554f97d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f554ff66000)

“笼子”

为了让这个程序不依赖于操作系统自身的库文件，我们需要制作容器镜像，即隔离的运行环境。Dockerfile 是制作容器镜像的“菜谱”。我们的菜谱就只有两个步骤，下载一个 centos 的基础镜像，把 app 这个可执行文件放到镜像中 /usr/local/bin 目录中去。

FROM centos
ADD app /usr/local/bin

地址

制作好的镜像存再本地，我们需要把这个镜像上传到镜像仓库里去。这里的镜像仓库，相当于应用商店。我们使用阿里云的镜像仓库，上传之后镜像地址是:

registry.cn-hangzhou.aliyuncs.com/kube-easy/app:latest

镜像地址可以拆分成四个部分：仓库地址/命名空间/镜像名称:镜像版本。显然，镜像上边的镜像，在阿里云杭州镜像仓库，使用的命名空间是 kube-easy，镜像名:版本是 app:latest。至此，我们有了一个可以在 Kubernetes 集群上运行的、“关在笼子里”的小程序。

入口

Kubernetes 作为操作系统，和普通的操作系统一样，有 API 的概念。有了 API，集群就有了入口；有了 API，我们使用集群，才能得其门而入。Kubernetes 的 API 被实现为运行在集群节点上的组件 API Server。这个组件是典型的 web 服务器程序，通过对外暴露 http(s) 接口来提供服务。

客户端怎样通过Kubernetes集群 API Server 认证？

这里我们创建一个阿里云 Kubernetes 集群。登录集群管理页面，我们可以看到 API Server 的公网入口。

API Server 内网连接端点： https://xx.xxx.xxx.xxx:6443

双向数字证书验证

阿里云 Kubernetes 集群 API Server 组件，使用基于 CA 签名的双向数字证书认证来保证客户端与 api server 之间的安全通信。这句话很绕口，对于初学者不太好理解，我们来深入解释一下。

从概念上来讲，数字证书是用来验证网络通信参与者的一个文件。这和学校颁发给学生的毕业证书类似。在学校和学生之间，学校是可信第三方 CA，而学生是通信参与者。如果社会普遍信任一个学校的声誉的话，那么这个学校颁发的毕业证书，也会得到社会认可。参与者证书和 CA 证书可以类比毕业证和学校的办学许可证。

这里我们有两类参与者，CA 和普通参与者；与此对应，我们有两种证书，CA 证书和参与者证书；另外我们还有两种关系，证书签发关系以及信任关系。这两种关系至关重要。

我们先看签发关系。如下图，我们有两张 CA 证书，三个参与者证书。

其中最上边的 CA 证书，签发了两张证书，一张是中间的 CA 证书，另一张是右边的参与者证书；中间的 CA 证书，签发了下边两张参与者证书。这六张证书以签发关系为联系，形成了树状的证书签发关系图。

客户端怎样通过Kubernetes集群 API Server 认证？

然而，证书以及签发关系本身，并不能保证可信的通信可以在参与者之间进行。以上图为例，假设最右边的参与者是一个网站，最左边的参与者是一个浏览器，浏览器相信网站的数据，不是因为网站有证书，也不是因为网站的证书是 CA 签发的，而是因为浏览器相信最上边的 CA，也就是信任关系。

理解了 CA（证书），参与者（证书），签发关系，以及信任关系之后，我们回过头来看“基于 CA 签名的双向数字证书认证”。客户端和 API Server 作为通信的普通参与者，各有一张证书。而这两张证书，都是由 CA 签发，我们简单称它们为集群 CA 和客户端 CA。客户端信任集群 CA，所以它信任拥有集群 CA 签发证书的 API Server；反过来 API Server 需要信任客户端 CA，它才愿意与客户端通信。

阿里云 Kubernetes 集群，集群 CA 证书，和客户端 CA 证书，实现上其实是一张证书，所以我们有这样的关系图。

客户端怎样通过Kubernetes集群 API Server 认证？

KubeConfig 文件

登录集群管理控制台，我们可以拿到 KubeConfig 文件。这个文件包括了客户端证书，集群 CA 证书，以及其他。证书使用 base64 编码，所以我们可以使用 base64 工具解码证书，并使用 openssl 查看证书文本。

  • 首先，客户端证书的签发者 CN 是集群 id c0256a3b8e4b948bb9c21e66b0e1d9a72，而证书本身的 CN 是子账号 252771643302762862；
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 787224 (0xc0318)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
        Validity
            Not Before: Nov 29 06:03:00 2018 GMT
            Not After : Nov 28 06:08:39 2021 GMT
        Subject: O=system:users, OU=, CN=252771643302762862
  • 其次，只有在 API Server 信任客户端 CA 证书的情况下，上边的客户端证书才能通过 API Server 的验证。kube-apiserver 进程通过 client-ca-file 这个参数指定其信任的客户端 CA 证书，其指定的证书是 /etc/kubernetes/pki/apiserver-ca.crt。这个文件实际上包含了两张客户端 CA 证书，其中一张和集群管控有关系，这里不做解释，另外一张如下，它的 CN 与客户端证书的签发者 CN 一致；
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 787224 (0xc0318)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
        Validity
            Not Before: Nov 29 06:03:00 2018 GMT
            Not After : Nov 28 06:08:39 2021 GMT
        Subject: O=system:users, OU=, CN=252771643302762862
  • 再次，API Server 使用的证书，由 kube-apiserver 的参数 tls-cert-file 决定，这个参数指向证书 /etc/kubernetes/pki/apiserver.crt。这个证书的 CN 是 kube-apiserver，签发者是 c0256a3b8e4b948bb9c21e66b0e1d9a72，即集群 CA 证书；
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2184578451551960857 (0x1e512e86fcba3f19)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
        Validity
            Not Before: Nov 29 03:59:00 2018 GMT
            Not After : Nov 29 04:14:23 2019 GMT
        Subject: CN=kube-apiserver
  • 最后，客户端需要验证上边这张 API Server 的证书，因而 KubeConfig 文件里包含了其签发者，即集群 CA 证书。对比集群 CA 证书和客户端 CA 证书，发现两张证书完全一样，这符合我们的预期。
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 786974 (0xc021e)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=CN, ST=ZheJiang, L=HangZhou, O=Alibaba, OU=ACS, CN=root
        Validity
            Not Before: Nov 29 03:59:00 2018 GMT
            Not After : Nov 24 04:04:00 2038 GMT
        Subject: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72

访问

理解了原理之后，我们可以做一个简单的测试：以证书作为参数，使用 curl 访问 api server，并得到预期结果。

# curl --cert ./client.crt --cacert ./ca.crt --key ./client.key https://xx.xx.xx.xxx:6443/api/
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "192.168.0.222:6443"
    }
  ]
}


文章名称：客户端怎样通过Kubernetes集群APIServer认证？
链接地址：http://cdxtjz.cn/article/ippesp.html

其他资讯