kubernetes快速入门11-认证和授权

kubernetes快速入门11-认证和授权

kubernetes快速入门11-认证和授权

认证

k8s的API Server接口是需要认证才能接入的，在使用kubeadm工具初化好master节点时，最后需要我们做sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config这个操作，admin.conf文件里存放的就是连接API Server所需要的认证信息，所以当我们使用kubectl命令进行操作时都会拿着该文件内的认证信息去连接API Server，认证通过后才能进行相应的操作。

API Server是Restful风格的接口，所以可以使用curl命令以Server接口，但API Server需要认证，而curl命令无法使用证书，不过k8s的kubectl命令可以运行一个API Server的服务，监听在某个端口上，该服务与API Server进行认证，而用户可以直接使用kubectl proxy --port 8801 Starting to serve on 127.0.0.1:8801 # 另起一终端 k8s@node01:~$ curl http://localhost:8801/api/v1/namespaces/default/ { "kind": "Namespace", "apiVersion": "v1", "metadata": { "name": "default", "selfLink": "/api/v1/namespaces/default", "uid": "9b85c3d7-6f39-4e32-9b58-ccdb9925474d", "resourceVersion": "152", "creationTimestamp": "2020-07-22T09:02:50Z", "managedFields": [ { "manager": "kube-apiserver", "operation": "Update", "apiVersion": "v1", "time": "2020-07-22T09:02:50Z", "fieldsType": "FieldsV1", "fieldsV1": {"f:status":{"f:phase":{}}} } ] }, "spec": { "finalizers": [ "kubernetes" ] }, "status": { "phase": "Active" } }

API Server的接口众多，可以慢慢探索。API Server只能接收JSON类型的数据，输出也是JSON数据，在应用yaml资源清单文件时，kubectl会先把yaml转换为json数据后再传递给API Server。

k8s集群中pod有可能也需要与API Server进行交互，如运行CoreDNS和dashboard，他们也是运行在pod中，但他们就需要和API Server进行交互，那就相应的pod也要有认证信息。每一个pod被创建后都会被挂载一个类型为Secret的卷，该卷存放的就是pod连接API Server的认证信息。

k8s@node01:~$ kubectl describe pod myapp-0 ... Volumes: myappdata: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) ClaimName: myappdata-myapp-0 ReadOnly: false default-token-ndclg: # 认证相关信息 Type: Secret (a volume populated by a Secret) SecretName: default-token-ndclg Optional: false ... k8s@node01:~$ kubectl get secret NAME TYPE DATA AGE default-token-ndclg kubernetes.io/service-account-token 3 7d21h k8s@node01:~$ kubectl describe secret default-token-ndclg Name: default-token-ndclg Namespace: default Labels: Annotations: kubernetes.io/service-account.name: default kubernetes.io/service-account.uid: 6fa06266-e97c-4665-9793-a6401ad4ff54 Type: kubernetes.io/service-account-token Data ==== token: .... ca.crt: 1025 bytes namespace: 7 bytes

pod与API Server交互使用的是pod网段的地址，与之对应的service为kubernetes

k8s@node01:~$ kubectl describe svc kubernetes Name: kubernetes Namespace: default Labels: component=apiserver provider=kubernetes Annotations: Selector: Type: ClusterIP IP: 10.96.0.1 # service地址 Port: 443/TCP TargetPort: 6443/TCP Endpoints: 192.168.101.40:6443 # 主节点的API Server Session Affinity: None Events:

每一个pod都是需要连接API Server的，都有一个默认的帐号信息(通过kubectl get secret获取)，该帐号只被授权获取与自己Pod相关的信息。如果pod中的应用程序需要连接API Server进行一些操作，那可能需要为此新建一个帐号并配置好认证信息，这些操作都可以通过kubectl create serviceaccount相关命令创建。

