【Kubernetes】k8s–安全機制

機制說明

Kubernetes 作為一個分散式叢集的管理工具，保證叢集的安全性是其一個重要的任務。API Server 是叢集內部各個元件通訊的中介，也是外部控制的入口。所以 Kubernetes 的安全機制基本就是圍繞保護 API Server 來設計的。比如 kubectl 如果想向 API Server 請求資源，需要過三關，第一關是認證（Authentication），第二關是鑑權（Authorization），第三關是准入控制（Admission Control），只有透過這三關才可能會被 K8S 建立資源。

認證：識別使用者身份

鑑權：對使用者進行許可權，操作許可權等

准入控制：判斷認證和鑑權這兩個條件是否符合；符合透過，不符合則拒絕

一、認證（Authentication）

是對客戶端的認證，通俗點就是使用者名稱密碼驗證

這是安全機制的第一道防線。它負責確認請求者的身份。

三種認證方式

●HTTP Token 認證：透過一個 Token 來識別合法使用者

HTTP Token 的認證是用一個很長的特殊編碼方式的並且難以被模仿的 Token 字串來表達客戶的一種方式。Token 是一個很長的很複雜的字串，每一個 Token 對應一個使用者名稱，儲存在 API Server 能訪問的檔案中。當客戶端發起 API 呼叫請求時，需要在 HTTP Header 裡放入 Token。

●HTTP Base 認證：透過使用者名稱+密碼的方式認證

使用者名稱:密碼用 BASE64 演算法進行編碼後的字串放在 HTTP Request 中的 Heather Authorization 域裡傳送給服務端，服務端收到後進行解碼，獲取使用者名稱及密碼。

●HTTPS 證書認證（最嚴格）：基於 CA 根證書簽名的客戶端身份認證方式。

#注：Token 認證和 Base 認證方式只能進行服務端對客戶端的單向認證，而客戶端不知道服務端是否合法；而 HTTPS 證書認證方式則可以實現雙向認證。

token

使用者傳送使用者名稱和密碼登入；

服務端收到後返回一個Token給客戶端；

客戶端帶著token去訪問服務端;

服務端返回需要的資訊

BASIC 認證

401：未授權

WWW-Authenticate：頭部裡面放的使用者名稱和密碼

HTTPS證書認證

雙向認證

（1）需要被認證的訪問型別

●Kubernetes 元件對 API Server 的訪問：kubectl、kubelet、kube-proxy●Kubernetes 管理的 Pod 對 API Server 的訪問：Pod（coredns,dashborad 也是以 Pod 形式執行）

（2）安全性說明：

●Controller Manager、Scheduler 與 API Server 在同一臺機器，所以直接使用 API Server 的非安全埠訪問（比如 8080 埠）●kubectl、kubelet、kube-proxy 訪問 API Server 就都需要證書進行 HTTPS 雙向認證，埠號使用 6443

（3）證書頒發：

●手動簽發：使用二進位制部署時，需要先手動跟 CA 進行簽發 HTTPS 證書●自動簽發：kubelet 首次訪問 API Server 時，使用 token 做認證，通過後，Controller Manager 會為 kubelet 生成一個證書，以後的訪問都是用證書做認證了

（4）kubeconfig

kubeconfig 檔案包含叢集引數（CA 證書、API Server 地址），客戶端引數（上面生成的證書和私鑰），叢集 context 上下文引數（叢集名稱、使用者名稱）。Kubenetes 元件（如 kubelet、kube-proxy）透過啟動時指定不同的 kubeconfig 檔案可以切換到不同的叢集，連線到 apiserver。

也就是說 kubeconfig 檔案既是一個叢集的描述，也是叢集認證資訊的填充。包含了叢集的訪問方式和認證資訊。kubectl 檔案預設位於 ~/.kube/config

（5）Service Account

只讀不可寫

Service Account是為了方便 Pod 中的容器訪問API Server。因為 Pod 的建立、銷燬是動態的，所以要為每一個 Pod 手動生成證書就不可行了。 Kubenetes 使用了 Service Account 來迴圈認證，從而解決了 Pod 訪問API Server的認證問題。

（6）Secret 與 SA 的關係

Kubernetes 設計了一種資源物件叫做 Secret，分為兩類：

●用於儲存 ServiceAccount 的 service-account-token●用於儲存使用者自定義保密資訊的 Opaque

kubeconfig在k8s中的路徑？

k8s遇到的問題？k8s證書過期，還有etcd癱瘓，導致資料丟失

