其他分享
首页 > 其他分享> > Kubernetes——X.509数字证书认证

Kubernetes——X.509数字证书认证

作者:互联网

X.509数字证书认证

  Kubernetes 支持的 HTTPS 客户端证书认证、token 认证及 HTTP basic 认证几种认证方式中,基于 SSL/TLS  协议的客户端证书认证以其安全性高且易于实现等特性,而成为主要使用的认证方式之一。

  SSL/TLS 最常见的使用场景是将 X.509 证书与服务器端相关联,但不为客户端使用证书(这意味着,服务端无法验证客户端的身份,起码不能通过 SSL/TLS 协议进行)。

  那如果从安全要求更高的场看,需要验证客户端时,使用其他几种(如 HTTP 基本认证)通常会更容易些,而且这些机制不会产生生成和分发 X.509 证书的高昂维护开销。不过也可以使用组织私有的证书分发系统也一样能够使用数字证书进行客户端认证。(比如 服务端和客户端的双向认证机制。)

  服务端与客户端互相认证的场景中,双方需要各自配备一套证书,并拥有信任的签证机构的证书列表。使用私有签证机构颁发的数字证书时,用户通常需要手动将此私有签证机构的证书添加到信任的签证机构列表中。

一、Kubernetes 中的 SSL/TLS 认证

  构建安全基础通信环境的 Kubernetes 集群时,需要用到 TLS 及数字证书通信场景有很多。

  API Server 是整个 Kubernetes 集群的通信网关。Controller-Manager、Scheduler、kubelet 及 kube-proxy 等均需要经由 API Server 与 etcd 通信完成资源状态信息的获取及更新等。同样处于安全通信的目的,master 的各个组件(API Server、Controller-Manager 和 Scheduler)需要基于 SSL/TLS 向外提供服务,而且与集群内部组件间进行通信时(主要是各节点上的 kubelet 和 kube-proxy)还需要进行双向身份验证。

  Kubernetes 集群中各资源的状态信息,包括 Secret 对象中的敏感信息等均以明文方式存储于 etcd 中。因此,etcd 集群内各节点之间的通信,以及各节点与其客户端(主要是 API Server)之间的通信都应该以加密的方式进行,并需要进行身份验证。

  API Server 与其客户端之间采用 HTTPS 通信可兼顾实现通信与认证的功能,它们之间通信的证书可由同一个 CA 进行管理,其客户端大体可分为如下三类:

二、客户端配置文件 kubeconfig

  包括 kubectl、kubelet 和 kube-controller-manager 等在内的 API Server 的各类客户端都可以使用 kubeconfig 配置文件提供接入多个集群的相关配置信息,包括各 API Server 的 URL 及认证信息等,而且能够设置成不同的上下文环境,并在各环境之间快速切换。

  使用 kubeadm 初始化集群后生成的 /etc/kubernetes/admin.conf 文件即为 kubeconfig 格式的配置文件,其由 kubeadm init 命令自动生成,可由 kubectl 加载(默认路劲为:$HOME/.kube/config)后用于接入服务器。

  "kubectl config view" 命令能够显示当前正在使用的配置文件,下面的命令结果显示了配置的集群列表,用户列表,上下文列表以及当前使用的上下文(current-context)等。

[root@k8s-master01-test-2-26 ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://lb.zuoyang.tech:6443
  name: cluster.local
contexts:
- context:
    cluster: cluster.local
    user: kubernetes-admin
  name: kubernetes-admin@cluster.local
current-context: kubernetes-admin@cluster.local
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
[root@k8s-master01-test-2-26 ~]# 

  事实上,任何类型的 API Server 客户端都可以使用 kubeconfig 进行配置,例如 Kubernetes Node 之上的 kubelet 和 kube-proxy 也需要将其用到的认证信息保存于专用的 kubecofnig 文件中,并通过 --kubecofig 选项进行加载。

  上面的kubeconfig 文件的定义包含以下几个主要配置:

  用户可以按需自定义相关的配置信息于 kubeconfig 配置文件中,以实现使用不同的用户账户接入集群的功能。

  kubeconfig 是一个文本文件,虽然支持用文本处理工具直接编辑,但更建议使用 "kubectl config" 命令进行设定,除了能够自动进行语法检查外,也能避免不必要的错误。

  kubeconfig 命令的常用操作包含如下几项:

  使用 kubeadm 部署的 Kubernetes 集群默认提供了拥有集群管理权限的 kubeconfig 配置文件 /etc/kubernetese/admin.conf,它可被复制到任何有着 kubelet 的主机上以用于管理整个集群。

  管理员还可以创建其他基于 SSL/TLS 认证的自定义用户帐号,以授权费管理员级集群资源使用权限,其配置过程分为两个部分:

1)为用户创建专用私钥及证书文件。