ServiceAccount也是k8s中的标准资源，可简写为sa，可以使用kubectl explain serviceAccount相应字段的帮助信息。也可以使用kubectl create serviceaccount创建。只要支持kubectl create创建的资源，可以使用--dry-run -o yaml输出创建该资源的一个yaml的资源清单框架信息，再在此上进行修改就可以定义出自己需要有清单文件。

k8s@node01:~$ kubectl create serviceaccount mysa --dry-run=client -o yaml apiVersion: v1 kind: ServiceAccount metadata: creationTimestamp: null name: mysa # 创建一个serviceaccount k8s@node01:~$ kubectl create sa mysa serviceaccount/mysa created k8s@node01:~$ kubectl get serviceaccount NAME SECRETS AGE default 1 7d21h mysa 1 13m k8s@node01:~$ kubectl describe sa mysa Name: mysa Namespace: default Labels: Annotations: Image pull secrets: # 这是另一种在拉取私有仓库的image时的认证方式，前边说过"pod.spec.imagePullSecrets"的方式 # 也可以把认证信息附加在serviceaccount中，使用serviceaccount.imagePullSecrets查看帮助 Mountable secrets: mysa-token-fq592 # 创建好用户后会自动创建一个进行认证的token信息 Tokens: mysa-token-fq592 Events: k8s@node01:~$ kubectl get secret NAME TYPE DATA AGE default-token-ndclg kubernetes.io/service-account-token 3 7d21h ingress- kubernetes.io/tls 2 2d4h mysa-token-fq592 kubernetes.io/service-account-token 3 11s mysql-password Opaque 1 20h

serviceaccount只是创建的帐户可以通过API Server的认证，但认证不等于有权限。

要想pod使用自定义的帐号，则使用pod.spec.serviceAccountName指定。

管理多套k8s集群

kubectl可以管理多套k8s集群，只需要配置好各k8s的集群信息，用户及认证信息，kubectl提供了kubectl config来配置相应的信息

k8s@node01:~$ kubectl config view apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://192.168.101.40:6443 name: kubernetes contexts: - context: cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetes current-context: kubernetes-admin@kubernetes kind: Config preferences: {} users: - name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED

k8s集群master初完成后会在/etc/kubernetes/pki下存放所有的关于认证的key信息

k8s@node01:/etc/kubernetes/pki$ tree . . ├── apiserver.crt ├── apiserver-etcd-client.crt ├── apiserver-etcd-client.key ├── apiserver.key ├── apiserver-kubelet-client.crt ├── apiserver-kubelet-client.key ├── ca.crt ├── ca.key ├── etcd │   ├── ca.crt │   ├── ca.key │   ├── healthcheck-client.crt │   ├── healthcheck-client.key │   ├── peer.crt │   ├── peer.key │   ├── server.crt │   └── server.key ├── front-proxy-ca.crt ├── front-proxy-ca.key ├── front-proxy-client.crt ├── front-proxy-client.key ├── sa.key └── sa.pub

接下来演示在此集群中再创建一个用户来管理该集群

# 创建用户相关的证书 k8s@node01:/etc/kubernetes/pki$ (sudo umask 077; sudo openssl genrsa -out usertom.key 2048) sudo: umask: command not found Generating RSA private key, 2048 bit long modulus (2 primes) .................+++++ ....+++++ e is 65537 (0x010001) # 生成证书签署请求，-subj中必须为用户的名称 k8s@node01:/etc/kubernetes/pki$ sudo openssl req -new -key usertom.key -out usertom.csr -subj "/CN=usertom" k8s@node01:/etc/kubernetes/pki$ sudo openssl x509 -req -in usertom.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out usertom.crt -days 3650 Signature ok subject=CN = usertom Getting CA Private Key # 验证证书有效时长 k8s@node01:/etc/kubernetes/pki$ sudo openssl x509 -noout -dates -in usertom.crt notBefore=Jul 30 07:40:03 2020 GMT notAfter=Jul 28 07:40:03 2030 GMT # 查看证书的详细信息 k8s@node01:/etc/kubernetes/pki$ sudo openssl x509 -noout -text -in usertom.crt Certificate: Data: Version: 1 (0x0) Serial Number: 51:8a:af:32:cc:b6:85:73:03:9f:2a:d0:b2:d0:08:55:e0:d1:95:bd Signature Algorithm: sha256WithRSAEncryption Issuer: CN = kubernetes Validity Not Before: Jul 30 07:40:03 2020 GMT # 有效期 Not After : Jul 28 07:40:03 2030 GMT Subject: CN = usertom Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:bd:ca:3d:14:dc:6b:12:fb:45:67:28:bb:70:e2: cd:0c:29:49:eb:f9:0b:62:df:7c:02:21:8e:60:e1: ... Exponent: 65537 (0x10001) Signature Algorithm: sha256WithRSAEncryption 18:bf:02:e4:f5:cf:f8:eb:4e:0a:0e:ee:f4:f7:06:1b:73:ca: 5b:ad:a2:e8:0e:88:4b:69:29:e3:8b:bb:33:1d:0a:57:19:53: ...