Secret 用在什麼地方？

Service Account (服務賬戶)中包含三個部分

每個pod都存在這三個檔案，用於與API server通訊

●Token：是使用 API Server 私鑰簽名的 Token 字串序列號，用於訪問 API Server 時，Server 端認證●ca.crt：ca 根證書，用於 Client 端驗證 API Server 傳送來的證書●namespace：標識這個 service-account-token 的作用域名空間

預設情況下，每個 namespace 都會有一個 Service Account，如果 Pod 在建立時沒有指定 Service Account，就會使用 Pod 所屬的 namespace 的 Service Account。每個 Pod 在建立後都會自動設定 spec.serviceAccount 為 default（除非指定了其他 Service Account）

檢視服務賬戶

`kubectl get sa`AI寫程式碼

每個 Pod 啟動後都會掛載該 ServiceAccount 的 Token、ca.crt、namespace 到 /var/run/secrets/kubernetes.io/serviceaccount/

kubectl get pod -n kube-system#進入一個podkubectl exec -it -n kube-system kube-proxy-52mtq#檢視掛載的令牌、證書和名稱空間ls /var/run/secrets/kubernetes.io/serviceaccount/exit

鑑權（Authorization）

之前的認證（Authentication）過程，只是確定通訊的雙方都確認了對方是可信的，可以相互通訊。而鑑權是確定請求方有哪些資源的許可權。API Server 目前支援以下幾種授權策略：（透過 API Server 的啟動引數 “–authorization-mode” 設定）

●AlwaysDeny：表示拒絕所有的請求，一般用於測試

●AlwaysAllow：允許接受所有請求，如果叢集不需要授權流程，則可以採用該策略，一般用於測試

●ABAC（Attribute-Based Access Control）：基於屬性的訪問控制，表示使用使用者配置的授權規則對使用者請求進行匹配和控制。也就是說定義一個訪問型別的屬性，使用者可以使用這個屬性訪問對應的資源。此方式設定較為繁瑣，每次設定需要定義一長串的屬性才可以。設定許可權是一對一的，當用戶多時會很麻煩；生效需要重啟APIserver，所以不用

●Webhook：透過呼叫外部 REST 服務對使用者進行授權，即可在叢集外部對K8S進行鑑權

●RBAC（Role-Based Access Control）：基於角色的訪問控制；k8s自1.6版本後，預設使用的規則

RBAC相比其他訪問控制方式的優勢

●對叢集中的資源（Pod，Deployment，Service）和非資源（元資訊或者資源狀態）均擁有完整的覆蓋●整個RBAC 完全由幾個API資源物件完成，同其他API 資源物件一樣，可以使用kubectl或API進行操作●可以在執行時進行調整，無需重啟API server；而ABAC 需要重啟API Server

RBAC的 API 資源物件說明（4種）

RBAC 引入了 4 個新的頂級資源物件：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4 種物件型別均可以透過 kubectl 與 API Server 操作

官方文件：https://kubernetes.io/docs/reference/access-authn-authz/rbac/

角色

Role：授權指定名稱空間的資源控制權限ClusterRole：可以授權所有名稱空間的資源控制權限

#如果使用 RoleBinding 繫結 ClusterRole，仍會受到名稱空間的影響；#如果使用 ClusterRoleBinding 繫結 ClusterRole，將會作用於整個 K8S 叢集

角色繫結

RoleBingding：將角色繫結到主體上（即subject）ClusterRoleBingding：將叢集角色繫結到主體上

主體

User：使用者Group：使用者組ServiceAccount：服務賬號

#User 使用字串表示，它的字首 system: 是系統保留的，叢集管理員應該確保普通使用者不會使用這個字首格式；Group 書寫格式與 User 相同，同樣 system: 字首也為系統保留。#Pod使用 ServiceAccount 認證時，service-account-token 中的 JWT 會儲存使用者資訊。有了使用者資訊，再建立一對角色/角色繫結（叢集角色/叢集角色繫結）資源物件，就可以完成許可權綁定了。

Role and ClusterRole

在 RBAC API 中，Role 表示一組規則許可權，許可權只能增加（累加許可權），不存在一個資源一開始就有很多許可權而透過 RBAC 對其進行減少的操作。也就是說只有白名單許可權，而沒有黑名單許可權的概念。

Role 只能定義在一個 namespace 中，如果想要跨 namespace 則可以建立 ClusterRole，也就是說定義 ClusterRole 不需要繫結 namespace。

