Kubernetes 证书详解(鉴权)

简介

上一篇系统分析了 Kubernetes 集群中每个证书的作用和证书认证的原理。对于 Kube-apiserver，Kubelet 来说，它们都能提供 HTTPS 服务，Kube-apiserver、Kubelet 对于一个请求，既要认证也要鉴权。在 Kube-apiserver 中，鉴权也有多种方式：

Node
ABAC
RBAC
Webhook

在 TLS + RBAC 模式下，访问 Kube-apiserver 有三种方式：

证书 + RBAC(就是上一篇说到的那些证书)
Node + RBAC( Kubelet 访问 Kube-apiserver 时)
ServiceAccount + RBAC( Kubernetes 集群内 Pod 访问 Kube-apiserver ）

关于 RBAC 的内容不熟悉的可以参考官网

K8S 证书的 CN、O

RBAC 鉴权需要对 User 或者 Group 来绑定相应权限达到效果。Kubernetes 证书中的 CN 表示 User，O 表示 Group，看一个例子：

用 openssl 命令解析 kubelet 的客户端证书，kubelet 访问 Kube-apiserver 的时候就会用这个证书来认证，鉴权。

$ openssl x509 -noout -text -in kubelet-client-current.pem

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 271895513527774644 (0x3c5f7876bd86db4)

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: CN=kubernetes

        Validity

            Not Before: May 10 06:48:30 2023 GMT

            Not After : Apr 16 06:48:37 2123 GMT

				# 看这里

        Subject: O=system:nodes, CN=system:node:master-172-31-97-104

        Subject Public Key Info:

        .......

可以发现 Kubelet 的客户端证书的 O 是 system.nodes，CN 是 system:node:master-172-31-97-104 ，所以在 Kubernetes 中，每个结点的 Kubelet 都被赋予 *system:node:"结点名称"* 的 User，且附属于 *system.nodes* 的 Group。

Kubernetes RBAC 鉴权机制就是利用将权限绑定到 User 或者 Group，使得 User、Group 拥有对应权限，下面就看看 Kubernetes 如何根据证书、ServiceAccount 鉴权的。

Kubectl

Kubectl 使用 KubeConfig 与 Kube-apiserver 进行认证、鉴权。认证上一篇说过了，就是通过 TLS 认证。这里说鉴权，先看看 KubeConfig 的客户端证书 O、CN

使用 openssl 命令解析 KubeConfig 中 client-certificate-data 字段，查看 KubeConfig 客户端证书的 O、CN

$ cat /root/.kube/config | grep client-certificate-data: | sed 's/    client-certificate-data: //g' | base64 -d | openssl x509 -noout  -subject

# 结果

subject= /O=system:masters/CN=kubernetes-admin

可以发现 KubeConfig 客户端证书为 kubernetes-admin User 且属于 system:masters Group。

system:masters 是 Kubernetes 内置的用户组，且 Kubernetes 集群中也包含许多默认 ClusterRole、ClusterRolebinding，其中 cluster-admin 的 ClusterRolebinding 就将 cluster-admin 的 ClusterRole 绑定到 *system:masters* Group，这样 KubeConfig 就拥有权限来操作 Kube-apiserver 了。

# cluster-admin ClusterRole 拥有所有资源的所有权限

$ kubectl get clusterrole cluster-admin -o yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

  annotations:

    rbac.authorization.kubernetes.io/autoupdate: "true"

  creationTimestamp: "2023-05-10T06:49:27Z"

  labels:

    kubernetes.io/bootstrapping: rbac-defaults

  name: cluster-admin

  resourceVersion: "85"

  uid: 006af228-e6ef-43fa-a73f-ca0c109b13f0

rules:

- apiGroups:

  - '*'

  resources:

  - '*'

  verbs:

  - '*'

- nonResourceURLs:

  - '*'

  verbs:

  - '*'

-------------------------------------------------------------------

# cluster-admin ClusterRoleBinding 将 cluster-admin ClusterRole 绑定到 system:masters Group

$ kubectl get clusterrolebinding cluster-admin -o yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  annotations:

    rbac.authorization.kubernetes.io/autoupdate: "true"

  creationTimestamp: "2023-05-10T06:49:27Z"

  labels:

    kubernetes.io/bootstrapping: rbac-defaults

  name: cluster-admin

  resourceVersion: "147"

  uid: 980fbdff-6750-4957-b5fa-954a5013b192

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

	# clusterRole name

  name: cluster-admin

subjects:

- apiGroup: rbac.authorization.k8s.io

  kind: Group

	# Group name

  name: system:masters

经过上面的操作，Kubectl 就可以使用 KubeConfig 来操作 Kube-apiserver 了。

Kube-scheduler、Kube-controller-manager

同样 Kube-scheduler、Kube-controller-manager 也是使用各自的 KubeConfig 来认证、鉴权。但是他们和 Kubectl 的 KubeConfig 不属于同一个用户、组。

使用 openssl 命令解析 Kube-scheduler 的 KubeConfig 中 client-certificate-data 字段，查看 KubeConfig 客户端证书的 O、CN

$ cat /etc/kubernetes/scheduler.conf | grep client-certificate-data: | sed 's/    client-certificate-data: //g' | base64 -d | openssl x509 -noout  -subject

# 结果

subject= /CN=system:kube-scheduler

可以发现 KubeConfig 客户端证书为 kubernetes-admin User 但是不属于某个 Group。

system:kube-scheduler 也是 Kubernetes 集群内部的设置的用户，Kubernetes 集群中也存在对应默认的 ClusterRole system:kube-scheduler 和 ClusterRoleBinding system:kube-scheduler。

# system:kube-scheduler ClusterRole 拥有细分的权限

$ kubectl get clusterrole system:kube-scheduler -o yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

  annotations:

    rbac.authorization.kubernetes.io/autoupdate: "true"

  creationTimestamp: "2023-05-10T06:49:27Z"

  labels:

    kubernetes.io/bootstrapping: rbac-defaults

  name: system:kube-scheduler

  resourceVersion: "115"

  uid: b1ddf98c-bdb9-4d4d-9af3-9db1c97b038a

rules:

- apiGroups:

  - ""

  - events.k8s.io

  resources:

  - events

  verbs:

  - create

  - patch

  - update

- apiGroups:

  - coordination.k8s.io

  resources:

  - leases

  verbs:

  - create

- apiGroups:

  - coordination.k8s.io

  resourceNames:

  - kube-scheduler

  resources:

  - leases

  verbs:

  - get

  - update

- apiGroups:

  - ""

  resources:

  - endpoints

  verbs:

  - create

 .......

 # 一些更细致的权限

--------------------------------------------------------------------------

# system:kube-scheduler ClusterRoleBinding 将 system:kube-scheduler ClusterRole 绑定到 system:kube-scheduler User

$ kubectl get clusterrolebinding system:kube-scheduler -o yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  annotations:

    rbac.authorization.kubernetes.io/autoupdate: "true"

  creationTimestamp: "2023-05-10T06:49:27Z"

  labels:

    kubernetes.io/bootstrapping: rbac-defaults

  name: system:kube-scheduler

  resourceVersion: "155"

  uid: a9b8a85e-bb5c-483c-a08e-51822ce84d7f

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

	# ClusterRole name

  name: system:kube-scheduler

subjects:

- apiGroup: rbac.authorization.k8s.io

  kind: User

	# User name

  name: system:kube-scheduler

可以发现 Kube-scheduler 权限并不是向 Kubectl 那样拥有所有资源的所有操作权限，即使是内部组件，基于最小权限原则，Kubernetes 依然会为这两个用户只绑定必要的权限。

Kube-controller-manager 和 Kube-scheduler 一样，只不过 Kube-controller-manager 的 User 是 system:kube-controller-manager，其默认的 ClusterRole、ClusterRoleBinding 名称不同而已，可以根据 Kube-scheduler 自行验证~

system: 前缀是 Kubernetes 保留的关键字，用于描述内置的系统用户和系统用户组，在 Kube-apiserver 启动时，会默认为这些用户绑定好对应的权限，具体参考官网

Kubelet

Kubelet 同样也会访问 Kube-apiserver，Kubelet 使用其客户端证书与 Kube-apiserver 认证、鉴权。

使用 openssl 命令解析 Kubelet 客户端证书，查看证书的 O、CN

$ openssl x509 -noout  -subject -in /var/lib/kubelet/pki/kubelet-client-current.pem

# 结果

subject= /O=system:nodes/CN=system:node:master-172-31-97-104

可以发现 Kubelet 客户端证书为 system:node:master-172-31-97-104 User 且属于 system:nodes Group。

还是和上面一样，system:nodes 也是 Kubernetes 内置用户组，通过查看其默认的 ClusterRole、ClusterRoleBinding

$ kubectl get clusterrolebinding system:node -o yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

  annotations:

    rbac.authorization.kubernetes.io/autoupdate: "true"

  creationTimestamp: "2023-05-10T06:49:27Z"

  labels:

    kubernetes.io/bootstrapping: rbac-defaults

  name: system:node

  resourceVersion: "157"

  uid: 8ba46211-bdae-493f-8f5f-3386fe63ba29

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

  name: system:node

发现 system:node ClusterRoleBinding 并没有绑定 system:node:master-172-31-97-104 User 或者 system:nodes Group。官方文档也有介绍：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/#core-component-roles

实际上 Kubernetes 现在基于 Node Authorizer 来限制kubelet只能读取和修改本节点上的资源，并不是使用 RBAC 来鉴权。为了获得节点鉴权器的授权，Kubelet 必须使用一个凭证以表示它在 system:nodes 组中，用户名为 system:node:<nodeName>。这个凭证就是从 Kubelet 客户端证书获取，也就是上面的 O、CN

Node Authorizer 参考：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/node/

Kube-apiserver

前面都是在说其他组件访问 Kube-apiserver，然后 Kube-apiserver 对访问者进行授权，然而 Kube-apiserver 也会作为客户端去访问 Kubelet，例如：kubectl logs/exec，Kube-apiserver 都会去访问 Kubelet。Kubelet 作为服务端内部也是通过 TLS + RBAC 这种模式去认证、鉴权。

使用 openssl 命令解析 Kube-apiserver 客户端证书，查看证书的 O、CN

$ openssl x509 -noout  -subject -in /etc/kubernetes/pki/apiserver-kubelet-client.crt

# 结果

subject= /O=system:masters/CN=kube-apiserver-kubelet-client

可以发现 Kube-apiserver 访问 Kubelet 客户端证书为 kube-apiserver-kubelet-client User 且属于 system:masters Group。

在 Kubectl 章节介绍了 system:masters 属于内置用户组，且默认拥有超级权限，所以 Kube-apiserver 可以去访问 Kubelet 操作资源。

ServiceAccount

上面说的几种情况，都是根据 User 或者 Group 鉴别其是否拥有权限，ServiceAccount 和 User、Group 属于同一性质。

在 Kubernetes 集群内部，比如 Pod 需要访问 Kube-apiserver，就会使用其配置的 Service Account（没有配置，则使用默认) 与 Kube-apiserver 认证、鉴权。