用户认证信息及证书已准备好，现在就把此用户增加到config中

k8s@node01:/etc/kubernetes/pki$ sudo kubectl config set-credentials usertom --client-certificate=./usertom.crt --client-key=./usertom.key --embed-certs=true User "usertom" set. k8s@node01:/etc/kubernetes/pki$ kubectl config view apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://192.168.101.40:6443 name: kubernetes contexts: - context: cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetes current-context: kubernetes-admin@kubernetes kind: Config preferences: {} users: - name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED - name: usertom # 用户已创建 user: client-certificate-data: REDACTED client-key-data: REDACTED # 增加上下文，让usertom用户也管理名称为kubernetes的集群，set-context时的名称必须为“用户名@集群名” k8s@node01:/etc/kubernetes/pki$ kubectl config set-context usertom@kubernetes --cluster=kubernetes --user=usertom Context "usertom@kubernetes" created # 切换current-context的用户 k8s@node01:/etc/kubernetes/pki$ kubectl config use-context usertom@kubernetes Switched to context "usertom@kubernetes". k8s@node01:/etc/kubernetes/pki$ kubectl get pods # 新用户未授权，被拒绝访问 Error from server (Forbidden): pods is forbidden: User "usertom" cannot list resource "pods" in API group "" in the namespace "default" # 切回默认用户 k8s@node01:/etc/kubernetes/pki$ kubectl config use-context kubernetes-admin@kubernetes Switched to context "kubernetes-admin@kubernetes".

创建集群也很简单，需要另一集群的ca证书，api server的访问地址，如下边的命令

# ca.crt应该为要加入集群的证书，这里使用了本集群的ca证书，只作演示所用，以免影响现有集群，使用--kubeconfig选项生成新的配置文件 k8s@node01:~$ kubectl config set-cluster mycluster --kubeconfig=/tmp/test.conf --server="--certificate-authority=/etc/kubernetes/pki/ca.crt k8s@node01:~$ kubectl config view --kubeconfig=/tmp/test.conf apiVersion: v1 clusters: - cluster: certificate-authority: /etc/kubernetes/pki/ca.crt server: https://192.168.101.222:6443 name: mycluster contexts: null current-context: "" kind: Config preferences: {} users: null

授权

k8s的授权也是插件化实现，主要的插件有Node，ABAC，RBAC，Webhook

RBAC：Role-based AC 基于角色的访问控制

k8s中的RBAC是许可授权，意思是许可授权做什么，不可定义不可做什么。

k8s中的资源URL通用格式：

/apis///namespaces//[/OBJECT_ID]

k8s中资源分属于两种级别：集群级别和名称空间级别

Role和RoleBinding： 角色和角色绑定，针对名称空间生效

ClusterRole和ClusterRoleBinding：集群角色和集群角色绑定，这是针对集群，即对集群的所有名称空间生效