Roler：受名稱空間影響，只能在某一個名稱空間有效Cluster：在所有名稱空間有效RoleBinding：受名稱空間的影響，只能在某一個名稱空間中和Role或者ClusterRole繫結CLusterROleBinding：只能引用ClusterRole來繫結賬戶的所有名稱空間，具有相關資源的操作許可權

Role 示例

#指定 core API 組和版本apiVersion: rbac.authorization.k8s.io/v1#指定型別為 Rolekind: Rolemetadata:#使用預設名稱空間   namespace: default#Role 的名稱  name: pod-reader#定義規則rules:#""表示 apiGroups 和 apiVersion 使用相同的 core API 組，即 rbac.authorization.k8s.io- apiGroups: [""]#資源物件為 Pod 型別  resources: ["pods"]#被授予的操作許可權  verbs: ["get", "watch", "list"]

#上面是一個Kubernetes的Role資源定義，用於指定core API group和版本，以及定義許可權規則

#以上配置的意義是，如果把 pod-reader 這個 Role 賦予給一個使用者，那麼這個使用者將在 default 名稱空間中具有對 Pod 資源物件進行 get（獲取）、watch（監聽）、list（列出）這三個操作許可權。

core API group包含了以下資源：

●Pods：代表叢集中的最小部署單元，可以包含一個或多個容器。

●ReplicationControllers：用於確保Pod的副本數符合預期。

●Services：定義瞭如何訪問Pods。

●PersistentVolumes：持久化儲存卷，可以被Pods使用。

●PersistentVolumeClaims：宣告對PersistentVolumes的需求。

●ConfigMaps：用於儲存配置資料，如鍵值對。

●Secrets：用於儲存敏感資訊，如密碼和令牌。

●Namespaces：用於組織叢集中的資源，例如，不同團隊可以有不同的名稱空間。

●Node：表示叢集中的節點。

●Nodes：表示叢集中的節點列表

ClusterRole示例

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:# "namespace" 被忽略，因為 ClusterRoles 不受名稱空間限制  name: secret-readerrules:- apiGroups: [""]#資源物件為 Secret 型別  resources: ["secrets"]  verbs: ["get", "watch", "list"]

提供的 ClusterRole 示例定義了一個名為 secret-reader 的叢集角色，這個角色授予了對 Kubernetes Secret 資源的讀取（get）、觀察（watch）和列出（list）許可權。由於這是一個 ClusterRole，這些許可權將適用於整個 Kubernetes 叢集中的所有名稱空間，而不僅僅是單個名稱空間。

這裡是對 ClusterRole 示例的詳細解釋：

●apiVersion：指定了 Kubernetes API 的版本，這裡使用的是 rbac.authorization.k8s.io/v1，這是 RBAC API 的穩定版本。●kind：指定了資源型別，這裡是 ClusterRole。●metadata：包含了資源的元資料，如名稱（name）。對於 ClusterRole，namespace 欄位被忽略，因為它不適用於叢集級別的資源。●rules：定義了角色的許可權規則。每個規則包含以下部分：●apiGroups：指定了 API 組，"" 表示核心 API 組。●resources：指定了資源型別，這裡為 "secrets"，即 Secret 資源。●verbs：指定了允許的操作，這裡是 "get"、"watch" 和 "list"

RoleBinding and ClusterRoleBinding

RoloBinding 可以將角色中定義的許可權授予使用者或使用者組，RoleBinding 包含一組主體(subject)，subject 中包含有不同形式的待授予許可權資源型別（User、Group、ServiceAccount）；RoloBinding 同樣包含對被繫結的 Role 引用；RoleBinding 適用於某個名稱空間內授權，而 ClusterRoleBinding 適用於叢集範圍內的授權

RoleBinding 示例1:

apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: read-pods  namespace: defaultsubjects:- kind: User  name: zhangsan  apiGroup: rbac.authorization.k8s.ioroleRef:  kind: Role  name: pod-reader  apiGroup: rbac.authorization.k8s.io

#將 default 名稱空間的 pod-reader Role 授予 zhangsan 使用者，此後 zhangsan 使用者在 default 名稱空間中將具有 pod-reader 的許可權

RoleBinding 同樣可以引用 ClusterRole 來對當前 namespace 內 User、Group 或 ServiceAccount 進行授權，這種操作允許叢集管理員在整個叢集內定義一些通用的 ClusterRole，然後在不同的 namespace 中使用 RoleBinding 來引用

