-
【CKA考试笔记】十五、安全管理：验证与授权
实验环境
完成初始化集群的环境：
（vms21）192.168.26.21——master1
（vms22）192.168.26.22——worker1
（vms23）192.168.26.23——worker2安装了k8s客户端工具的主机：
（vms41）192.168.26.41——client一、验证
概述
当我们登录master上时，似乎不需要任何验证就可以进行管理操作，这是因为我们使用root用户登录master上并操作，若我们通过其他用户或者在其他节点上进行kubectl相关命令操作时，就会显示拒绝连接
如下图所示：
以使用pc端的微信为例，我们登录pc的账号并不同于登录微信的账号，我们首先登录pc，然后使用微信的账号登录微信
k8s也一样，我们登录os后，需要用k8s的账号登录，只是在k8s中默认已经设置了root账号，所以我们通过root登录os时，便直接可以登录k8s，所以没有感知到登录验证，而使用其他账号（在k8s中并没有进行过设置的账号）则会显示失败
那么在k8s环境里是如何进行认证的？token 认证方式
用户以登录的方式来认证有以下两种：
（1）basic-auth-file：输入用户名、密码
（2）token-auth-file：输入token进行验证
将用户名、密码或token信息配置在master的/etc/kubernetes/manifests/kube-apiserver.yaml中
但在k8s v1.19之前（不包括v1.19），有basic-auth-file的认证方式（通过用户名密码的方式认证），后来取消了，因此这里我们只需要了解token的认证方式一：master上生成token
openssl rand -hex 10 #输出： 4a557575eaa52fe0555f- 1
- 2
- 3
二：master上，生成一个认证文件
/etc/kubernetes/pki/xxx.csv，把生成的token写入文件中
如：对mary用户生成一个认证文件bb.csvvim /etc/kubernetes/pki/bb.csv #文件中的格式如下： #token,用户,UUID 4a557575eaa52fe0555f,mary,3- 1
- 2
- 3
- 4
- 5
三：master上编辑/etc/kubernetes/manifests/kube-apiserver.yaml文件，在spec.containers.command下配置认证文件的路径
vim /etc/kubernetes/manifests/kube-apiserver.yaml #在spec.containers.command插入： - --token-auth-file=/etc/kubernetes/pki/bb.csv- 1
- 2
- 3
- 4
四：重启生效
systemctl restart kubelet- 1
测试：
另启一个虚拟机作为客户端（vms41）
一：安装k8s客户端工具#添加k8s的国内加速yum源k8s.repo，放入/etc/yum.repos.d/下 rm -rf /etc/yum.repos.d/* ; wget ftp://ftp.rhce.cc/k8s/* -P /etc/yum.repos.d/ yum install -y kubectl-1.24.2-0 --disableexcludes=kubernetes- 1
- 2
- 3
- 4
二：在master查询k8s服务器地址
kubectl cluster-info #输出： Kubernetes control plane is running at https://192.168.26.21:6443 CoreDNS is running at https://192.168.26.21:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.- 1
- 2
- 3
- 4
- 5
- 6
三：登录k8s，并执行命令：
get pods -n kube-system# -s：指定k8s服务器 # --token：使用token的验证方式连接 kubectl -s https://192.168.26.21:6443 --token=4a557575eaa52fe0555f get pods -n kube-system- 1
- 2
- 3
但此时会连接失败：
Unable to connect to the server: x509: certificate signed by unknown authority- 1
这是因为k8s中所有的组件（kube-apiserver、kube-controller-manager…）之间若想要相互进行通信，都需要进行加密认证——证书的认证 TLS
我们可以以跳过认证的方式来连接# --insecure-skip-tls-verify=true：跳过TLS认证 kubectl --insecure-skip-tls-verify=true -s https://192.168.26.21:6443 --token=4a557575eaa52fe0555f get pods -n kube-system- 1
- 2
若出现：
Error from server (Forbidden): pods is forbidden: User "mary" cannot list resource "pods" in API group "" in the namespace "kube-system"- 1
意为mary用户权限不够，只要在master上给mary用户授权即可
kubectl create clusterrolebinding cbind1 --clusterrole cluster-admin --user=mary- 1
授权后就可以连接了
kubectl --insecure-skip-tls-verify=true -s https://192.168.26.21:6443 --token=4a557575eaa52fe0555f get pods -n kube-system #输出： NAME READY STATUS RESTARTS AGE calico-kube-controllers-56cdb7c587-xk97l 1/1 Running 18 (27m ago) 27d calico-node-4vfw4 1/1 Running 23 (27m ago) 27d calico-node-69h65 1/1 Running 17 (27m ago) 27d calico-node-k8btq 1/1 Running 17 (27m ago) 27d coredns-74586cf9b6-rlkhp 1/1 Running 17 (27m ago) 27d coredns-74586cf9b6-x5vld 1/1 Running 17 (27m ago) 27d etcd-vms21.rhce.cc 1/1 Running 22 (27m ago) 27d kube-apiserver-vms21.rhce.cc 1/1 Running 1 (27m ago) 22h kube-controller-manager-vms21.rhce.cc 1/1 Running 23 (27m ago) 27d kube-proxy-d9lsg 1/1 Running 18 (27m ago) 27d kube-proxy-f6dbr 1/1 Running 18 (27m ago) 27d kube-proxy-lgjsd 1/1 Running 17 (27m ago) 27d kube-scheduler-vms21.rhce.cc 1/1 Running 23 (27m ago) 27d metrics-server-58556b7dd4-cpth2 1/1 Running 16 (27m ago) 27d- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
删除mary的权限
kubectl delete clusterrolebinding cbind1- 1
kubeconfig 认证方式
k8s中各组件若想要相互通信，则需要TLS认证—mTLS（双向认证）
什么是mTLS双向认证？如下图：
apiserver组件要与kubelet组件相互通信，首先由一个权威的机构（CA）来给各组件颁发证书，包含用户证书和CA证书，kubelet连接到apiserver，需要出示自己的用户证书，apiserver通过自己的CA证书来验证对方用户证书的真伪性，同样，apiserver也需要向kubelet出示用户证书，kubelet使用自己CA证书来验证对方用户证书，这种相互认证对方证书即双向认证
同样的，若有某远端客户端连接到apiserver，也需要进行双向认证
使用kubeconfig的认证方式，我们需要编写kubeconfig文件
因为k8s组件间需要TLS认证，因此kubeconfig文件中需要包含三部分信息：
1.cluster信息：
（1）集群的地址
（2）CA证书（CA颁发的证书，用于验证对方出示的用户证书）
2.上下文信息：
（1）关联了集群信息与用户信息
（2）其他一些默认的用户信息，如所处的命名空间等
3.用户信息：
（1）用户私钥
（2）用户证书（CA颁发的证书，出示给对方以供验证）查看kubeconfig文件结构
kubectl config view #输出： apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://192.168.26.21:6443 name: kubernetes contexts: - context: cluster: kubernetes namespace: net 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- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
当我们使用root用户登录k8s的时候，默认使用的就是kubeconfig的认证方式，他使用的kubeconfig文件就是“/etc/kubernetes/admin.conf”
查看/etc/kubernetes/admin.confvim /etc/kubernetes/admin.conf #输出： apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1EY3dOakE1TkRjME4xb1hEVE15TURjd016QTVORGMwTjFvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTW1DCjNOZFdJcXpVV1B6Yk1hYS9jZTR3NW14ZjBRUUdHTkhqb1lhOHR6S0c3VDNObVBMTDRpTHlhQ05ESUUxeTBLRlEKK1RtZGFCSll4M1U0ZE5ZTHNTZEVWcUI1ajNSem5xNUo2L1BPbTBjVW5yY0VxUFFYN0w5MXNNZU90QlZOdWYyRApRc01ZV3lpK3NXUVMxYVhqTHZyaUdWYXRGd0dDSmhTbHlLTENvODdNOHdHbjZzeWlyaXhNdG1sZURLdlJMYkZRCnRhMzRWSVRlQVg3R3VsckJKQmZEMmRxZXY5K0EzZytWMU5KeXo5TXJ0Tkh5THM5ZWNUcnZpbE1JTW55MmUyMDcKZHRGc2V6MmhyenZhRkpIdzVzcDE3enozUHZXcS83ang1YU9lWEdtaU1NemxQSWhJV1JlbU11UWhmVjRsekVrRApzYUtrV05NNEpvSDlsdDZpb21NQ0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZMUmlpc0hQMmVERTE4THBGZVFHcVg2WDR4SXFNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBSTBMWXU0Q3ArL1ZZME9oaEU5WgpZT09Ob2JmTTg5SG9wVnFCVkZtd1Q1cGliS1pXYmZidGQ5bjg5T3p0WlJrSlBLOGNpOCtwRmpleDJFVGNzRWVTCkxveisyRFN3T1VrSnJ2OHl1VjJPZDI2Q3hIMDFEZ1NjcTJMSlRhNG1EVi93b0ZFYlNGTVVyaUVtRXZRdHZsengKMTlMTWJTOUdVdWtCaURhVWp2U0xqOVViS3lWZ3JnUVdWUlJaY0hHamY5c3dYRmU4NVdUQVJiR1Q2R09ZVnZyQQoxa3JSQlhZSGhKSGxKeEptVXJTSDc5c2pHeGdCQy9qR1ppZURPa2RNVWhDbTFFQ3BTcnBFakhKTml2KzY3Nnh1CkdUbmR5ejk2TFZUM1A3U0phV0tEcThvNTFNcmRNTExiZGVWSE04TkVrWTR1b3UxTkUrVEJtU2lCQlQvL2ZHRnUKdXUwPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== server: https://192.168.26.21: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: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURJVENDQWdtZ0F3SUJBZ0lJUnVuazhVcGVwWFF3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExVUUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TWpBM01EWXdPVFEzTkRkYUZ3MHlNekEzTURZd09UUTNORGxhTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcHRZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXEwdnBWZHVRdFJlMHVWY1QKdHBjWURFU05SM1J4Q1pBZ0FkOEw4Visyc0VlelRKKzhld1d2NEs4ZGY0alVjTXREQUdreUFNZWRJd3hHc2JDVgp1UU1HY2V4YzVyWUNiUm81ekNGMUhFM09OMmZvelZtSWVLL0NyUGRJUnJQdFVaS1NDVUlpNDhIL1dvN1ltdG9rCnhUaFZhUW84T0NZSFFtZThPbjZRUW56MTdpTEhSV241NUE0QjlYWlVCRTNUaXFEUGlWbWlJemJLZ1BhSFJDV0IKRWxwUS9XUXNrV1B3WUJkMXR3cFhLRzBsQ2xwcUI3TTJocEo1RmM4WVBKL2pEeE9DTHFZeXdmQWFhUHoyVjNxdQpUcWppaXM4aSt4bEJrbGxXUERldFhwWHB3Y0JTVnIwS3FJRE9BTFdhMGRwWDRoekFnMVB2Y0c3eG9aZkpWeTRzCnNwdFJKUUlEQVFBQm8xWXdWREFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RBWURWUjBUQVFIL0JBSXdBREFmQmdOVkhTTUVHREFXZ0JTMFlvckJ6OW5neE5mQzZSWGtCcWwrbCtNUwpLakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBY003Vy82YlcwemUyUVMxMThKYlBMeFJlWGV4L2ZTbXZzMFNBCi9qQWlEZXM4RDU4dkVuZmVwTGp1TUR0MTNQRXdyUW5QQXQxY1J4UElqODlwR0FhS2dkNDV3MVE5RzBrbGNsR2UKelcrNkl2TzM5KzVKT1ozSCtzK3UzQlJkTzZJc0RiREN2dE5tVm0vRmt4QTZsSnAwbG9jWE44SW1neWE4SXYxMgo4Y0t1MUx6YWZnK0ZkOEpYcUoyMEt6MVJCZjN3bm5NR3lXZXRkYUN1MmZGb242QVEyaFBaSTNETWdRU01Zbzc0CnErOTdCYm9maklGdkxFclhCRm56dlRLRkQrSzRWcVM3MDQ5N0lDZ3RndUkwbjJ5Zk5LaG1zZmloUGtZQ0k5bG4KdXF1VURYdXpBYWFaZklSbW5WVm5EcldMZktDd1ZPaUFVUmg2Q1Y1YUhrTVcyRS8zUWc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBcTB2cFZkdVF0UmUwdVZjVHRwY1lERVNOUjNSeENaQWdBZDhMOFYrMnNFZXpUSis4CmV3V3Y0SzhkZjRqVWNNdERBR2t5QU1lZEl3eEdzYkNWdVFNR2NleGM1cllDYlJvNXpDRjFIRTNPTjJmb3pWbUkKZUsvQ3JQZElSclB0VVpLU0NVSWk0OEgvV283WW10b2t4VGhWYVFvOE9DWUhRbWU4T242UVFuejE3aUxIUlduNQo1QTRCOVhaVUJFM1RpcURQaVZtaUl6YktnUGFIUkNXQkVscFEvV1Fza1dQd1lCZDF0d3BYS0cwbENscHFCN00yCmhwSjVGYzhZUEovakR4T0NMcVl5d2ZBYWFQejJWM3F1VHFqaWlzOGkreGxCa2xsV1BEZXRYcFhwd2NCU1ZyMEsKcUlET0FMV2EwZHBYNGh6QWcxUHZjRzd4b1pmSlZ5NHNzcHRSSlFJREFRQUJBb0lCQUY2OWVvMXhCY1VUR25LVAoxYVJjUndHcC9KV3pzajAreUdVZ2p3TnVFNlhGMGtZajV1UUh6akd2eU5uYnZOdXhvQm9mRkhmWDczSU4vUitUCjhndEV3QkRNVU1tTml5UDZxRkxkZ2w4b0xWRDVtSW5TNWljUjF0TkJaV2t0WkttRUxsOE9oQ3VDQlpCNWh4V0cKWjJYbzlWeEdPKzQySWplNUZpTW9Fdk9qRjRZZ01BSmlhTkUwR0xKQldQTDFSYUxqWWdlcVVKdTRuWmVUZUR4LwpEaVdBK0tyTmRBRUpRcXkyTmxmR0JMV25kVHo0N3lLRERzcmhMVU9OOUdFdVQzN0g0SitmR3pJT1JTeDdwSEJ2CjJqZ1lQNnlHbWFOV0Q1bjVKeWhDN0VTdW5NaXFwNEI2WTBUYTNKeVoxcVI4c0p1QUJxUkVqQ3FpTHpXMCs4T3IKS2lnWWhOVUNnWUVBeERKVUJZYlV5ODlqVWYrN2ltalBJMzlJemZ3NFY5VldpaEJtUEpWa3BiNW13cDE5U1d0RApadUZ4c0JPMklRMUcrVlltQmNPZzVIVTBnc0NNdllHelRES3pZQnNVUVRKRVBGNTdBa0tZNGNqcit5OTlXL2F0CmRsdHJYMGhCcGFSMWR4YkVxaWxidm5ydTdhRHN5QzBMbUdLNjQxRXNXZmFkRGltTmxva2YvSDhDZ1lFQTM0S1MKNTlTblQ5cXppSkxJa0tXOE1mQ1lhbVZaT05VK3B5VFpsZU5vMzZ4NWE5c3YyREM0YjM1eW1rekJnUjhqVFZzZgozWklwZ2pzbHRGeVQyZ21ubXJqck5lcU8zdnFISTk2WXNhWHU2TFFjKzdtUEY3N2haUGE5dlBQV0JKSGJ3SzNqCkY0WUxSMVhmdlh0OGJsejRWbXZEcXRxZG44VC9NdENpUXZ1N2NGc0NnWUFDRktLTmVIT1RRYnpFNXRoZlRHTTkKOWlDWWhwODJWejNXc3Z2U2txY0JsdlpTQkFlTEdzY1pOVFRXY0M4VFJLZkhCeUhhRjh3Q0FEZ3hWc2RuVHhQTwpzQTcwNnZTWkNHWnUyWFdtZlh4UGtLam4vZ1h2VHJ0aU1PLy9qNjJhaXhidnoxOEFpdlc5SEdLaVJIMmVWZFAwCnByOWluNzYvcVh6YTVKZnF5OE42RXdLQmdRQ3FseHBRM3ptajlTUTZCTzRYbUtkKzVrY3VUWlEva0dKMVorYTYKUkF0elRFeVFTWWJHMXNpdU1EQ0FIRDFFcytOWjAwY0s4ZGZFa2loQTlMZlVIckpSb1BuRStQVjZzblFhcUhhYQpnQzlNWk13S1JLSTJXWFhtZlh4cmp4KzE5UzFvYms5NVVOR2k3S1FNRndmdG8vL1cxZ0ZOa2ZYa1Q1TUgwYjFHCnFxTnhLUUtCZ1FDNGVDbmZadW1LbGxFeC9CbVB6U2VYSDVYZFh3d2ZVK3UyRU5BL3JYRXJ4dmtmRUVGNEN5OVkKdzB3MXJFRlJnajNpYWRKNDJXQzBGQWsyUFFEMW5pSEtXVG5UVG1ZQURWRTNyYkhMY1RCRFJFaURyalhtazY2bAozSEVUQzBiTWF3cW5PeS92QkM0N1ZMUkQ2WjUzRE50ZDljQTVrS1hTcGdCUTNpdUZNcG9GZmc9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
clusters.cluster.certificate-authority-data——集群的证书
clusters.cluster.server——集群的地址
users.user.client-certificate-data——用户的证书
users.user.client-key-data——用户的私钥
context——上下文信息，关联用户与集群
（参考多集群切换章节）实验：
一、master上将/etc/kubernetes/admin.conf拷贝至vms41scp /etc/kubernetes/admin.conf 192.168.26.41:~- 1
二、vms41上使用kubeconfig的认证方式，使用admin.conf作为kubeconfig文件连接k8s，并执行命令get pods
# --kubeconfig指定kubeconfig文件 kubectl --kubeconfig=./admin.conf get pods #输出： NAME READY STATUS RESTARTS AGE default-testpod 1/1 Running 4 (133m ago) 2d5h pod1 1/1 Running 7 (133m ago) 13d pod2 1/1 Running 6 (133m ago) 9d- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
三、若每次连接k8s都要指定–kubeconfig略显麻烦，我们可以通过以下两种方式设置：
方式一：配置环境变量，默认使用某文件作为kubeconfig文件
配置vms41上的环境变量KUBECONFIG=./admin.confexport KUBECONFIG=./admin.conf- 1
配置完后直接可以kubectl [命令]
方式二：创建配置文件目录“.kube/config”，则默认会读取目录下的文件作为kubeconfig文件#取消环境变量的设置 unset KUBECONFIG #创建.kube目录 mkdir .kube #将admin.conf拷贝至.kube/config下 cp admin.conf .kube/config- 1
- 2
- 3
- 4
- 5
- 6
此时，就可以操作kubectl命令了
若这时进行重新初始化操作kubeadm reset，则.kube/config/admin.conf文件会发生变化
若设置了变量又存在“.kube/config”目录，则会优先选择变量的设置但在实际工作中，我们不会直接将master上的/etc/kubernetes/admin.conf拷贝给其他客户端使用，因为这是管理员的kubeconfig认证文件，权限很大，不够安全
因此，我们需要针对客户端创建一个kubeconfig文件实验：（考试不考）
客户端需要一个ca证书和一个私钥
在k8s集群环境中已经存在ca证书，即/etc/kubernetes/pki下的ca.crt
一、master上查看/etc/kubernetes/pki下的相关证书ls /etc/kubernetes/pki #输出： apiserver.crt apiserver.key bb.csv etcd front-proxy-client.crt sa.pub apiserver-etcd-client.crt apiserver-kubelet-client.crt ca.crt front-proxy-ca.crt front-proxy-client.key apiserver-etcd-client.key apiserver-kubelet-client.key ca.key front-proxy-ca.key sa.key- 1
- 2
- 3
- 4
- 5
- 6
ca.crt——ca证书
ca.key——ca私钥/var/lib/kubelet/pki下为kubelet的相关证书
ls /var/lib/kubelet/pki #输出： kubelet-client-2022-07-06-17-47-50.pem kubelet-client-current.pem kubelet.crt kubelet.key- 1
- 2
- 3
- 4
二、将ca证书拷贝出来到家目录备用
cp /etc/kubernetes/pki/ca.crt .- 1
三、master上生成一个私钥
openssl genrsa -out [文件名].key 2048 #这里生成一个文件名为john的私钥 openssl genrsa -out john.key 2048- 1
- 2
- 3
四、master上使用私钥向CA证书中心申请证书，首先生成一个csr文件xxx.csr
openssl req -new -key john.key -out [文件名].csr -subj "/CN=john/O=cka2020" #这里生成一个文件名为john的csr文件 openssl req -new -key john.key -out john.csr -subj "/CN=john/O=cka2020"- 1
- 2
- 3
五、对csr文件编码
cat john.csr | base64 | tr -d "\n" #输出： LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1pqQ0NBVTRDQVFBd0lURU5NQXNHQTFVRUF3d0VhbTlvYmpFUU1BNEdBMVVFQ2d3SFkydGhNakF5TURDQwpBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUxPV2VMZ2V5L2pkZ25pZWd2dGxQcGpUCmtvbXB6b2ZSN0xFRkw1cGRBQmRHd0N3QkVIWVVCNjVabnM4TGMxWUNnSW1PdjlFUm9DUmU2RHIzQzRRKzVQSXIKVnpaYXZuYW1CdzF5MnRxdm5tTmhxVkRJWUZ4Qzd6VkU3UlVFdTcxaFpwNnFkNWJNbzk3NUFCNXNiSHhJamwwdgp6cFA3eUIybEQvWm1LdmxWdjlLMU90UzhGTDlNTnpoRFVTc2dWWVdrV01LUnpqZ1UwT2RwSFVpYkpUOTRvVW1GCmRKZEh5ZXNyQkdwYTVvN09yZUh6OEliLzJaRGhsMU1xL21GblZobU9SWXpSMlhXQXo0ejU1a3VEakRwbHJSWXUKUGJpZ2FzTmFpVmRKNEpMT0F2MTBaS21FL0tlM1daZHozM2s3V3VZbTRxWWRubm42cWQ3M2FoTXp4STdPWUZrQwpBd0VBQWFBQU1BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQUR1cVNYa0pEenVkOUcxVnZLVGZUeVRLYmFGNXRqCkh1dktIQTNwL29nTzdodSs3MU0vNDkrQ0RVQ2NlRlVudVlWUmUrM00yQWdYT1UrVERkZUgwQzY5dzV6TXc2RjUKYmpLbWZncW5PamtTSWVic1o0elBQSWg4WGUydUtGd0NFMnFPN1dRRy9aZGZ4RnJoN1NZVmRHcytRdnRObkZFRAp2VkVWc1hyVG1UR3l4MGMyN0NlNjFMTEI5c0l3a24zUUJ2Y2gwajloRXBWL3hIRnR2VUhHSnM0L3VYQ1RMV0R4CjV5azBQTW9EWjlJQXpRdWlBaStlOENFeTVSMjhZNTIwR0xMUCt3aExrTFA2VzNDOVVyQjh2OVhDeVgxdXRnanYKbjlwWTJlb1BRQ0k5b3dBVTR5czV3TkdLVTVKVE5xdnVCQ3BvTGNRWTM1STRFc0xkNzk3V1FKUzUKLS0tLS1FTkQgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg==- 1
- 2
- 3
- 4
六、编写申请证书请求文件的yaml文件
vim csr.yaml #插入： apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: john spec: groups: - system:authenticated signerName: kubernetes.io/kube-apiserver-client request: [...csr文件内容，第五步输出的内容...] usages: - client auth- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
七、创建证书申请文件
kubectl apply -f csr.yaml- 1
查看
kubectl get csr #输出： NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION john 46s kubernetes.io/kube-apiserver-client kubernetes-admin <none> Pending- 1
- 2
- 3
- 4
- 5
八、颁发证书
kubectl certificate approve john- 1
九、颁发后，再次查看csr，可以看到CONDITION变成了Approved,Issued
以yaml文件的形式查看，可以看到spec.status.certificate下有了CA颁发的证书kubectl get csr #输出： NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION john 2m3s kubernetes.io/kube-apiserver-client kubernetes-admin <none> Approved,Issued kubectl get csr john -o yaml #输出： ... status: certificate: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCekNDQWUrZ0F3SUJBZ0lSQU5seCtMR2dpQk5GeWZOQURJMm9JU0F3RFFZSktvWklodmNOQVFFTEJRQXcKRlRFVE1CRUdBMVVFQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TWpBNE1EWXdOekkzTkRoYUZ3MHlNekE0TURZdwpOekkzTkRoYU1DRXhFREFPQmdOVkJBb1RCMk5yWVRJd01qQXhEVEFMQmdOVkJBTVRCR3B2YUc0d2dnRWlNQTBHCkNTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDemxuaTRIc3Y0M1lKNG5vTDdaVDZZMDVLSnFjNkgKMGV5eEJTK2FYUUFYUnNBc0FSQjJGQWV1V1o3UEMzTldBb0NKanIvUkVhQWtYdWc2OXd1RVB1VHlLMWMyV3I1MgpwZ2NOY3RyYXI1NWpZYWxReUdCY1F1ODFSTzBWQkx1OVlXYWVxbmVXektQZStRQWViR3g4U0k1ZEw4NlQrOGdkCnBRLzJaaXI1VmIvU3RUclV2QlMvVERjNFExRXJJRldGcEZqQ2tjNDRGTkRuYVIxSW15VS9lS0ZKaFhTWFI4bnIKS3dScVd1YU96cTNoOC9DRy85bVE0WmRUS3Y1aFoxWVpqa1dNMGRsMWdNK00rZVpMZzR3NlphMFdMajI0b0dyRApXb2xYU2VDU3pnTDlkR1NwaFB5bnQxbVhjOTk1TzFybUp1S21IWjU1K3FuZTkyb1RNOFNPem1CWkFnTUJBQUdqClJqQkVNQk1HQTFVZEpRUU1NQW9HQ0NzR0FRVUZCd01DTUF3R0ExVWRFd0VCL3dRQ01BQXdId1lEVlIwakJCZ3cKRm9BVXRHS0t3Yy9aNE1UWHd1a1Y1QWFwZnBmakVpb3dEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBSVE0QnkzYwpFNWNtRjNVaEFIM3lVdmZEd2Ryb1lxcmFIdHlsNEtRTVhQazhqbXNZWkhaWU9RdG4wVkFhaUF2R1d5Q1Y5YVVRCmd3aUM2Q1Rra285Y0tlOUttUzlyRDMwenhJS2U4MUNnWGVTcXVYcWh4WmduUUxTM2NJejFvT1lIZXFGUFA5WS8KM2hPZUI5a3BsN0xPZzMyU1RFbXRFQXZpbTRRVFBPc2xJaXBKR29ROUc0VUpEYTJIT1VwQXcwNmJkL3I3NzVHOAorc2d1RzdiYjJJWHZuMkI5V1BiWDhVRjZ3RmtqbGNBaFdidU9NTGZQcVllSjQwSzdvMEZiS2FnK05pelVBREZWCk13VHBUeE9PK1ZNeU5aOERUQzA4UjhoZWNEcmE3SThMQy9kV0x4MkFvYzR4aUlJellPSTk1WEtCaXU5dXJwb1QKalRkWFFsdUhRUElZZk5NPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== conditions: - lastTransitionTime: "2022-08-06T07:32:48Z" ...- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
十、把证书导出作为用户证书
将证书base64编码后导出为用户证书文件 “john.crt”kubectl get csr john -o jsonpath='{.status.certificate}' | base64 -d > john.crt- 1
此时就具备了ca证书ca.crt、用户证书john.crt、用户私钥john.key
十一、以命令行的方式创建一个kubeconfig文件
设置集群信息：
文件名为kc1、集群为cluster1、集群地址为https://192.168.26.21:6443、集群证书为ca.crt
embed-certs=true表示将ca.crt证书内容嵌入到yaml文件中kubectl config --kubeconfig=kc1 set-cluster cluster1 --server=https://192.168.26.21:6443 --certificate-authority=ca.crt --embed-certs=true- 1
设置用户信息：
将用户证书、用户私钥嵌入kc1的kubeconfig文件中kubectl config --kubeconfig=kc1 set-credentials john --client-certificate=john.crt --client-key=john.key --embed-certs=true- 1
设置上下文信息：
将集群信息和用户信息关联起来kubectl config --kubeconfig=kc1 set-context context1 --cluster=cluster1 --namespace=default --user=john- 1
编辑kubeconfig文件kc1，将默认上下文配置current-context改为“context1”
... current=context: "context1" ...- 1
- 2
- 3
最终，kubeconfig文件kc1如下：
apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1EY3dOakE1TkRjME4xb1hEVE15TURjd016QTVORGMwTjFvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTW1DCjNOZFdJcXpVV1B6Yk1hYS9jZTR3NW14ZjBRUUdHTkhqb1lhOHR6S0c3VDNObVBMTDRpTHlhQ05ESUUxeTBLRlEKK1RtZGFCSll4M1U0ZE5ZTHNTZEVWcUI1ajNSem5xNUo2L1BPbTBjVW5yY0VxUFFYN0w5MXNNZU90QlZOdWYyRApRc01ZV3lpK3NXUVMxYVhqTHZyaUdWYXRGd0dDSmhTbHlLTENvODdNOHdHbjZzeWlyaXhNdG1sZURLdlJMYkZRCnRhMzRWSVRlQVg3R3VsckJKQmZEMmRxZXY5K0EzZytWMU5KeXo5TXJ0Tkh5THM5ZWNUcnZpbE1JTW55MmUyMDcKZHRGc2V6MmhyenZhRkpIdzVzcDE3enozUHZXcS83ang1YU9lWEdtaU1NemxQSWhJV1JlbU11UWhmVjRsekVrRApzYUtrV05NNEpvSDlsdDZpb21NQ0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZMUmlpc0hQMmVERTE4THBGZVFHcVg2WDR4SXFNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBSTBMWXU0Q3ArL1ZZME9oaEU5WgpZT09Ob2JmTTg5SG9wVnFCVkZtd1Q1cGliS1pXYmZidGQ5bjg5T3p0WlJrSlBLOGNpOCtwRmpleDJFVGNzRWVTCkxveisyRFN3T1VrSnJ2OHl1VjJPZDI2Q3hIMDFEZ1NjcTJMSlRhNG1EVi93b0ZFYlNGTVVyaUVtRXZRdHZsengKMTlMTWJTOUdVdWtCaURhVWp2U0xqOVViS3lWZ3JnUVdWUlJaY0hHamY5c3dYRmU4NVdUQVJiR1Q2R09ZVnZyQQoxa3JSQlhZSGhKSGxKeEptVXJTSDc5c2pHeGdCQy9qR1ppZURPa2RNVWhDbTFFQ3BTcnBFakhKTml2KzY3Nnh1CkdUbmR5ejk2TFZUM1A3U0phV0tEcThvNTFNcmRNTExiZGVWSE04TkVrWTR1b3UxTkUrVEJtU2lCQlQvL2ZHRnUKdXUwPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== server: https://192.168.26.21:6443 name: cluster1 contexts: - context: cluster: cluster1 namespace: default user: john name: context1 current-context: "context1" kind: Config preferences: {} users: - name: john user: client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCekNDQWUrZ0F3SUJBZ0lSQU5seCtMR2dpQk5GeWZOQURJMm9JU0F3RFFZSktvWklodmNOQVFFTEJRQXcKRlRFVE1CRUdBMVVFQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TWpBNE1EWXdOekkzTkRoYUZ3MHlNekE0TURZdwpOekkzTkRoYU1DRXhFREFPQmdOVkJBb1RCMk5yWVRJd01qQXhEVEFMQmdOVkJBTVRCR3B2YUc0d2dnRWlNQTBHCkNTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDemxuaTRIc3Y0M1lKNG5vTDdaVDZZMDVLSnFjNkgKMGV5eEJTK2FYUUFYUnNBc0FSQjJGQWV1V1o3UEMzTldBb0NKanIvUkVhQWtYdWc2OXd1RVB1VHlLMWMyV3I1MgpwZ2NOY3RyYXI1NWpZYWxReUdCY1F1ODFSTzBWQkx1OVlXYWVxbmVXektQZStRQWViR3g4U0k1ZEw4NlQrOGdkCnBRLzJaaXI1VmIvU3RUclV2QlMvVERjNFExRXJJRldGcEZqQ2tjNDRGTkRuYVIxSW15VS9lS0ZKaFhTWFI4bnIKS3dScVd1YU96cTNoOC9DRy85bVE0WmRUS3Y1aFoxWVpqa1dNMGRsMWdNK00rZVpMZzR3NlphMFdMajI0b0dyRApXb2xYU2VDU3pnTDlkR1NwaFB5bnQxbVhjOTk1TzFybUp1S21IWjU1K3FuZTkyb1RNOFNPem1CWkFnTUJBQUdqClJqQkVNQk1HQTFVZEpRUU1NQW9HQ0NzR0FRVUZCd01DTUF3R0ExVWRFd0VCL3dRQ01BQXdId1lEVlIwakJCZ3cKRm9BVXRHS0t3Yy9aNE1UWHd1a1Y1QWFwZnBmakVpb3dEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBSVE0QnkzYwpFNWNtRjNVaEFIM3lVdmZEd2Ryb1lxcmFIdHlsNEtRTVhQazhqbXNZWkhaWU9RdG4wVkFhaUF2R1d5Q1Y5YVVRCmd3aUM2Q1Rra285Y0tlOUttUzlyRDMwenhJS2U4MUNnWGVTcXVYcWh4WmduUUxTM2NJejFvT1lIZXFGUFA5WS8KM2hPZUI5a3BsN0xPZzMyU1RFbXRFQXZpbTRRVFBPc2xJaXBKR29ROUc0VUpEYTJIT1VwQXcwNmJkL3I3NzVHOAorc2d1RzdiYjJJWHZuMkI5V1BiWDhVRjZ3RmtqbGNBaFdidU9NTGZQcVllSjQwSzdvMEZiS2FnK05pelVBREZWCk13VHBUeE9PK1ZNeU5aOERUQzA4UjhoZWNEcmE3SThMQy9kV0x4MkFvYzR4aUlJellPSTk1WEtCaXU5dXJwb1QKalRkWFFsdUhRUElZZk5NPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBczVaNHVCN0wrTjJDZUo2QysyVSttTk9TaWFuT2g5SHNzUVV2bWwwQUYwYkFMQUVRCmRoUUhybG1lend0elZnS0FpWTYvMFJHZ0pGN29PdmNMaEQ3azhpdFhObHErZHFZSERYTGEycStlWTJHcFVNaGcKWEVMdk5VVHRGUVM3dldGbW5xcDNsc3lqM3ZrQUhteHNmRWlPWFMvT2svdklIYVVQOW1ZcStWVy8wclU2MUx3VQp2MHczT0VOUkt5QlZoYVJZd3BIT09CVFE1MmtkU0pzbFAzaWhTWVYwbDBmSjZ5c0VhbHJtanM2dDRmUHdodi9aCmtPR1hVeXIrWVdkV0dZNUZqTkhaZFlEUGpQbm1TNE9NT21XdEZpNDl1S0JxdzFxSlYwbmdrczRDL1hSa3FZVDgKcDdkWmwzUGZlVHRhNWliaXBoMmVlZnFwM3ZkcUV6UEVqczVnV1FJREFRQUJBb0lCQUJjVmVGN3lWbldldzI2TgpzWGh2QXlUUnpUdzB2MzlsMUc3TW85bkxxbjlUY05BM01zNTZ0S0lNa3dVNkM1RTZzUnI5WmxxUlVXeGJacTV0Cm91VlUwRWp3bVQwN1hOQVRkMFNiUnRabFRJNnB0d0hUUDgrY0t2TkY4Tk9LMERiL2xoay9BREE2RGJaVGUxaHQKeDJRU1QzcGE4c3JDeW01RkVWQXl3Y05hNmxWRER6U0l2TExxR3lOclBZa1pKVUhnTnVkN0RaOUd2TmdCZk8zQwpBY3BZd3h3MVN5bWpBZ2RGcVNHSWU3Q0hkYUpYM0JodHBsREFwUlNBRzNHdnNVakYyRy94NXJVQlE2WVF5OEY4Clp1alo1QTJDU1N1ZDhEbjY0VkZqVXBGN3dLQ0dMRjE2dkR5SlNEOUp3cFZtZmY5bnNxV3loWDc0WncyT1llZGUKVmlacUxxRUNnWUVBMlFOb1pWS2xaSUZ2MDE3bXEyV0p0cFBMdGhXemxzUkRsUFovQWNvbDl0MEVTZWFOR01VZgphSHhZNzdoWjFac1pPbHhWdDdkZTlEaWZkVmEzZllzb0JpaHdyMFIwdkdrNUExdTUyK0xHSGpJWE5ONit4Uy9NClh3Zi9XSy9mY1RESmt0RFRhY1NPaHl2b055QzBjTkFqZ2Z3MUR5SFRrQ0FOdElVT05xc2xPUk1DZ1lFQTA5blcKY1kvd2k4ekJlTTI1V1pBRGc0ODdIdDduaTJBNEdqWnRXa1ViekkxUUU2Qi9CSGU5ek5JQUdvdDdPTDBWbDhTLwpGQXBvY2xNSWY0RjVpb0NSZkR6c2dyZjZFSHhhOTBuNml2eHVUTWd1cUNlMGpjRHNaTVZOMEc2SDZURGQ5K2VOCkRlejFuMWxBUEM5b2Eva25EWmo1OTVobUlKMXc1Y0ttOTMvNU9tTUNnWUVBb2VCdTRSWFRGYk9Qck1YZm52NXcKeVdaWjBJdERtVFR4akk2S2t0VXRtSVdwQzA4VTlPTWwySlRZNm9oRFNwa1ZLbmx4MzBiRFo3MU5CUVFZZjJkcwpCWnZvNG5SWDk2c3R3aG1ML0QrZXRTdDhNQTN2azd0aDRZbGZxZElYQktIMTJyUTIzM0NsT0tOQjVzMVlpOFpXCmxrR0JlcllxMEJsNDM2MVl1dUxUTTAwQ2dZQjQwY043QUp3dkhwYzRUaHRtK0xzSVRLZHE4N1VaeDhZM0xOTXcKcURreWIyVTd6RXlrUDZYL0tjVGxYcWJudE82Ym41bFoxSlc4blo0N0dadzNZUnVYdnljalpjazNuYlJEVSsyUApWbWVSWXBrNVRXdXJiRnRsSFNGRHZjWEZPQmxmU0s4cFFmclM1aE84UDAxT1Jzbis5eitYOVZKSlI0RWJoK2V4ClAwcmtBUUtCZ1FDdUZIQXdGSVpLb3dVNStRNG5zTy81ck5jK2xETzdhOHQ0bm0wemEvYTJPUzI5aW8rTGt6Z2IKK3RNYi9oRm8rbER4SW9zdlZzTUJFbFNSK3BleDVrRWhKbWlKaTVhbTBZems0Rk9yblVkUkFlcERPUGVid1VsQQp6eU0zQS9YOVFRc21wZStURlRtZHpibnN5SHNOUFRXOU1SeHh6eHJvL3h0YzZtakJsMStmbnc9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
注意：ca所颁发的证书的有效期都只有1年，1年之后，需要续期
十二、将kc1这个kubeconfig文件拷贝到vms41（client）的家目录中scp kc1 192.168.26.41:~- 1
十三、vms41上，将kc1拷贝至.kube/config目录下，作为默认的kubeconfig文件
cp kc1 .kube/config- 1
查看上下文信息，可以看设置已经生效
kubectl config get-contexts #输出： CURRENT NAME CLUSTER AUTHINFO NAMESPACE context1 cluster1 john default- 1
- 2
- 3
- 4
- 5
十四、最后，在master上给用户john授权
kubectl create clusterrolebinding cbind1 --clusterrole cluster-admin --user=john- 1
测试：
#vms41上测试 kubectl get pods #master上删除用户john的权限 kubectl delete clusterrolebinding cbind1- 1
- 2
- 3
- 4
- 5
oauth2 认证方式
接入第三方认证，如HTTP认证等
二、授权（鉴权）
第一章中讲到了客户端用户如何验证登录k8s，登录后，用户得拥有相应的权限才能做相应的操作
master上/etc/kubernetes/manifests/kube-apiserver.yaml文件中，spec.containers.command下用authorization-mode配置项配置鉴权的模式
鉴权的方式：- –authorization-mode=Node.RBAC（默认为这种方式）
- –authorization-mode=AlwaysAlow（允许所有请求，若为这个配置，客户端用户无论是否有被授权，总是允许）——不推荐
- –authorization-mode=AlwaysDeny（拒绝所有请求，若为这个配置，客户端用户即使被授权了，也是拒绝）——不推荐
- –authorization-mode=ABAC（这种方式不够灵活，放弃）
ABAC（Attribute-Based Access Contorl）
推荐使用RBAC（Role Based Access Control——基于角色的访问控制）的模式
-
–authorization-mode=RBAC
在这种模式下，我们来给用户授权 -
–authorization-mode=Node
Node授权器主要用于各个node上的kubelet访问apiserver时使用的，其他一般均由RBAC授权器来授权
因此，系统默认的配置为：- --authorization-mode=Node,RBAC，推荐也是这种鉴权方式
三、k8s中的权限、角色、用户
用户——用户不属于任何命名空间，就是一个独立的用户
权限——k8s中有各种权限如：create、update、patch、get、watch、list、delete等
角色——角色是基于命名空间的，我们并不会将某些权限直接授权给用户，而是会先创建某些角色，将权限授权给角色，然后把角色授权给用户，这个授权的过程叫作rolebinding（角色绑定）
注意：角色是基于命名空间的，假设角色role1在命名空间ns1下，将角色role1绑定给用户john，那么john只有在命名空间ns1下才具有角色role1的权限
同时，我们也可以创建clusterrole，clusterrole是全局的，没有命名空间的限制，但是，若通过rolebinding的方式来将clusterrole绑定给用户，那么该用户仍然只有在该rolebinding所在的命名空间下才具有相应权限
若想让用户拥有全局的权限（在所有命名空间下都有权限），则创建一个clusterrolebinding，通过clusterrolebinding来将clusterrole绑定给用户
查看角色
#查看当前命名空间下的角色 kubectl get role #查看指定命名空间下的角色 kubectl get role -n [命名空间名称]- 1
- 2
- 3
- 4
- 5
查看集群角色
kubectl get clusterrole- 1
查看角色有哪些权限
#Verbs下为属性 kubectl describe role [角色名称]- 1
- 2
查看集群角色“管理员”的权限
kubectl describe clusterrole admin- 1
创建角色
方式一：命令行的方式
# 命令行中资源类型可以简写，如pod简写为po，但是yaml文件中不能简写 kubectl create role [角色名称] --verb=[拥有的权限，如：get,create...] --resource=[针对什么资源拥有权限，如：pod,svc...]- 1
- 2
方式二：yaml文件的方式
通过命令行输出yaml文件模板kubectl create role [角色名称] --verb=[拥有的权限，如：get,create...] --resource=[针对什么资源拥有权限，如：pod,svc...] --dry-run=client -o yaml > [文件名].yaml- 1
例：
kubectl create role role1 --verb=get,list --resource=po --dry-run=client -o yaml > role1.yaml输出的yaml文件模板如下： ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: role1 rules: - apiGroups: - "" resources: - pods verbs: - get - list- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
rules.apiGroups——配置资源类型的apiVersion的父级（具体看下面的实验）
rules.resources——在限定的apiVerion父级的范围下，配置资源类型（注意：yaml文件中的资源类型必须是复数）
rules.verbs——配置拥有的权限，若配置为 - “*” ，表示拥有所有权限
rules表示权限规则，一个apiGroups表示一个规则，若多个资源都在一个apiGroups下则应用相同的权限规则，若想对不同的资源分配不同的权限规则，可以配置多个apiGroups，如下：
对于service拥有get、list的权限、对于pod拥有所有的权限apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: role1 rules: - apiGroups: - "" resources: - pods verbs: - “*” - apiGroups: - "" resources: - services verbs: - get - list- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
创建集群角色同创建角色
#命令行方式创建 kubectl create clusterrole [名称] --verb=[权限] --resource=[资源] #yaml文件 kubectl create clusterrole [名称] --verb=[权限] --resource=[资源] --dry-run=client -o yaml > [文件名].yaml- 1
- 2
- 3
- 4
也可以直接修改某个角色为集群角色
修改yaml文件将kind改为“ClusterRole”apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole ...- 1
- 2
- 3
查看rolebinding
kubectl get rolebinding kubectl get rolebinding -n [命名空间]- 1
- 2
查看clusterrolebinding
kubectl get clusterrolebinding- 1
创建rolebinding、clusterrolebinding
kubectl create rolebinding [名称] --role=[绑定的角色] --user=[绑定的用户] kubectl create rolebinding [名称] --clusterrole=[绑定的集群角色] --user=[绑定的用户] kubectl create clusterrolebinding --clusterrole=[绑定的集群角色] --user=[绑定的用户]- 1
- 2
- 3
- 4
查看用户在所有命名空间有哪些rolebinding
kubectl get rolebinding -A -o wide | grep [用户]- 1
删除角色
kubectl delete role [名称]- 1
删除rolebinding、clusterrolebinding
kubectl delete rolebinding [名称] kubectl delete clusterrolebinding [名称]- 1
- 2
实验：创建role
master上创建角色，并将角色绑定给用户john，以yaml文件的方式创建角色，先通过命令行输出yaml文件目标
（1）角色名为role1，对于pod拥有get，list的权限，输出role1.yaml文件kubectl create role role1 --verb=get,list --resource=po --dry-run=client -o yaml > role1.yaml- 1
（2）输出的yaml文件模板如下：
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: role1 rules: - apiGroups: - "" resources: - pods verbs: - get - list- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
（3）创建该角色
kubectl apply -f role1.yaml- 1
（4）查看该角色及查看有哪些权限
kubectl get role #输出： NAME CREATED AT role1 2022-08-07T08:23:22Z kbuectl describe role role1 #输出： Name: role1 Labels: <none> Annotations: <none> PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [get list]- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
（5）创建rolebinding，名为rbind1，绑定role1和john
kubectl create rolebinding rbind1 --role=role1 --user=john- 1
（6）查看rolebinding
kubectl get rolebinding #输出： NAME ROLE AGE rbind1 Role/role1 8s- 1
- 2
- 3
- 4
查看john在所有命名空间下都有哪些rolebinding、角色
kubectl get rolebinding -A -o wide | grep john #输出： default rbind1 Role/role1 3m54s john- 1
- 2
- 3
（7）给角色role1增加create、delete的权限
修改yaml文件，在rules.verbs下增加create、delete... rules: - apiGroups: - "" resources: - pods verbs: - get - list - create - delete ...- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
修改后需要重新apply一下生效
kubectl apply -f role1.yaml- 1
（8）此时用户john只有针对资源pod拥有get、list、create、delete的权限，我们想要它也有对于service的权限
修改yaml，rules.resources下增加services（yaml文件中不能使用简写svc）... rules: - apiGroups: - "" resources: - pods - services verbs: - get - list - create - delete ...- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
重新apply生效
kubectl apply -f role1.yaml- 1
（9）查看role1的权限，可以看到有了对于pod、svc的get、list、create、delete的权限
（10）使其拥有对于pod和svc的所有权限，修改yaml文件如下... rules: - apiGroups: - "" resources: - pods - services verbs: - “*” #- get #- list #- create #- delete ...- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
重新apply生效
kubectl apply -f role1.yaml- 1
（11）修改权限规则，使得对于svc只有get、list的权限，对于pod拥有所有的权限
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: role1 rules: - apiGroups: - "" resources: - pods verbs: - “*” - apiGroups: - "" resources: - services verbs: - get - list- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
重新apply生效
kubectl apply -f role1.yaml- 1
（12）此时，我们想增加对deployment的get、list权限
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: role1 rules: - apiGroups: - "" resources: - pods verbs: - “*” - apiGroups: - "" resources: - services - deployments verbs: - get - list- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: creationTimestamp: null name: role1 rules: - apiGroups: - "" resources: - pods verbs: - “*” - apiGroups: - "" resources: - services - deployments verbs: - get - list- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
重新apply生效
kubectl apply -f role1.yaml- 1
然后来到vms41上测试，发现权限不够
这是因为不同资源类型的apiVersion不一样
通过kubectl api-resources查看，可以看到pods、services的apiVersion为v1，deployments的apiVersion为apps/v1
总的来看，资源类型的apiVersion分成了两种结构
单一结构的xx，如：v1
两层结构的yy/xx，如：apps/v1
对于单层结构的，父级为空 “”，对于两层结构的，父级为yy，如apps
在权限规则中，配置项apiGroups下配置的即为资料类型的apiVersion的父级，该规则就限定了一个范围，只对apiVersion的父级为该配置的资源类型生效
如：... rules: - apiGroups: - "" ...- 1
- 2
- 3
- 4
- 5
就表示该规则只对apiVersion的父级为空（即apiVersion为单层）的资源类型生效
所以，若想让deployment也能生效规则，则要在apiGroups下增加 - “apps”
修改yaml如下：
并增加对于deployment的create权限... - apiGroups: - "" - "apps" resources: - services - deployments verbs: - get - list - create ...- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
重新apply生效
kubectl apply -f role1.yaml- 1
（13）来到vms41上测试创建deploy，设置2个副本数
出现如下报错：Error from server (Forbidden): deployments.apps "web1" is forbidden: User "john" cannot patch resource "deployments/scale" in API group "apps" in the namespace "default"- 1
意为用户john缺少对资源deployments/scale的patch权限，在apps这个apiGroups下
因此在“apps”的apiGroups下增加对于deployments/scale的patch权限
修改yaml文件如下：- apiGroups: - "" - "apps" resources: - services - deployments - deployments/scale verbs: - get - list - create - patch ...- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
重新apply生效
kubectl apply -f role1.yaml- 1
实验：创建clusterrole
（1）master上删除role1、rbind1
kubectl delete role role1 kubectl delete rolebinding rbind1- 1
- 2
（2）修改role1.yaml，将kind改为ClusterRole，名字改为“crole”
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: creationTimestamp: null name: crole rules: - apiGroups: - "" resources: - pods verbs: - "*" - apiGroups: - "" resources: - services - deployments verbs: - get - list- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
（3）创建该clusterrole
kubectl apply -f role1.yaml- 1
（4）查看是否创建成功
kubectl get clusterrole | grep crole #输出： crole 2022-08-08T05:57:18Z- 1
- 2
- 3
（5）通过rolebinding的方式将crole授权给用户john
kubectl create rolebinding rbind1 --clusterrole=crole --user=john- 1
虽然是clusterrole，集群角色是没有命名空间的限制的，但是是通过rolebinding的方式授权给用户，因此用户还是受rolebinding所在的命名空间的限制
来到vms41上，测试发现，只能在当前命名空间（rbind1所在命名空间）才有权限
（6）删除rbind1，通过clusterrolebinding的形式将crole授权给用户johnkubectl delete rolebinding rbind1 kubectl create clusterrolebinding cbind --clusterrole=crole --user=john- 1
- 2
此时，用户john才所有命名空间下都具备了集群角色crole的权限
来到vms41下，可以测试查看所有命名空间下的podkubectl get pods -A- 1
（7）实验结束，删除clusterrolebinding
kubectl delete clusterrolebinding cbind- 1
三、了解serviceaccount
概述
以上所提到的 “用户”，都属于“用户账户”，系统还有一种账户——serviceaccount
k8s系统中有两种账户：
1.user account（用户账户）——用于登录系统（通过token或者kubeconfig认证方式登录系统）
2.service account（sa）——用于给pod运行的在每个命名空间里，都有一个默认的sa，这个sa是无法删除的（删除后又会自动重新生成）
#查看当前命名空间下的sa kubectl get sa #输出： NAME SECRETS AGE default 0 32d- 1
- 2
- 3
- 4
- 5
当我们运行一个pod的时候，必须指定这个pod使用哪个sa的身份来运行
我们在创建pod时，若没有指定sa，则会默认使用default下的sa身份来运行
例如我们创建如下pod：apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: pod1 name: pod1 spec: terminationGracePeriodSeconds: 0 containers: - image: nginx imagePullPolicy: IfNotPresent name: pod1 resources: {} dnsPolicy: ClusterFirst restartPolicy: Always status: {}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
创建好后，我们以yaml文件的形式查看该pod
kubectl get pod pod1 -o yaml #输出： ... spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: pod1 resources: {} terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /var/run/secrets/kubernetes.io/serviceaccount name: kube-api-access-m8z25 readOnly: true dnsPolicy: ClusterFirst enableServiceLinks: true nodeName: vms22.rhce.cc preemptionPolicy: PreemptLowerPriority priority: 0 restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: default serviceAccountName: default terminationGracePeriodSeconds: 0 tolerations: - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 volumes: - name: kube-api-access-m8z25 projected: defaultMode: 420 sources: - serviceAccountToken: expirationSeconds: 3607 path: token - configMap: items: - key: ca.crt path: ca.crt name: kube-root-ca.crt - downwardAPI: items: - fieldRef: apiVersion: v1 fieldPath: metadata.namespace path: namespace status: ...- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
可以看到serviceAccount的这项属性为default
投射卷projected与sa信息
使用sa，会自动给pod生成一个卷，卷类型为projected，可以看到yaml文件中spec.volumes下名为kube-api-access-m8z25的projected类型的卷
projected卷称为 “投射卷”，主要作用是把sa信息挂载到容器中去
进入pod，可查看投射卷挂载在容器的什么位置kubectl exec -it pod1 -- df -hT #输出： Filesystem Type Size Used Avail Use% Mounted on overlay overlay 150G 6.9G 144G 5% / tmpfs tmpfs 64M 0 64M 0% /dev tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/sda1 xfs 150G 6.9G 144G 5% /etc/hosts shm tmpfs 64M 0 64M 0% /dev/shm tmpfs tmpfs 3.8G 12K 3.8G 1% /run/secrets/kubernetes.io/serviceaccount tmpfs tmpfs 2.0G 0 2.0G 0% /proc/acpi tmpfs tmpfs 2.0G 0 2.0G 0% /proc/scsi tmpfs tmpfs 2.0G 0 2.0G 0% /sys/firmware- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
可以看到，投射卷是挂载在容器的 “/run/secrets/kubernetes.io/serviceaccount” 下
/run/secrets/kubernetes.io/serviceaccount下会生成一个token#查看该token kubectl exec -it pod1 -- cat /run/secrets/kubernetes.io/serviceaccount/token #输出： eyJhbGciOiJSUzI1NiIsImtpZCI6IjNJUlNCbDgteVViUHdZeFJsTDMzRkgyZlNYMDFLVndrNXMzU2NxOWV2WUEifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNjkxNDc1ODYxLCJpYXQiOjE2NTk5Mzk4NjEsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0IiwicG9kIjp7Im5hbWUiOiJwb2QxIiwidWlkIjoiYmI4OTY5ZGItMzE5OC00ZGYyLTg0ZmQtODljODliZGQ3MTI1In0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJkZWZhdWx0IiwidWlkIjoiYThiNzU2YzItNGY2Ny00Nzg3LWE3OGEtNzNmZGE2ZmJjODRhIn0sIndhcm5hZnRlciI6MTY1OTk0MzQ2OH0sIm5iZiI6MTY1OTkzOTg2MSwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRlZmF1bHQ6ZGVmYXVsdCJ9.Tk8oiZpkTWm7qIPqnlOGQy6biue0wPuM6ZFOgr-ixppMfpgipqJh2YVylEZF7RB1DIlqm0aO2cZDy0GDD2F4yBkkOiGo2xpmI1liqDKu-ujsK_SqzZA3_OIKS9VVnTHMAciKg69AHqZVeOIu-n0iY_9pESFtGhn4hEKPyIXTh2QBEwrFdgqW4_mMSlOAJs19akkWoLTILsEBwGX20j-eSAek9zlaSI6iLDFqh5ltsxnAYHxdVRgsQJTdpAtUnXxfYrzALnfvaQeVVsOOZWCug80SN0pdZDDiFqD2XrFyGGcODT3pfedrTKWboRuVsWghcq0NNHJ8XWr3bzTIeXar5Q- 1
- 2
- 3
- 4
这个token就含有sa的信息
可以到https://jwt.io/中解码该token
可以看到sub一项指定的就是default命名空间的sa
因此，若给sa授予了什么权限，这个token中就会包含被授权的权限信息
容器里面的进程会去访问/run/secrets/kubernetes.io/serviceaccount下的token，以获取相应的权限
因此sa的权限越大，容器里面的进程的权限也越大
注：这个token有效期为1小时，过期后kubelet会自动去申请、更新
我们也可以手动创建一个sa，然后创建pod时指定该sa
在k8s-1.20之前（包含1.20）：创建sa同时会创建一个secret出来，并且pod里的token就是这个secret的token，并且这个token是永不过期的
k8s-1.21至1.23：创建sa同时也会生成一个secret，但是pod里的token不再使用secret里的token了
在k8s-1.24之后（包括1.24）：创建sa时干脆就不再生成secret，但是我们可以手动创建secret实验：创建pod时指定sa
（1）删除上面的pod1
kubectl delete pod pod1- 1
（2）创建名为sa1的service account
kubectl create sa sa1- 1
（3）查看是否创建成功
kubectl get sa #输出： NAME SECRETS AGE default 0 32d sa1 0 3s- 1
- 2
- 3
- 4
- 5
注：在k8s1.24之前（不包括1.24），创建sa同时会创建一个secret出来，1.24之后就不会了，但是我们可以手动创建secret
（4）创建pod，spec下使用serviceAccount配置项指定sa
指定sa1作为该pod的sa
创建pod1.yamlapiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: pod1 name: pod1 spec: terminationGracePeriodSeconds: 0 serviceAccount: sa1 containers: - image: nginx imagePullPolicy: IfNotPresent name: pod1 resources: {} dnsPolicy: ClusterFirst restartPolicy: Always status: {}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
创建该pod
kubectl apply -f pod1.yaml- 1
（5）检验pod1使用的sa是否是sa1
进入pod1查看/run/secrets/kubernetes.io/serviceaccount下的tokenkubectl exec -it pod1 -- cat /run/secrets/kubernetes.io/serviceaccount/token #输出： eyJhbGciOiJSUzI1NiIsImtpZCI6IjNJUlNCbDgteVViUHdZeFJsTDMzRkgyZlNYMDFLVndrNXMzU2NxOWV2WUEifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNjkxNDc4MzYyLCJpYXQiOjE2NTk5NDIzNjIsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0IiwicG9kIjp7Im5hbWUiOiJwb2QxIiwidWlkIjoiNTFkOWExZDYtNjAxNC00YTYwLTg4MjgtMGYwNWM3ZGI3MzU5In0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJzYTEiLCJ1aWQiOiJjOTY4ZThkMy0zMDkwLTQ5ZTktYTczNC02ZDA2ZTBlNjViZjIifSwid2FybmFmdGVyIjoxNjU5OTQ1OTY5fSwibmJmIjoxNjU5OTQyMzYyLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpzYTEifQ.T0hmPRD5-AnYI-BE-HXURAE1mqV3NZEPtoaIwgXq8a6r1y4DJf6b80IjMRnENbew51qABkex8GnVLCALuNym9X_ziIK3LjgTg5Vq1Sk2jM30M3ziclFugI_ZzAdf3Qg1LSWkEIzo7rNOQ-dcnPYFOTHlrsJOXUioXgHj-0qEiSoHKJCc7wIn-yhNsY1mz8DaYvS9OZPJPxw0XXmY5Ov-azCpcta7LPhUONGCg8sYKThAr8fBbSKyGx8cg1WNlzm2GD1IRrHRJtHk0ik-BlKRFYPEK12z1RbT-7n874moLKaay7F51wNz7BWE0-AI2Y7EFtWajvUF9V1GlXSp-Q1Eyg- 1
- 2
- 3
将token信息复制到https://jwt.io/中解码
可以看到sub一项的值为：“sub”: “system:serviceaccount:default:sa1”
（6）可以给sa1创建一个secret，生成yaml如下：cat > sa1-secret.yaml<<EOF apiVersion: v1 kind: Secret type: kubernetes.io/service-account-token metadata: name: sa1 annotations: kubernetes.io/service-account.name: "sa1" EOF- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
创建该secret
kubectl apply -f sa1-secret.yaml- 1
查看secret
kubectl get secrets #输出： NAME TYPE DATA AGE sa1 kubernetes.io/service-account-token 3 57s- 1
- 2
- 3
- 4
查看sa1的secret
kubectl describe secrets sa1 #输出： Name: sa1 Namespace: default Labels: <none> Annotations: kubernetes.io/service-account.name: sa1 kubernetes.io/service-account.uid: c968e8d3-3090-49e9-a734-6d06e0e65bf2 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1099 bytes namespace: 7 bytes token: eyJhbGciOiJSUzI1NiIsImtpZCI6IjNJUlNCbDgteVViUHdZeFJsTDMzRkgyZlNYMDFLVndrNXMzU2NxOWV2WUEifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhMSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJzYTEiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJjOTY4ZThkMy0zMDkwLTQ5ZTktYTczNC02ZDA2ZTBlNjViZjIiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpzYTEifQ.c1AfEofgEh6Uy6HK7L8hUlndX01rdgsUczbezOHACfqsbHa3_aefc3_ZNUJvhO2Pts6Vkycl_c3yMHqk0NiJ5Q2DQLUR-w3Q5G_USrhRimlSRzQ5uag_bchAEi0DX1HAsVSByvV_8tgfgUSFDHFNPXqvZpkhY4aNfahmYH3o9MKRHTj1P0Lcn2Q-LhS4wMs_MN55q0Wu7LGPIPrxytxC7K4uBO5ZuTh0QNP_bZSML6tGECvWwo_yQEQ1fqSvcgd-q7NzbQT7GnjhuhwZ1yID5E-G3qz6uzB-CnVydQS0qswat8EGvNPRVqFuJ9ibKaJhSZvmahT0n76FqDWxtTRnBw- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
但是pod里并没有应用这个token（指k8s-1.21之后，包括1.21）
-
相关阅读:
Linux网络编程6——poll和epoll
超实用！产品经理如何提高自己的工作效率？
2022年全球及中国刹车片行业头部企业市场占有率及排名调研报告
git 丢弃修改 回退版本
第四章-决策树
Go语言基础-基础语法
APP自动化测试-12.Appium日志分析(原理)
Allegro添加渐近线操作指导
xgp加速器免费 微软商店xgp用什么加速器
《TCP/IP网络编程》Go语言系列 -- 多播与广播
- 原文地址：https://blog.csdn.net/weixin_41755556/article/details/126118818