ClusterRole和RoleBinding也可以进行绑定，这种跨界绑定代表相应用户拥有集群多个名称空间的相应权限，如：一个用户需要在多个名称空间拥有相同的权限，可以在每个名称空间中定义Role和RoleBinding完成定义，也可以不定义Role而定义一个ClusterRole，并让ClusterRole和RoleBinding完成绑定关系。

k8s中有两种用户：user account和service account，授权是针对role，一个user和相应Role进行RoleBinding后让user拥有Role的相应权限。此种绑定是在名称空间级别。

Role和RoleBinding

Role是k8s的标准资源对象，可以使用kubectl create role --help和kubectl explain role查看相应的帮助信息。

# 创建一个Role资源对象 8s@node01:~$ kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run=client -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: pods-reader rules: - apiGroups: - "" resources: - pods verbs: - get - list - watch k8s@node01:~$ kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run=client -o yaml > my_manifests/rbac/role-demo.yaml # 可以对资源清单文件稍做调整 k8s@node01:~/my_manifests/rbac$ cat role-demo.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pods-reader namespace: default rules: - apiGroups: - "" resources: - pods verbs: - get - list - watch k8s@node01:~/my_manifests/rbac$ kubectl apply -f role-demo.yaml role.rbac.authorization.k8s.io/pods-reader created k8s@node01:~/my_manifests/rbac$ kubectl get role NAME CREATED AT pods-reader 2020-07-31T02:16:19Z

RoleBinding也是k8s的标准资源对象，可以使用kubectl explain rolebinding和kubectl create rolebinding --help查看相应的帮助信息

# 创建一个RoleBinding资源对象 k8s@node01:~/my_manifests/rbac$ kubectl create rolebinding usertome-read-pods --role=pods-reader --user=usertom --dry-run=client -o yaml > rolebinding-demo.yaml # 对资源清单文件可以稍做修改，增加名称空间，默认也是default，只是习惯。rolebinding与user进行绑定，user需要事先增加 k8s@node01:~/my_manifests/rbac$ cat rolebinding-demo.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: creationTimestamp: null name: usertome-read-pods namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pods-reader subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: usertom k8s@node01:~/my_manifests/rbac$ kubectl apply -f rolebinding-demo.yaml rolebinding.rbac.authorization.k8s.io/usertome-read-pods created k8s@node01:~/my_manifests/rbac$ kubectl get rolebinding NAME ROLE AGE usertome-read-pods Role/pods-reader 8s

切换到usertome用户测试

k8s@node01:~$ kubectl config use-context usertom@kubernetes Switched to context "usertom@kubernetes". k8s@node01:~$ kubectl get pods # 可以正常获取pod信息 NAME READY STATUS RESTARTS AGE myapp-0 1/1 Running 1 24h myapp-1 1/1 Running 1 24h myapp-2 1/1 Running 1 24h k8s@node01:~$ kubectl get pods -n kube-system # rolebinding只对指定的名称空间有效 Error from server (Forbidden): pods is forbidden: User "usertom" cannot list resource "pods" in API group "" in the namespace "kube-system"

ClusterRole和ClusterRoleBinding

clusterrole和clusterrolebinding都是k8s中的标准资源对象，可以使用kubectl create clusterrole|clusterrolebinding --help和kubectl explain clusterrole|clusterrolebinding查看帮助信息