RoleBingding 示例2：

apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: read-secrets  namespace: kube-publicsubjects:- kind: User  name: lisi  apiGroup: rbac.authorization.k8s.ioroleRef:  kind: ClusterRole  name: secret-reader  apiGroup: rbac.authorization.k8s.io

#以上 RoleBinding 引用了一個 ClusterRole，這個 ClusterRole 具有整個叢集內對 secrets 的訪問許可權；但是其授權使用者 lisi 只能訪問 kube-public 空間中的 secrets（因為 RoleBinding 定義在 kube-public 名稱空間）

使用 ClusterRoleBinding 可以對整個叢集中的所有名稱空間資源許可權進行授權

ClusterRoleBinding 示例：

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  name: read-secrets-globalsubjects:- kind: Group  name: manager  apiGroup: rbac.authorization.k8s.ioroleRef:  kind: ClusterRole  name: secret-reader  apiGroup: rbac.authorization.k8s.io

#以上 ClusterRoleBinding 授權 manager 組內所有使用者在全部名稱空間中對 secrets 進行訪問

Resources

Kubernetes 叢集內一些資源一般以其名稱字串來表示，這些字串一般會在API 的 URL 地址中出現；同時某些資源也會包含子資源，例如 log 資源就屬於 pods 的子資源，API 中對 Pod 日誌的請求 URL 樣例如下：

`GET /api/v1/namespaces/{namespace}/pods/{name}/log`

#在這裡，pods 對應名字空間作用域的 Pod 資源，而 log 是 pods 的子資源。如果要在 RBAC 授權模型中控制這些子資源的訪問許可權，可以透過 / 分隔符來分隔資源和子資源實現。#以下是一個定義允許某主體讀取 pods 同時訪問這些 Pod 的 log 子資源的 Role 定義樣例：

apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  namespace: default  name: pod-and-pod-logs-readerrules:- apiGroups: [""]  resources: ["pods", "pods/log"]  verbs: ["get", "list"]

#rules.verbs有："get", "list", "watch", "create", "update", "patch", "delete", "exec"

#rules.resources有："services", "endpoints", "pods", "secrets", "configmaps", "crontabs", "deployments", "jobs", "nodes", "rolebindings", "clusterroles", "daemonsets", "replicasets", "statefulsets", "horizontalpodautoscalers", "replicationcontrollers", "cronjobs"

#rules.apiGroups有："","apps", "autoscaling", "batch"

curl -X 命令

從外部獲取k8s中 pod的資訊

准入控制（Admission Control）

准入控制是 API Server 的一個准入控制器外掛列表，透過新增不同的外掛，實現額外的准入控制規則。傳送到 API Server 的請求都需要經過這個列表中的每個准入控制器外掛的檢查，檢查不透過，則拒絕請求。一般建議直接採用官方預設的准入控制器。

官方准入控制器推薦列表（不同版本各有不同）：NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,NodeRestriction

這裡列舉幾個外掛的功能：

●NamespaceLifecycle：用於名稱空間回收，防止在不存在的 namespace 上建立物件，防止刪除系統預置 namespace，刪除 namespace 時，連帶刪除它的所有資源物件。●LimitRanger：用於配額管理，確保請求的資源不會超過資源所在 Namespace 的 LimitRange 的限制。●ServiceAccount：用於在每個 Pod 中自動化新增 ServiceAccount，方便訪問 API Server。●ResourceQuota：基於名稱空間的高階配額管理，確保請求的資源不會超過資源的 ResourceQuota 限制。●NodeRestriction：用於 Node 加入到 K8S 群集中以最小許可權執行。

官方文件參考：https://kubernetes.io/zh/docs/reference/access-authn-authz/admission-controllers/

實踐：建立一個使用者只能管理指定的名稱空間

建立使用者

useradd -m monorpasswd monor#設定密碼

使用這個使用者進行資源操作，會發現連線 API Server 時被拒絕訪問請求

su - monorkubectl get pods

建立證書和 kubeconfig 檔案

#建立用於使用者連線到 API Server 所需的證書和 kubeconfig 檔案#上傳證書生成工具 cfssl、cfssljson、cfssl-certinfo 到 /usr/local/bin 目錄中

cd /usr/local/bin/#上傳cfssl、cfssljson、cfssl-certinfo證書生成工具#新增執行許可權chmod +x /usr/local/bin/*ls

