深入理解K8S【安全認證機制】
1 核心概念
1.1 安全體系
對于大型系統來說，對業務的權限、網絡的安全認證是必不可少的。
對于linux系統來說，用戶和組、文件權限、SELinux、防火墻、pam、sudo等，究其核心的目的都是為了保證系統是安全的。
- 那么kubernetes的這種大型的任務編排系統來說，同樣也陸續產生了一系列對平臺的權限認證、對業務的權限認證、對網絡的安全認證等認證體系
- K8s官網：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/
K8S權限及認證（3A）：
- Authentication認證：校驗用戶身份，若不成功返401。多個認證插件進行
或邏輯。只要有一個插件校驗通過就放行，進入下一關。【是不是我們的人】- Authorization授權：什么樣的用戶有什么權限。不同用戶獲取不同的資源操作權限，比如普通用戶、超級用戶等。權限不足返回403<鑒權過程遵循“
或”邏輯，且任何一個插件對操作的許可授權后都將不再進行后續插件驗證，如果都未許可則拒絕。【是什么角色，給你什么權限】- Admission準入控制：用戶認證、授權之后，當進行一些寫操作的時候，需要遵循的一些限制的要求,比如資源限制內容合規性檢查，遵循“
與”邏輯，且無論成敗，每次操作都要經由所有插件檢驗,最后統一返回結果
只對寫操作進行合規性檢查，在授權范圍內，對用戶的某些命令或者操作進行進一步的限制【操作造成的結果是否在合規范圍內，需要所有插件檢驗通過】
分為兩類:
- validaing 校驗(合規性,資源默認和最大和最小限制)
- mutating 變更(補全,默認值填充)
K8s安全校驗流程解析：
- UA（普通人類賬戶）、SA（集群內部賬戶，內嵌賬戶）發起請求
- 認證、授權插件遵循
短路與，如：多個認證插件，有一個成功就放行，讓請求到達授權插件鏈；準入控制插件不遵循短路與，需要準入控制插件鏈上的插件都檢測通過才允許請求往下走。- 校驗通過，訪問k8s對應資源。
①上圖左側的用戶：
- kubernetes主要有兩種用戶：
- User Account:普通人類用戶(交互模式)
- Service Account:集群內部的pod用戶(服務進程)
②中間：每個部分都是以插件的方式來整合到 kubernetes 集群環境中：
認證和授權是按照插件的順序依次進行檢測，并且遵循 “短路模型” 的認證方式所謂的"短路"即，失敗的時候，到此結束,后續的規則不會進行。
準入控制 由于僅用戶寫操作場景，所以它不遵循 “短路模型”，而是會全部檢測通過才允許執行原因在于，它要記錄為什么不執行，原因是什么，方便后續審計等動作。
③右側部分：k8s資源
1.2 認證機制
1.2.1 k8s中的用戶
- UserAccount：非pod類的客戶端來訪問API Server，一般是我們現實中的"人"。常見的管理方式：openssl等。（K8s將這部分外包出去，由外部的第三方服務進行管理）【真實的人操作的賬戶、k8s外包出去、openssl】
- ServiceAccount（SA）：k8s內部自帶的、與pod關聯的賬號類型。主要用于集群pod內的進程訪問API Server。該賬號認證到API Server的信息稱為Service Account Token，它們保存于同名的Secret對象中。【k8s內嵌、pod操作的賬戶】
- 匿名用戶
1.2.2 用戶組（類比windows用戶組）
為了方便k8s對某一類用戶賬號UA進行管理，一般會通過用戶組方式進行管理。
- k8s本身并沒有用戶組的概念。用戶組是在身份提供者（如：OpenID Connect、Active Directory、kubectlconfig文件中定義的）。
- 在k8s中，用戶、用戶組主要在Authentication認證、Authorization授權環節中發揮作用。
①查看集群中的用戶和組（CN和OU）：openssl x509 -in xx-apiserver.crt -text -noout
例如：查看用戶組system：master權限
所有的k8s集群資源操作，其實都是通過node節點上的kubelet和master節點上的apiserver之間的通信實現，而在kubernetes的認證目錄中有其專用的通信認證證書 apiserver-kubelet-client.crt，可以通過該文件來檢查一下這兩者之間是一個怎樣的關系。
# 以rancher搭建的k8s為例
# 查看集群中的用戶關系
openssl x509 -in /var/lib/rancher/rke2/server/tls/client-kube-apiserver.crt -text -noout
結果：
Certificate:
...
Issuer: CN = kubernetes
Validity
Not Before: Oct 3 03:06:43 2021 GMT
Not After : Oct 3 03:06:43 2022 GMT
Subject: O=system:masters, CN=kube-apiserver-kubelet-client
...
結果顯示：對于kubelet，用戶名是kube-apiserver-kubelet-client，而且屬于system:master的組，這兩者的關系是在基于openssl或者csffl工具創建用戶時候基于CN和O來設定的信息。
②查看集群角色權限:kubectl get clusterrole cluster-admin -o yaml
# 查看k8s cluster-admin的用戶權限
kubectl get clusterrole cluster-admin -o yaml
③查看集群和用戶角色綁定關系：kubectl get clusterrolebinding cluster-admin -o yaml
# 查看cluster-admin這個綁定配置，做了什么配置
kubectl get clusterrolebinding cluster-admin -o yaml...
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRole # 被綁定人擁有cluster-admin用戶的權限name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.iokind: Group# 將system:masters里的所有人都應用該綁定關系name: system:masters
1.2.3 認證插件
API Server啟用的身份認證機制：
- 基于認證插件支持多種認證方式，而相應認證插件的啟用需要經由kube-apiserver上的專用選項完成
- kubeadm 部署的集群默認啟用的認證機制包括如下幾種：
- X509客戶端證書認證
- Bootstrap令牌認證
- 前端代理身份認證 front-proxy
- Service Account 令牌
注意：API Server并不保證各認證插件的生效次序與定義的次序相同（認證插件遵循或關系，有一個認證通過就放行，不再進行其他認證插件的校驗。直接進入下一步授權）
# 在master節點查看認證機制
cat /etc/kubernetes/manifests/kube-apiserver.yaml
①X509客戶端證書認證（TSL雙向認證）：k8s ca.crt簽發證書
TLS雙向認證，客戶端持有數字證書,API Server信任客戶端證書的頒發者.即服務器客戶端互相驗證信任的CA需要在kube-apiserver啟動時,通過–client-ca-file選項指定.證書中的Subject中的 CN(CommonName)即被識別為用戶名，而O（Organization）被識別為組名對于這種客戶的賬號，k8s是無法管理的。為了使用這個方案，api-server需要用–client-ca-file、–tls-private-key-file、–tls-cert-file選項來開啟。kubeadm部署的Kubernetes集群，默認使用 /etc/kubernetes/pki/ca.crt 進行客戶端認證,此文件是kubeadm為Kubernetes各組件間頒發數字證書的CA
- 由k8s的ca.crt簽發證書，校驗證書合法性（是否是我簽發的），校驗權限（是否是某個cn用戶，是否是某個o組）
②Token令牌認證：節點數量很多，直接通過token進行通信
在節點數量非常多的時候，大量手動配置TLS認證比較麻煩，可以通過在api-server開啟 experimental-bootstrap-token-auth 特性，通過對客戶端的和k8s平臺預先定義的token信息進行匹配，認證通過后，自動為節點頒發證書，可以大大減輕工作量，而且應用場景非常廣。
包括: Service Account 令牌,靜態令牌文件,Bootstrap令牌,OIDC(OpenID Connect)令牌,Webhook 令牌 等
- 節點數量多，手動配置tls證書麻煩。直接通過token方式通信。（token中存儲了用戶的信息）
③代理認證
一般借助于中間代理的方式來進行統用的認證方式，樣式不固定
④匿名方式
無法認證的其它請求（無認證）
2 實戰
2.1 User Account管理
2.1.1 X509客戶端認證(k8s集群維護了三套CA證書系統)
官網地址：https://kubernetes.io/zh/docs/setup/best-practices/certificates/
Kubernetes集群中的X509客戶端認證依賴于PKI證書體系,有如下三套CA證書系統
kubeadm部署Kubernetes集群時會自動生成所需要的證書，它們位于/etc/kubernetes/pki自錄下
| 文件 | Default CN | 說明 |
|---|---|---|
| ca.crt,ca.key | kubernetes-ca | Kubernetes general CA |
| etcd/ca.crt,etcd/ca.key | etcd-ca | For all etcd-related functions |
| front-proxy-ca.crt,front-proxyca.crt.key | kubernetes-frontproxy-ca | For the front-end proxy |
2.1.2 X509創建用戶證書（普通用戶、管理員）
①創建普通用戶
# 執行下面命令后展示的內容，表示默認kubernetes的CA簽發的證書，都是k8s客戶端的用戶
grep '\-\-client-ca-file' /etc/kubernetes/manifests/kubeapiserver.yaml
- --client-ca-file=/etc/kubernetes/pki/ca.crt
# 創建存放證書的目錄
mkdir pki
(umask 077; openssl genrsa -out pki/test.key 4096)# 生成證書申請,加入ops組只具有普通權限
openssl req -new -key pki/test.key -out pki/test.csr -subj
"/CN=test/O=ops"# 使用kubernetes-ca頒發證書
openssl x509 -req -days 3650 -CA /etc/kubernetes/pki/ca.crt -
CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -in pki/test.csr -out
pki/test.crt#復制證書文件到到worker節點
#執行kubectl命令并指定apiserver地址和test用戶的證書等信息
kubectl get pod --server=https://192.xx.xxx.xx:6443 --clientcertificate=pki/test.crt --client-key=pki/test.key --certificateauthority=/etc/kubernetes/pki/ca.crt# Error from server (Forbidden): pods is forbidden: User "test" cannot list resource "pods" in API group "" in the namespace "default"
解決：
方法一：提升test用戶的權限，加入管理員組或綁定其他權限
方法二：忽略證書校驗
kubectl get pod -s https://192.xx.xxx.xx:6443 --clientcertificate=pki/test.crt --client-key=pki/test.key --insecure-skip-tlsverify=true# 如果沒有kubectl命令，也可以通過curl命令驗證
curl --cert pki/test.crt --key pki/test.key --key-type PEM --
cacert /etc/kubernetes/pki/ca.crt https://192.xx.xxx.xx:6443
②創建管理員
將創建的用戶加入管理員組。創建管理員時，指定O為system:masters
# 創建管理員用戶testuser證書
(umask 077; openssl genrsa -out pki/testuser.key 4096)
#生成證書申請文件,注意：加入system:masters組或System組才具有管理權限
openssl req -new -key pki/testuser.key -out pki/testuser.csr -subj
"/CN=testuser/O=system:masters"
# 通過k8s ca簽發證書
openssl x509 -req -days 3650 -CA /etc/kubernetes/pki/ca.crt -
CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -in pki/testuser.csr -out pki/testuser.crt
# 查看目錄下的文件（應該有testuser.csr testuser.key testuser.crt文件）
ls pki# 使用證書訪問節點，觀察是否有權限獲取pod
kubectl get pods -s https://192.xx.xxx.xx:6443 --certificateauthority=/etc/kubernetes/pki/ca.crt --client-certificate=pki/testuser.crt --clientkey=pki/testuser.key2.2 ServiceAccount管理
2.2.1 ServiceAccount概念
官方文檔：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/
- 用途：API Server對來自Pod中客戶端程序進行身份驗證
- ServiceAccount也是API Server支持的標準資源類型
在Pod上使用ServiceAccount：
- 自動設定：Service Account通常由API Server自動創建并通過ServiceAccount準入控制器自動關聯到集群中創建的每個Pod上
- K8s自動為每個pod注入一個ServiceAccount及配套令牌
- 在每個namespace中，會自動生成(由ServiceAccount準入控制器負責)一個名稱為default的ServiceAccount，并默認將其自動分配給該空間下的每個Pod共享使用
# 查看pod配置 -o yaml以yaml格式輸出，-o json以json格式輸出
kubectl get po nginx-statefulset-0 -o yaml | grep -C 9 -i ServiceAccount
2.2.2 創建&使用ServiceAccount
- 查看SA
- 創建和使用SA賬號
①查看和創建新SA
查看SA：
#每個命名空間都會有一個默認的default的SA賬號名稱
kubectl get sa -A
創建SA：
- 創建一個名為mysa的ServiceAccount。
- 定義了一個名為myrole的Role，允許get, watch, 和 list操作在pods, services, 和 secrets資源上。
- 創建一個RoleBinding，將myrole綁定到mysa，這樣ServiceAccount就有了相應的權限。
- 如果我們希望ServiceAccount在整個集群范圍內都有權限，我們需要創建一個ClusterRole和ClusterRoleBinding。（將yml中的Role和RoleBinding換成ClusterRole和ClusterRoleBinding）
# 創建namespace
kubectl create ns mynamespace
mysa.yml:
apiVersion: v1
kind: ServiceAccount
metadata:name: mysanamespace: mynamespace # 指定命名空間，可忽略
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:name: myrolenamespace: mynamespace # 確保與ServiceAccount在同一命名空間
rules:
- apiGroups: [""]resources: ["pods", "services", "secrets"]verbs: ["get", "watch", "list"]---apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: bind-mysa-to-myrolenamespace: mynamespace # 同樣，確保與ServiceAccount和Role在同一命名空間
subjects:
- kind: ServiceAccountname: mysanamespace: mynamespace
roleRef:kind: Rolename: myroleapiGroup: rbac.authorization.k8s.io
#創建賬號
kubectl apply -f mysa.yml
# 查看sa賬號(我們在mynamespace創建的，這里需要指定名稱空間)
kubectl get sa -n mynamespace -o wide | grep mysa # 查看sa詳情信息
kubectl describe sa -n mynamespace
SA賬號配套的token是在secrets對象中,注意:k8s v1.24版后創建SA不會自動生成對應Secret
# 查看ServiceAccount的Secret信息
kubectl get secrets -n mynamespace
# 查看ServiceAccount詳情
kubectl get sa mysa -n mynamespace -o yaml
②應用SA
在pod資源中一個屬性專門來設置該資源屬于哪個SA管理
# 查看pod.spec.serviceAccountName作用
kubectl explain pod.spec.serviceAccountName# 創建rolebonding（給mynamespace的mysa賦予admin權限）
kubectl create clusterrolebinding mysa-clusterrolebinding --clusterrole=admin --serviceaccount=mynamespace:mysa
注意： SA可以跨名稱空間進行授權，即A名稱空間的SA帳號可以授權給B名稱空間的權限，甚至對所有名稱空間授權
2.3 kubectlconfig管理
前面介紹的使用X509或令牌方式創建用戶的命令行方式需要指定很多選項,無疑是很麻煩的。
- 因此可以將用戶的憑證信息保存在kubeconfig文件中方便使用，kubeconfig 是YAML格式的文件，用于存儲身份認證信息，以便于客戶端加載并認證接入到API Server。
- kubeconfig 保存有認證到一或多個Kubernetes集群的相關配置信息，并允許管理員按需在各配置間靈活切換
通過kubeadm在創建集群的時候，其中有一步就是：生成kubernetes控制組件的kubeconfig文件及相關的啟動配置文件,通過各種conf文件，讓不同的組件具備操作相關資源的權限
總結：
- kubectlconfig文件(yaml格式文件)清晰明了，方便下載
- kubectlconfig支持配置多個環境。（類比Java SpringBoot多環境yml配置：dev、pre、pro）
2.3.1 kubectlconfig概念
kubectl管理多個context，每個context包含了訪問k8s集群必要的兩個配置：用戶、地址。
- clusters：每個Kubernetes集群的信息，包括集群對應訪問端點（API Server）的地址
- users：認證到API Server的用戶的身份憑據列表
- contexts：將每一個user同可認證到的cluster建立關聯關系的上下文列表
- current-context：當前默認使用的context
# 查看conf文件中的用戶信息
awk '/client-certificate-data/{print $NF}' /config |
base64 -d | openssl x509 -noout -text
2.3.2 kubectlconfig創建和管理
kubectl config 命令可以創建和管理kubeconfig文件
# 查看幫助手冊
kubectl config --help
Available Commands:current-context 顯示 current_contextdelete-cluster 刪除 kubeconfig 文件中指定的集群delete-context 刪除 kubeconfig 文件中指定的 contextdelete-user Delete the specified user from the kubeconfigget-clusters 顯示 kubeconfig 文件中定義的集群get-contexts 描述一個或多個 contextsget-users Display users defined in the kubeconfigrename-context Renames a context from the kubeconfig file.set 設置 kubeconfig 文件中的一個單個值set-cluster 設置 kubeconfig 文件中的一個集群條目set-context 設置 kubeconfig 文件中的一個 context 條目set-credentials 設置 kubeconfig 文件中的一個用戶條目unset 取消設置 kubeconfig 文件中的一個單個值use-context 設置 kubeconfig 文件中的當前上下文view 顯示合并的 kubeconfig 配置或一個指定的 kubeconfig 文件
# 例如：查看當前使用的context
kubectl config current-context
# 使用testuser-context，后續執行kubectl命令
#會自動讀取testuser-context存儲的集群及用戶憑證信息
kubectl config use-context testuser-context
3 安全認證綜合案例
3.1 UserAccount創建&使用kubetlconfig
3.1.1 UserAccount創建
- 創建私鑰文件（openssl genrsa -out user1.key 2048）
- genrsa：用于生成rsa私鑰（不會生成公鑰，因為公鑰提取自私鑰）
- out filename：指定私鑰保存位置
- numbits：指定私鑰長度，默認1024
- 簽名請求（openssl req -new -key user1.key -out user1.csr -subj
“/CN=user1/O=group”）
- new 新建一個簽名請求文件
- key 指定已有私鑰文件，簽名請求，必須與-new搭配
- out 輸出證書文件名稱
- subj 指定生成證書的擁有者信息（CN及O的值：用戶名及組名）
- 剛才的私鑰和認證并沒有被Kubernetes集群納入到管理體系，需要基于kubeadm集群的CA相關證書來
進行認證- 生成證書（openssl x509 -req -CA ./ca.crt -CAkey ./ca.key -
CAcreateserial -in user1.csr -out user1.crt -days 365）
- -req 產生證書簽發申請命令
- -in 指定需要簽名的請求文件
- -CA 指定CA證書文件
- -CAkey 指定CA證書的秘鑰文件
- -CAcreateserial 生成唯一的證書序列號
- -x509 表示輸出一個X509格式的證書
- -days 指定證書過期時間為365天
- -out 輸出證書文件
- openssl x509 -in user1.crt -text -noout：查看生成的證書信息
最終生成的文件：.key 是私鑰，.csr是簽名請求文件，.crt是證書
# 1 創建私鑰文件
(umask 077; openssl genrsa -out user1.key 2048)
# 2 簽名請求
openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=group"
# 3 利用k8s ca機構簽發證書
openssl x509 -req -in user1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out user1.crt -days 365#結果顯示：*.key 是私鑰，*.csr是簽名請求文件
# 查看證書信息
openssl x509 -in user1.crt -text -noout
3.1.2 使用kubectlconfig
①創建kubectlconfig用戶
# 1 指定用戶證書、私鑰，以及生成的conf文件位置
kubectl config set-credentials user1 --embed-certs=true --client-certificate=user1.crt --client-key=user1.key --kubeconfig=/tmp/user1.conf
#參數詳解：
- set-credentials #子命令的作用就是給kubeconfig認證文件創建一個用戶條目
- –client-certificate=path/to/certfile #指定用戶的簽證證書文件
- –client-key=path/to/keyfile #指定用戶的私鑰文件
- –embed-certs=true #在kubeconfig中為用戶條目嵌入客戶端證書/密鑰，默認值是false
- –kubeconfig=/path/other_config.file #表示將屬性信息單獨輸出到一個文件，如不指定，默認存放在 ~/.kube/config文件中
②創建kubectlconfig集群
# --certificateauthority配置k8s ca證書路徑
kubectl config set-cluster mycluster --server="https://localhost:6443" --embed-certs=true --kubeconfig=/tmp/user1.conf --certificate-authority=ca.crt
#參數詳解：
- –server=cluster_api_server
- –certificate-authority=path/to/certificate/authority
- –embed-certs=true #默認為false,會將證書文件路徑存入kubeconfig文件中,true時會將證書內容存入kubdconfig文件中
- true：則會將證書內容base64編碼后存放到我們kubeconfig指定的.conf文件中。
- false：.conf文件會直接將client-key等字段設置為具體路徑
#注意：這里使用到的證書必須是kubernetes的ca證書。
③創建context（關聯集群）
kubectl config set-context user1@mycluster --cluster=mycluster --user=user1 --kubeconfig=/tmp/user1.conf
#屬性詳解
- –cluster=cluster_nickname 關聯的集群名稱
- –user=user_nickname 關聯的用戶名稱
- –namespace=namespace 可以設置該生效的命名空間
查看配置文件最后效果：
kubectl config view --kubeconfig=/tmp/user1.conf# 解析client-certificate-data、client-key-data（base64方式解析證書信息）
# kubectl config view --kubeconfig=/tmp/user1.conf --raw
總結
以rancher搭建的k8s為例
- 創建user1用戶，不設置任何權限，預期用戶創建成功，并能正常使用
openssl genrsa -out user1.key 2048# 生成證書簽名請求
openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=group"# 使用集群的CA證書和私鑰對證書簽名請求進行簽名
openssl x509 -req -in user1.csr -CA /var/lib/rancher/rke2/server/tls/client-ca.crt -CAkey /var/lib/rancher/rke2/server/tls/client-ca.key -CAcreateserial -out user1.crt -days 365# 創建一個kubectl配置文件（--embed-certs=true將認證內嵌其中）
kubectl config set-credentials user1 --embed-certs=true --client-certificate=user1.crt --client-key=user1.key# 查看配置信息(并且顯示認證信息（經過base64編碼）)
kubectl config view --raw# 設置上下文
kubectl config set-context user1-context --cluster=default --namespace=default --user=user1# 切換到user1用戶
kubectl config use-context user1-context# 設置context證書文件
# kubectl config --kubeconfig=/root/user1/user1.yml set-credentials user1-context --client-certificate=/root/user1/user1.crt --client-key=/root/user1/user1.key
給user1分配所有權限：
user1-clusterrole.yml：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: user1-clusterrole
rules:- apiGroups: [ "*" ]resources: [ "*" ]verbs: [ "*" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: user1-clusterrole-binding
subjects:- kind: Username: user1 # 將user1應用ClusterRoleBindingapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: user1-clusterrole # ClusterRoleBinding綁定user1-clusterrole這個ClusterRoleapiGroup: rbac.authorization.k8s.io
3.2 SA賬號創建&使用kubectlconfig
- 創建sa賬號
security-sa-admin.yaml：
apiVersion: v1
kind: ServiceAccount
metadata:name: adminnamespace: default
---
#v1.24版之后添加下面內容手動創建secret
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:name: admin-secretannotations:kubernetes.io/service-account.name: "admin"
# 應用配置文件
kubectl apply -f security-sa-admin.yaml
2. 查看和配置kubectlconfig
# 查看SA賬號的Token
kubectl get secret admin-secret -n default -o jsonpath='{.data.token}' |base64 -d# 將獲取到的token設置到KUBEADMIN_TOKEN字段
KUBEADMIN_TOKEN=$(kubectl get secret admin-secret -n default -o jsonpath='{.data.token}' |base64 -d)# 設置用戶信息
kubectl config set-credentials kubeadmin --token=$KUBEADMIN_TOKEN --kubeconfig=/root/kubeadmin.conf
# 設置集群信息--certificate-authority
kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server="https://localhost:6443" --embed-certs=true --kubeconfig=/root/kubeadmin.conf# 設置上下文信息context（集群及用戶信息）
kubectl config set-context kubeadmin@kubernetes --cluster=kubernetes --user=kubeadmin --kubeconfig=/root/kubeadmin.conf# 指定默認context
kubectl config use-context kubeadmin@kubernetes --kubeconfig=/root/kubeadmin.conf# 給admin角色設置admin權限
kubectl create clusterrolebinding admin-binding --serviceaccount default:admin --clusterrole cluster-admin
)