# 先切换回管理用户 k8s@node01:~/my_manifests/rbac$ kubectl config use-context kubernetes-admin@kubernetes Switched to context "kubernetes-admin@kubernetes". # 删除usertom与rolebinding的绑定关系 k8s@node01:~/my_manifests/rbac$ kubectl delete rolebinding usertome-read-pods rolebinding.rbac.authorization.k8s.io "usertome-read-pods" deleted # 创建clusterrole k8s@node01:~/my_manifests/rbac$ kubectl create clusterrole all-pods-reader --verb=get,list,watch --resource=pods clusterrole.rbac.authorization.k8s.io/all-pods-reader created # 绑定clusterrolebinding k8s@node01:~/my_manifests/rbac$ kubectl create clusterrolebinding usertom-all-pods-reader --clusterrole=all-pods-reader --user=usertom clusterrolebinding.rbac.authorization.k8s.io/usertom-all-pods-reader created # 切换用户并测试 k8s@node01:~/my_manifests/rbac$ kubectl config use-context usertom@kubernetes Switched to context "usertom@kubernetes". k8s@node01:~/my_manifests/rbac$ kubectl get pods NAME READY STATUS RESTARTS AGE myapp-0 1/1 Running 1 25h myapp-1 1/1 Running 1 25h myapp-2 1/1 Running 1 25h k8s@node01:~/my_manifests/rbac$ kubectl delete pod myapp-0 # 没有赋予角色delete权限，删除失败 Error from server (Forbidden): pods "myapp-0" is forbidden: User "usertom" cannot delete resource "pods" in API group "" in the namespace "default" k8s@node01:~/my_manifests/rbac$ kubectl get pods -n kube-system # 各个名称空间的Pod都可以获取 NAME READY STATUS RESTARTS AGE coredns-66bff467f8-9tfh6 1/1 Running 113 7d coredns-66bff467f8-sxpb7 1/1 Running 112 7d etcd-node01 1/1 Running 8 8d kube-apiserver-node01 1/1 Running 10 8d kube-controller-manager-node01 1/1 Running 50 8d kube-flannel-ds-amd64-djjs7 1/1 Running 9 8d kube-flannel-ds-amd64-hthnk 1/1 Running 9 8d kube-flannel-ds-amd64-zkdpp 1/1 Running 8 8d kube-proxy-2ck9j 1/1 Running 5 3d19h kube-proxy-r2v2p 1/1 Running 8 8d kube-proxy-vlbxb 1/1 Running 9 8d kube-scheduler-node01 1/1 Running 44 8d

同样可以保存为yaml格式的资产清单文件进行apply应用后生成相应的资源对象。

ClsterRole与RoleBinding绑定

ClsterRole与RoleBinding进行绑定时ClsterRole中的权限会被降级成只在RoleBinding中的名称空间有效。

# 切换回管理用户并删除clusterrolebinding k8s@node01:~/my_manifests/rbac$ kubectl config use-context kubernetes-admin@kubernetes Switched to context "kubernetes-admin@kubernetes". k8s@node01:~/my_manifests/rbac$ kubectl delete clusterrolebinding usertom-all-pods-reader clusterrolebinding.rbac.authorization.k8s.io "usertom-all-pods-reader" deleted # 把ClusterRole使用Rolebinding进行绑定 k8s@node01:~/my_manifests/rbac$ kubectl create rolebinding usertom-get-pods --clusterrole=all-pods-reader --user=usertom rolebinding.rbac.authorization.k8s.io/usertom-get-pods created # 切换用户测试 k8s@node01:~/my_manifests/rbac$ kubectl get pods NAME READY STATUS RESTARTS AGE myapp-0 1/1 Running 1 25h myapp-1 1/1 Running 1 25h myapp-2 1/1 Running 1 25h k8s@node01:~/my_manifests/rbac$ kubectl get pods -n kube-system # 本该有获取其他名称空间的权限，但与Rolebinding进行绑定后只能获取Rolebing资源所在名称空间的相应权限，默认为default Error from server (Forbidden): pods is forbidden: User "usertom" cannot list resource "pods" in API group "" in the namespace "kube-system"

ClusterRole中admin的用途

在ClusterRole资源中有个名为admin的资源，该名称的资源定义了集群级别的一个拥有管理权限的角色。使用kubectl get clusterrole admin -o yaml查看其定义的详细权限。如果想在每个集群内的名称空间内创建一个用户拥有管理功能，那可直接绑定admin这个ClusterRole，即使用RoleBinding来绑定ClusterRole。