通过一个例子来说明：

mysql 这个 Pod 配置 mysql-sa 这个 ServiceAccount

# pod 部分 yaml

nodeName: master-172-31-97-104

  preemptionPolicy: PreemptLowerPriority

  priority: 0

  restartPolicy: Always

  schedulerName: default-scheduler

  securityContext: {}

	# serviceAccount 配置

  serviceAccount: mysql-sa

  serviceAccountName: mysql-sa

  terminationGracePeriodSeconds: 10

  tolerations:

  - effect: NoSchedule

    key: node-role.kubernetes.io/master

    operator: Exists

  - effect: NoExecute

    key: node.kubernetes.io/not-ready

    operator: Exists

    tolerationSeconds: 300

  - effect: NoExecute

    key: node.kubernetes.io/unreachable

    operator: Exists

    tolerationSeconds: 300

然后查看对应 Role，查看拥有的权限

$ kubectl get role mysql-role -n test -o yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  name: mysql-role

  namespace: test

rules:

- apiGroups:

  - ""

  resources:

  - configmaps

  verbs:

  - get

  - list

  - watch

  - create

  - update

  - patch

  - delete

- apiGroups:

  - ""

  resources:

  - events

  verbs:

  - create

  - patch

查看 RoleBinding，然后会发现将上面的 Role 与 Pod 的 ServiceAccount 绑定。

