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

时间：2020-09-18 02:47:13 阅读：45 评论：0 收藏：0 [点我收藏+]

标签：应该 vat 准备 proxy 问控制 date 控制 base mysql

认证

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命令以http的方式来直接请求API Server接口，但API Server需要认证，而curl命令无法使用证书，不过k8s的kubectl命令可以运行一个API Server的服务，监听在某个端口上，该服务与API Server进行认证，而用户可以直接使用http的方式与kubectl运行的这个代理服务进行访问。

k8s@node01:~$ 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:       <none>
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:       <none>
Selector:          <none>
Type:              ClusterIP
IP:                10.96.0.1  # service地址
Port:              https  443/TCP
TargetPort:        6443/TCP
Endpoints:         192.168.101.40:6443  # 主节点的API Server
Session Affinity:  None
Events:            <none>

每一个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:              <none>
Annotations:         <none>
Image pull secrets:  <none>  # 这是另一种在拉取私有仓库的image时的认证方式，前边说过"pod.spec.imagePullSecrets"的方式
                                                         # 也可以把认证信息附加在serviceaccount中，使用serviceaccount.imagePullSecrets查看帮助
Mountable secrets:   mysa-token-fq592  # 创建好用户后会自动创建一个进行认证的token信息
Tokens:              mysa-token-fq592
Events:              <none>
k8s@node01:~$ kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-ndclg   kubernetes.io/service-account-token   3      7d21h
ingress-https         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="https://192.168.101.222:6443" --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/<GROUP>/<VERSION>/namespaces/<NAMESPACE_NAME>/<KIND>[/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是同一个用户，不知道如何考证)，所以该用户可以完全操作集群内的资源。

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

标签：应该 vat 准备 proxy 问控制 date 控制 base mysql

原文地址：https://blog.51cto.com/zhaochj/2533732

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行