# 确保使用管理用户 k8s@node01:~/my_manifests/rbac$ kubectl config use-context kubernetes-admin@kubernetes # 绑定 k8s@node01:~/my_manifests/rbac$ kubectl create rolebinding usertom-ns-admin --clusterrole=admin --user=usertom rolebinding.rbac.authorization.k8s.io/usertom-ns-admin created # 切换用户测试 k8s@node01:~/my_manifests/rbac$ kubectl config use-context usertom@kubernetes Switched to context "usertom@kubernetes". k8s@node01:~/my_manifests/rbac$ kubectl get pods NAME READY STATUS RESTARTS AGE myapp-0 1/1 Running 1 26h myapp-1 1/1 Running 1 26h myapp-2 1/1 Running 1 26h k8s@node01:~/my_manifests/rbac$ kubectl get pods -n kube-system # 其他用户空间不可获取相应资源 Error from server (Forbidden): pods is forbidden: User "usertom" cannot list resource "pods" in API group "" in the namespace "kube-system" k8s@node01:~/my_manifests/rbac$ kubectl delete pod myapp-0 # 用本名称空间的资源可以删除 pod "myapp-0" deleted k8s@node01:~/my_manifests/rbac$ kubectl get pods NAME READY STATUS RESTARTS AGE myapp-0 1/1 Running 0 4s myapp-1 1/1 Running 1 26h myapp-2 1/1 Running 1 26h

默认用户权限探索

为什么默认用户可以操作集群中的所有资源？

集群中存在一个名为cluster-admin的clusterrole

k8s@node01:~$ kubectl get clusterrole cluster-admin -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: "2020-07-22T09:02:49Z" labels: kubernetes.io/bootstrapping: rbac-defaults managedFields: - apiVersion: rbac.authorization.k8s.io/v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:annotations: .: {} f:rbac.authorization.kubernetes.io/autoupdate: {} f:labels: .: {} f:kubernetes.io/bootstrapping: {} f:rules: {} manager: kube-apiserver operation: Update time: "2020-07-22T09:02:49Z" name: cluster-admin resourceVersion: "44" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-admin uid: 3613d9c3-51cf-4c89-bc82-7ad6abf41ff9 rules: # 拥有对所有资源的全部权限 - apiGroups: - '*' resources: - '*' verbs: - '*' - nonResourceURLs: - '*' verbs: - '*'

集群中也存在一个名为cluster-admin的clusterrolebinding资源，把cluster-admin这个角色与system:masters组相绑定

k8s@node01:~$ kubectl get clusterrolebinding cluster-admin -o yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: "2020-07-22T09:02:49Z" labels: kubernetes.io/bootstrapping: rbac-defaults managedFields: - apiVersion: rbac.authorization.k8s.io/v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:annotations: .: {} f:rbac.authorization.kubernetes.io/autoupdate: {} f:labels: .: {} f:kubernetes.io/bootstrapping: {} f:roleRef: f:apiGroup: {} f:kind: {} f:name: {} f:subjects: {} manager: kube-apiserver operation: Update time: "2020-07-22T09:02:49Z" name: cluster-admin resourceVersion: "101" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin uid: e0373813-44b6-45d8-9b43-1f7be1aa84d2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin # clusterrole名称 subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:masters # 对一个名为 system:masters 组进行了绑定

只要用户属于system:masters这个组那就拥有了操作集群的所有权限。再来看看kubectl命令调用时使用的证书信息

k8s@node01:/etc/kubernetes/pki$ sudo openssl x509 -in apiserver-kubelet-client.crt -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 5217042427423920986 (0x4866a87258be935a) Signature Algorithm: sha256WithRSAEncryption Issuer: CN = kubernetes Validity Not Before: Jul 22 09:02:22 2020 GMT Not After : Jul 22 09:02:23 2021 GMT Subject: O = system:masters, CN = kube-apiserver-kubelet-client Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) ...

Subject: O = system:masters, CN = kube-apiserver-kubelet-client 组刚好是system:masters，而kubernetes-admin@kubernetes用户属于该组(也有说kubernetes-admin@kubernetes与kube-apiserver-kubelet-client是同一个用户，不知道如何考证)，所以该用户可以完全操作集群内的资源。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。