mkdir /opt/monorcd /opt/monorvim user-cert.shcat > monor-csr.json <<EOF{  "CN": "monor",  "hosts": [],  "key": {    "algo": "rsa",    "size": 2048  },  "names": [    {      "C": "CN",          "ST": "BeiJing",      "L": "BeiJing",      "O": "k8s",          "OU": "System"    }  ]}EOF

#API Server 會把客戶端證書的 CN 欄位作為 User，把 names.O 欄位作為 Group

chmod +x user-cert.sh./user-cert.shlscd /etc/kubernetes/pki/#使用cfssl工具生成一個證書cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /opt/monor/monor-csr.json | cfssljson -bare monor

#/etc/kubernetes/pki/ 目錄中會生成 monor-key.pem、monor.pem、monor.csr

cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /opt/monor/monor-csr.json | cfssljson -bare monor

表示使用cfssl工具生成一個證書

●-ca=ca.crt：指定一個已存在的CA證書，用於簽發新證書。

●-ca-key=ca.key：指定與CA證書關聯的私鑰。

●-profile=kubernetes：指定一個配置檔案，其中包含了用於生成證書的配置。這個配置檔案通常包含證書的OIDC、Kubernetes ServiceAccount等選項。

●/opt/monor/monor-csr.json：指定一個CSR（證書籤名請求）檔案，這個檔案包含了生成證書所需的資訊，如CN（Common Name）、O（Organization）等。

●cfssljson -bare monor：將生成的證書和私鑰儲存為PEM格式的檔案

cd /opt/monor/lsvim rbac-kubeconfig.shAPISERVER=$1# 設定叢集引數export KUBE_APISERVER="https://$APISERVER:6443"kubectl config set-cluster kubernetes \  --certificate-authority=/etc/kubernetes/pki/ca.crt \  --embed-certs=true \  --server=${KUBE_APISERVER} \  --kubeconfig=monor.kubeconfig# 設定客戶端認證引數kubectl config set-credentials monor \  --client-key=/etc/kubernetes/pki/monor-key.pem \  --client-certificate=/etc/kubernetes/pki/monor.pem \  --embed-certs=true \  --kubeconfig=monor.kubeconfig# 設定上下文引數kubectl config set-context kubernetes \  --cluster=kubernetes \  --user=monor \  --namespace=test \  --kubeconfig=monor.kubeconfig# 使用上下文引數生成 monor.kubeconfig 檔案kubectl config use-context kubernetes --kubeconfig=monor.kubeconfig

#建立test名稱空間kubectl create ns test#新增執行許可權chmod +x rbac-kubeconfig.sh#執行指令碼./rbac-kubeconfig.sh 192.168.67.30ls

檢視證書

`cat monor.kubeconfig`

mkdir /home/monor/.kubecp monor.kubeconfig /home/monor/.kube/configls /home/monor/.kube/#修改屬主和屬組為monor使用者chown -R monor:monor /home/monor/.kube/ll /home/monor/.kube/

RBAC授權

檢視幫助，編寫Role的yaml檔案

kubectl explain Rolekubectl explain RoleBinding

cd /opt/monor/vim rbac.yaml

#執行yaml檔案，建立資源kubectl apply -f rbac.yaml#列出指定 test 名稱空間中所有的 Role 和 RoleBinding 資源kubectl get role,rolebinding -n test

切換使用者，測試操作許可權

su - monor#注意 monor 使用者只在自己的家目錄有許可權，因此無法在根目錄下建立檔案vim pod-test.yamlapiVersion: v1kind: Podmetadata:  name: pod-monorspec:  containers:    - name: nginx      image: nginx

kubectl create -f pod-test.yamlkubectl get pod -o wide

報錯：kubectl無法連線到 Kubernetes 叢集

解決：執行rbac-kubeconfig.sh檔案時後面要新增本機ip

訪問 svc 資源就會被拒絕

#驗證許可權設定，嘗試獲取service資訊kubectl get svc#也無法訪問 default 名稱空間kubectl get pod -n defaultkubectl get svc -n default

使用 root 使用者檢視

kubectl get pods --all-namespaces -o wide#可以看到pod-monor角色繫結在test名稱空間上

#由此可以看出 RoleBinding 的使用者只能管理指定的名稱空間中的資源

也可以透過繫結 admin 角色來獲得管理員許可權

kubectl create rolebinding monor-admin-bingding --clusterrole=admin --user=monor --namespace=test

表示為名為 monor 的使用者在 test 名稱空間中建立一個角色繫結，並將該使用者賦予 admin 叢集角色的許可權。