$ kubectl get rolebinding mysql-role -n test -o yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: mysql-rolebinding

  namespace: test

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: Role

	# role name

  name: mysql-role

subjects:

- kind: ServiceAccount

	# serviceAccount name

  name: mysql-sa

  namespace: test

这样 mysql-sa ServiceAccount 就拥有了 Configmmap，Event 这两个资源的所有权限。

所以当 Pod 内部去访问 Kube-apiserver，实际上 Kube-apiserver 是根据其 ServiceAccount 来鉴定其拥有的权限，而不是 User 或者 Group。

总结

上面的鉴权原理，可以下面这张图做个总结

每个组件都代表着不同的 K8S 角色与 Kube-apiserver 鉴权。

到这里整个 Kubernetes 证书都讲解完了，包括认证、鉴权。掌握了 Kubernetes 组件之间的调用关系，以及双向 TLS 认证就可以理清证书的作用和关系，同时还需掌握证书内容的 O、CN、SANS 等字段作用，才能明白 Kubernetes 是如何根据证书 + RBAC 进行访问授权的。

最后有兴趣可以使用二进制部署一个 Kubernetes 集群，通过手动签发证书，来加深理解~

引用

Kubernetes 官方文档 Node Authorizer

Kubernetes 官方文档 RBAC

关注微信公众号，可了解更多云原生详情~