2)将其配置于某 kubeconfig 文件中。

  第一步,为目标用户帐号 kube-user1 创建私钥及证书文件,保存于/etc/kubernetes/pki 目录中:

  1. 生成私钥文件,注意其权限应该为 600 以阻止其他用户随意获取,这里在 Master 节点上以 root 用户进行操作,并将文件放置于 /etc/kubernetes/pki 专用目录中:
    [root@k8s-master01-test-2-26 ~]# cd /etc/kubernetes/pki/
    [root@k8s-master01-test-2-26 pki]# (umask 077; openssl genrsa -out kube-user1.key 2048)
    Generating RSA private key, 2048 bit long modulus
    .....................................................................................................................................................................................................+++
    .............................................................................+++
    e is 65537 (0x10001)
    [root@k8s-master01-test-2-26 pki]# 
  2. 创建证书签署请求,-subj 选项中 CN 的值将被 kubeconfig 作为用户名使用,O(这个是大写字母O)的值将被视为用户组:
    [root@k8s-master01-test-2-26 pki]# openssl req -new -key kube-user1.key -out kube-user1.csr -subj "/CN=kube-user1/O=kubernetes"
  3. 基于 kubeadm 安装 Kubernetes 集群时生成的 CA 签署证书,这里设置其有效时长为 3650 天:
    [root@k8s-master01-test-2-26 pki]# openssl x509 -req -in kube-user1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out kube-user1.crt -days 3650
    Signature ok
    subject=/CN=kube-user1/O=kubernetes
    Getting CA Private Key
    [root@k8s-master01-test-2-26 pki]# 
  4. 验证证书信息:
    [root@k8s-master01-test-2-26 pki]# openssl x509 -in kube-user1.crt -text -noout
    Certificate:
        Data:
            Version: 1 (0x0)
            Serial Number:
                c4:7c:ef:f3:90:60:70:e4
        Signature Algorithm: sha256WithRSAEncryption
            Issuer: CN=kubernetes
            Validity
                Not Before: Jul  2 08:14:12 2022 GMT
                Not After : Jun 29 08:14:12 2032 GMT
            Subject: CN=kube-user1, O=kubernetes
            Subject Public Key Info:
                Public Key Algorithm: rsaEncryption
                    Public-Key: (2048 bit)
                    Modulus:
                        00:ac:01:43:70:a0:79:58:2d:3f:5c:36:6c:09:c5:
                        3e:66:6a:c1:8a:b4:70:02:ad:09:85:32:d4:8a:eb:
                        b5:6d:39:ad:03:b7:2a:17:25:59:b4:04:07:45:9c:
                        80:7e:ea:83:0c:31:00:4c:a5:86:6b:04:1c:36:22:
                        8f:1d:f5:9d:86:7b:99:1b:79:d5:64:2b:30:a4:c6:
                        0b:11:0e:b3:b9:f5:74:70:16:57:62:b2:e8:0c:5d:
                        3d:f3:4c:9b:c4:48:e3:c8:ab:2f:fe:2f:5f:7c:31:
                        65:d8:cd:30:d9:bf:aa:78:0b:3e:c3:9e:a6:ed:41:
                        33:7e:50:ac:85:fa:0c:e2:ea:75:44:ad:33:c5:21:
                        74:f4:30:d1:00:b2:8d:41:75:0d:48:28:ec:7a:13:
                        cb:35:09:52:3d:ef:0d:82:88:4f:42:e1:0a:6f:d6:
                        85:a0:15:c7:14:88:d8:7a:72:64:87:47:03:de:52:
                        9f:28:8a:73:c9:50:b5:8d:35:3b:cf:3a:8d:15:06:
                        8c:17:44:51:0f:34:24:de:af:ef:96:66:7f:21:58:
                        73:6b:ef:17:da:ee:ec:a3:be:62:3e:5f:9e:70:fe:
                        30:36:52:39:75:f3:aa:99:69:9a:b0:fc:bf:fc:a6:
                        29:23:5e:9b:13:01:de:cc:d8:75:5c:bc:3f:7b:b3:
                        5a:21
                    Exponent: 65537 (0x10001)
        Signature Algorithm: sha256WithRSAEncryption
             3f:65:ea:cc:c7:4e:d6:fe:43:78:4d:ee:8c:7f:9c:ed:b0:f0:
             70:97:19:72:2d:86:dd:3b:10:b9:e5:e1:82:b8:5b:0a:dc:2e:
             49:31:2c:b0:6c:40:f1:34:76:4b:97:12:d1:17:33:a2:79:e4:
             83:6e:14:74:73:b8:b3:b5:03:4a:26:47:09:e9:20:dd:2c:32:
             52:3b:59:ad:bf:10:09:2b:dc:1c:9a:1c:1e:a5:b0:af:d6:14:
             d7:ad:85:65:8f:02:0d:a0:ea:c2:d9:7c:51:77:c8:79:c1:5c:
             ed:f6:c1:0e:c2:70:72:32:79:d6:16:db:8e:0d:c6:00:ea:07:
             4d:d5:86:ca:e7:5e:93:16:0e:d8:f8:50:3c:5e:cf:58:a8:3b:
             ba:ef:4e:c7:f5:94:cf:a1:cf:dd:a2:d6:c7:c5:fa:50:ca:55:
             83:fd:32:03:fb:43:08:f6:fc:c5:56:b0:9e:47:8d:74:a9:fa:
             17:55:1f:ad:55:ec:6e:62:fb:9e:fd:b9:23:a0:85:ec:7a:7d:
             61:2b:68:7a:50:23:9b:2a:e7:0e:c8:1c:b7:3c:b4:1b:e9:4b:
             73:af:54:b8:c4:18:87:ff:6e:03:7d:6a:19:53:1b:d6:c8:22:
             d2:17:7d:e5:22:e7:45:c1:bf:79:b1:90:b0:a4:73:c0:a5:25:
             1d:06:52:72
    [root@k8s-master01-test-2-26 pki]# 

  第二步,以默认的管理员 kubernetes-admin@cluster.local 为新建的 kube-user1 设定 kube-config 配置文件。配置结果将默认保存于当前系统用户的 .kube/config 文件中,当然也可以为 kubectl 使用 --kubecofig 选项指定自定义的专用文件路径。

  1. 配置新集群信息(集群名称是 cluster.local 是已经存在了,我新建集群名称为 kubernets 集群),包括集群名称、API Server URL 和 CA 证书,若默认集群已然存在,则可省略此步骤,另外,(注意)提供的新配置不能与现有配置中的集群名称相同,否则将覆盖它们!
    [root@k8s-master01-test-2-26 pki]# kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server="https://172.16.0.26:6443"
    Cluster "kubernetes" set.
    [root@k8s-master01-test-2-26 pki]# 
  2. 配置客户端证书及密钥,用户信息会通过命令从证书 Subject 的 CN 值中自动提取,例如前面创建 csr 时使用的 "CN=kube-user1",而组名则来自于 "O=kubernetes" 的定义。
    [root@k8s-master01-test-2-26 pki]# kubectl config set-credentials kube-user1 --embed-certs=true --client-certificate=/etc/kubernetes/pki/kube-user1.crt --client-key=/etc/kubernetes/pki/kube-user1.key 
    User "kube-user1" set.
    [root@k8s-master01-test-2-26 pki]# 
  3. 配置 context,用来组合 cluster 和 credentials,即访问的集群的上下文。如果为管理多个集群而设置了多个环境,则可以使用 use-context 来进行切换:
    [root@k8s-master01-test-2-26 pki]# kubectl config set-context kube-user1@kubernetes --cluster=kubernetes --user=kube-user1
    Context "kube-user1@kubernetes" created.
    [root@k8s-master01-test-2-26 pki]# 
  4. 最后指定要使用的上下文,切换为以 kube-user1 访问集群:
    [root@k8s-master01-test-2-26 pki]# kubectl config use-context kube-user1@kubernetes
    Switched to context "kube-user1@kubernetes".
    [root@k8s-master01-test-2-26 pki]# 
  5. 测试访问集群资源,不过在启用 RBAC 的集群上执行命令时,kube-user1 并未获得集群资源的访问权限,因此会出现错误提示:
    [root@k8s-master01-test-2-26 pki]# kubectl --context=kube-user1@kubernetes get pods
    Error from server (Forbidden): pods is forbidden: User "kube-user1" cannot list resource "pods" in API group "" in the namespace "default"
    [root@k8s-master01-test-2-26 pki]#

此时,

  若需要切换至管理员帐号,则可使用 "kubeclt config use-context kubernetes-admin@kubernetes" 命令来完成(1.24.1版本:kubectl config use-context kubernetes-admin@cluster.local)。

  若需要临时使用某 context 时,不必设置 current-context,只需要为 kubectl 命令使用 --context 选项指定目标 context 的名称即可,如"kubectl --context=kube-user1@kubernetes get pods"。

三、TLS bootstrapping 机制

 

标签:pki,Kubernetes,kubernetes,user1,X.509,集群,kube,root,数字证书
来源: https://www.cnblogs.com/zuoyang/p/16437585.html