透過這個角色繫結，使用者 monor 將獲得在 test 名稱空間中擁有管理員許可權的能力

su - monorkubectl get svc

讓monor普通使用者建立service並檢視

kubectl get pod#新增標籤並檢視kubectl label pod pod-monor run=monorkubectl get pod pod-monor --show-labels#建立上述pod的service並檢視kubectl expose pod pod-monor --port=80 --target-port=80 --type=ClusterIP --name=svc-monorkubectl get svc

授權普通使用者可以操作k8s資源的流程

如果想讓普通使用者能夠接入 pod、service、configMap、secret等k8s叢集相關資源的許可權怎麼做？

1.建立service account 或者使用者

2.做認證；token/證書認證① service account 會自動生成service account token 的secret 資源②使用者需要建立證書，使用cfssl 等工具透過CA證書和公鑰檔案生成證書和私鑰，使用CA證書和私鑰檔案建立kubeconfig 配置檔案，把kubeconfig 配置檔案匯入自動的家目錄中（./kube/config 檔案中）

3.做RBAC鑑權 RoleClusterRole 建立角色，賦予資源的操作許可權，RoleBinding、ClusterRoleBinding 把使用者(主體)和角色繫結

此後pod 或者使用者對有相關名稱空間中的相關資源的具有了操作許可權

總結——k8s 安全機制

認證(Authenticating)鑑權(Authorization)准入控制(Admission Control)

認證(Authenticating)

●token 認證使用很長很複雜的token字串做認證，通常是單向認證

●basic 認證使用賬戶和密碼的格式透過base64 編碼和解碼來認證，通常是單向認證

●https 認證使用透過CA 機構簽發的正式進行https認證，可以實現雙向認證

k8s認證的元件

kubectl，kubelet，controller-manager，scheduler等與API server通訊，使用https證書認證，預設使用6443埠通訊；使用kubeconfig配置檔案就知道使用了什麼證書連線到哪個k8s叢集的API server

以pod形式執行的元件：是怎麼認證的？

dashboard，coreDNS，外接儲存外掛provsisnor；與APIserver通訊，使用serviceaccount作為pod的服務賬號來訪問API sercer，每個pod 都會有一個 serviceaccount服務賬號，可以建立pod資源的時候指定serviceaccount欄位

鑑權(Authorization)

鑑權策略

●alwaysdeny●alwaysallow●ABAC**（Attribute-Based Access Control）**●Webhook●RBAC**（Role-Based Access Control）**（預設控制策略）

RBAC 的四個資源物件

角色：Role，ClusterRole；都可以實現定義角色的賦予某些資源（rules，resources）的操作許可權（rules，verbs）

●Role 受名稱空間影響，只能在某一個名稱空間中有效●ClusterRole 預設可以在k8s 中所有的名稱空間中有效，配置中不需要定義namespace

角色繫結：RoleBingding，ClusterRoleBinding；把賬戶主題繫結subject（user，group，serviceaccount）和角色進行繫結，使主體和賬戶具有相關資源的操作許可權

●Rolebinding 和同一個名稱空間的Role繫結，可以是主體賬戶在這個名稱空間中具有相關的資源操作許可權●Rolebinding 和 ClusterRole繫結，以主體賬戶在RoleBinding 所在的名稱空間中具有相關資源的操作許可權

ClusterRoleBinding 和 ClusterRole 繫結，可以使主體賬戶在k8s所有的名稱空間中具有相關的資源操作許可權

建立 RBAC 鑑權

1.先建立 Role ClusterRole 定義角色賦予某些資源的操作許可權2.再建立 RoleBinding和ClusterRoleBinding 把主體和角色進行繫結

准入控制(Admission Control)

新增准入控制外掛，實現額外的准入控制規則對資源進行請求做檢查

配置安全機制

三種認證

認證pod的兩哪種方式

連結：https://blog.csdn.net/Mo_nor/article/details/139458716?ops_request_misc=&request_id=&biz_id=102&utm_term=k8s%E5%AE%89%E5%85%A8&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduweb~default-3-139458716.142^v102^pc_search_result_base1&spm=1018.2226.3001.4187

（版權歸原作者所有，侵刪）

文末福利

就目前來說，傳統運維衝擊年薪30W+的轉型方向就是SRE&DevOps崗位。

為了幫助大家早日擺脫繁瑣的基層運維工作，給大家整理了一套高階運維工程師必備技能資料包，內容有多詳實豐富看下圖！

共有 20 個模組