【Kubernetes】k8s集群安全機(jī)制

機(jī)制說明

Kubernetes 作為一個(gè)分布式集群的管理工具，保證集群的安全性是其一個(gè)重要的任務(wù)。API Server 是集群內(nèi)部各個(gè)組件通信的中介， 也是外部控制的入口。所以 Kubernetes 的安全機(jī)制基本就是圍繞保護(hù) API Server 來設(shè)計(jì)的。
比如 kubectl 如果想向 API Server 請(qǐng)求資源，需要過三關(guān)，第一關(guān)是認(rèn)證（Authentication），第二關(guān)是鑒權(quán)（Authorization）， 第三關(guān)是準(zhǔn)入控制（Admission Control），只有通過這三關(guān)才可能會(huì)被 K8S 創(chuàng)建資源。

一、認(rèn)證（Authentication）

1.k8s集群內(nèi)的三種認(rèn)證方式

●HTTP Token 認(rèn)證：通過一個(gè) Token 來識(shí)別合法用戶
HTTP Token 的認(rèn)證是用一個(gè)很長的特殊編碼方式的并且難以被模仿的 Token 字符串來表達(dá)客戶的一種方式。Token 是一個(gè)很長的很復(fù)雜的字符串，每一個(gè) Token 對(duì)應(yīng)一個(gè)用戶名存儲(chǔ)在 API Server 能訪問的文件中。當(dāng)客戶端發(fā)起 API 調(diào)用請(qǐng)求時(shí)，需要在 HTTP Header 里放入 Token。

●HTTP Base 認(rèn)證：通過用戶名+密碼的方式認(rèn)證
用戶名:密碼 用 BASE64 算法進(jìn)行編碼后的字符串放在 HTTP Request 中的 Heather Authorization 域里發(fā)送給服務(wù)端， 服務(wù)端收到后進(jìn)行解碼，獲取用戶名及密碼。

●HTTPS 證書認(rèn)證（最嚴(yán)格）：基于 CA 根證書簽名的客戶端身份認(rèn)證方式。

注意：Token 認(rèn)證和 Base 認(rèn)證方式只能進(jìn)行服務(wù)端對(duì)客戶端的單向認(rèn)證，而客戶端不知道服務(wù)端是否合法；而 HTTPS 證書認(rèn)證方式 則可以實(shí)現(xiàn)雙向認(rèn)證。

2.k8s集群內(nèi)的認(rèn)證說明

1）需要被認(rèn)證的訪問類型：
●Kubernetes 組件對(duì) API Server 的訪問：kubectl、kubelet、kube-proxy
●Kubernetes 管理的 Pod 對(duì) API Server 的訪問：Pod（coredns,dashborad 也是以 Pod 形式運(yùn)行）

2）安全性說明：
●Controller Manager、Scheduler 與 API Server 在同一臺(tái)機(jī)器，所以直接使用 API Server 的非安全端口訪問（比如 8080 端口）
●kubectl、kubelet、kube-proxy 訪問 API Server 就都需要證書進(jìn)行 HTTPS 雙向認(rèn)證，端口號(hào)使用 6443

3）證書頒發(fā)：
●手動(dòng)簽發(fā)：使用二進(jìn)制部署時(shí)，需要先手動(dòng)跟 CA 進(jìn)行簽發(fā) HTTPS 證書
●自動(dòng)簽發(fā)：kubelet 首次訪問 API Server 時(shí)，使用 token 做認(rèn)證，通過后，Controller Manager 會(huì)為 kubelet 生成一個(gè)證書， 以后的訪問都是用證書做認(rèn)證了

4）kubeconfig
kubeconfig 文件包含集群參數(shù)（CA 證書、API Server 地址），客戶端參數(shù)（上面生成的證書和私鑰），集群 context 上下文參數(shù) （集群名稱、用戶名）。Kubenetes 組件（如 kubelet、kube-proxy）通過啟動(dòng)時(shí)指定不同的 kubeconfig 文件可以切換到不同的集群 ，連接到 apiserver。
也就是說 kubeconfig 文件既是一個(gè)集群的描述，也是集群認(rèn)證信息的填充。包含了集群的訪問方式和認(rèn)證信息。kubectl 文件默認(rèn)位于 ~/.kube/config

5）Service Account
Service Account是為了方便 Pod 中的容器訪問API Server。因?yàn)?Pod 的創(chuàng)建、銷毀是動(dòng)態(tài)的，所以要為每一個(gè) Pod 手動(dòng)生成證書就不可行了。 Kubenetes 使用了 Service Account 來循環(huán)認(rèn)證，從而解決了 Pod 訪問API Server的認(rèn)證問題。

6）Secret 與 SA 的關(guān)系
//Kubernetes 設(shè)計(jì)了一種資源對(duì)象叫做 Secret，分為兩類：
●用于保存 ServiceAccount 的 service-account-token
●用于保存用戶自定義保密信息的 Opaque

3.Service Account 包含三個(gè)部分

●Token：是使用 API Server 私鑰簽名的 Token 字符串序列號(hào)，用于訪問 API Server 時(shí)，Server 端認(rèn)證
●ca.crt：ca 根證書，用于 Client 端驗(yàn)證 API Server 發(fā)送來的證書
●namespace：標(biāo)識(shí)這個(gè) service-account-token 的作用域名空間

注意：默認(rèn)情況下，每個(gè) namespace 都會(huì)有一個(gè) Service Account，如果 Pod 在創(chuàng)建時(shí)沒有指定 Service Account，就會(huì)使用 Pod 所屬的 namespace 的 Service Account。每個(gè) Pod 在創(chuàng)建后都會(huì)自動(dòng)設(shè)置 spec.serviceAccount 為 default（除非指定了其他 Service Accout）。

二、 鑒權(quán)（Authorization）

1.鑒權(quán)的方式

之前的認(rèn)證（Authentication）過程，只是確定通信的雙方都確認(rèn)了對(duì)方是可信的，可以相互通信。而鑒權(quán)是確定請(qǐng)求方有哪些資源的權(quán)限。API Server 目前支持以下幾種授權(quán)策略：（通過 API Server 的啟動(dòng)參數(shù) “--authorization-mode” 設(shè)置）
●AlwaysDeny：表示拒絕所有的請(qǐng)求，一般用于測試
●AlwaysAllow：允許接收所有請(qǐng)求，如果集群不需要授權(quán)流程，則可以采用該策略，一般用于測試
●ABAC（Attribute-Based Access Control）：基于屬性的訪問控制，表示使用用戶配置的授權(quán)規(guī)則對(duì)用戶請(qǐng)求進(jìn)行匹配和控制。也就是說定義一個(gè)訪問類型的屬性，用戶可以使用這個(gè)屬性訪問對(duì)應(yīng)的資源。此方式設(shè)置較為繁瑣，每次設(shè)置需要定義一長串的屬性才可以。
●Webhook：通過調(diào)用外部 REST 服務(wù)對(duì)用戶進(jìn)行授權(quán)，即可在集群外部對(duì)K8S進(jìn)行鑒權(quán)
●RBAC（Role-Based Access Control）：基于角色的訪問控制，K8S自1.6版本起默認(rèn)使用規(guī)則

2.RBAC 相對(duì)其它訪問控制方式的優(yōu)勢：

●對(duì)集群中的資源（Pod,Deployment,Service）和非資源（元信息或者資源狀態(tài)）均擁有完整的覆蓋
●整個(gè) RBAC 完全由幾個(gè) API 資源對(duì)象完成，同其它 API 資源對(duì)象一樣，可以用 kubectl 或 API 進(jìn)行操作
●可以在運(yùn)行時(shí)進(jìn)行調(diào)整，無需重啟 API Server，而 ABAC 則需要重啟 API Server

3.RBAC 的 API 資源對(duì)象說明

RBAC 引入了 4 個(gè)新的頂級(jí)資源對(duì)象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4 種對(duì)象類型均可以通過 kubectl 與 API Server 操作。

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

4.RBAC的角色與角色綁定

//角色
Role：授權(quán)指定命名空間的資源控制權(quán)限
ClusterRole：可以授權(quán)所有命名空間的資源控制權(quán)限
#如果使用 RoleBinding 綁定 ClusterRole，仍會(huì)受到命名空間的影響；如果使用 ClusterRoleBinding 綁定 ClusterRole， 將會(huì)作用于整個(gè) K8S 集群。

//角色綁定
RoleBinding：將角色綁定到主體（即subject）
ClusterRoleBinding：將集群角色綁定到主體

//主體（subject）
User：用戶
Group：用戶組
ServiceAccount：服務(wù)賬號(hào)
#User 使用字符串表示，它的前綴 system: 是系統(tǒng)保留的，集群管理員應(yīng)該確保普通用戶不會(huì)使用這個(gè)前綴格式；Group 書寫格式與 User 相同，同樣 system: 前綴也為系統(tǒng)保留。
#Pod使用 ServiceAccount 認(rèn)證時(shí)，service-account-token 中的 token（JWT） 會(huì)保存用戶信息。 有了用戶信息，再創(chuàng)建一對(duì)角色/角色綁定（集群角色/集群角色綁定）資源對(duì)象，就可以完成權(quán)限綁定了。

5.Role and ClusterRole

在 RBAC API 中，Role 表示一組規(guī)則權(quán)限，權(quán)限只能增加（累加權(quán)限），不存在一個(gè)資源一開始就有很多權(quán)限而通過 RBAC 對(duì)其進(jìn)行減少的操作。也就是說只有白名單權(quán)限，而沒有黑名單權(quán)限的概念。

Role 只能定義在一個(gè) namespace 中，如果想要跨 namespace 則可以創(chuàng)建 ClusterRole，也就是說定義 ClusterRole 不需要綁定 namespace。

1）Role的字段定義

apiVersion: rbac.authorization.k8s.io/v1 #指定 core API 組和版本
kind: Role #指定類型為 Role
metadata:
 namespace: default #使用默認(rèn)命名空間
 name: pod-reader #Role 的名稱
rules: #定義規(guī)則
- apiGroups: [""] #標(biāo)明 core API 組
 resources: ["pods"] #資源對(duì)象為 Pod 類型
 verbs: ["get","watch","list"] #被授予的操作權(quán)限

注意：以上配置的意義是，如果把 pod-reader 這個(gè) Role 賦予給一個(gè)用戶，那么這個(gè)用戶將在 default 命名空間中具有對(duì) Pod 資源對(duì)象 進(jìn)行 get（獲?。?、watch（監(jiān)聽）、list（列出）這三個(gè)操作權(quán)限。

2）ClusterRole 示例

apiVersion:rbac.authorization.k8s.io/v1
kind:ClusterRole
metadata:
 #"namespace"被忽略，因?yàn)?ClusterRoles 不受名字空間限制
 name: secret-reader
rules:
- apiGroups: [""]
 resources: ["secrets"] #資源對(duì)象為 Secret 類型
 verbs: ["get","watch","list"]

3）RoleBinding and ClusterRoleBinding示例

RoloBinding 可以將角色中定義的權(quán)限授予用戶或用戶組，RoleBinding 包含一組主體（subject），subject 中包含有不同形式的待授予權(quán)限資源類型（User、Group、ServiceAccount）；
RoloBinding 同樣包含對(duì)被綁定的 Role 引用；
RoleBinding 適用于某個(gè)命名空間內(nèi)授權(quán)，而 ClusterRoleBinding 適用于集群范圍內(nèi)的授權(quán)

apiVersion:rbac.authorization.k8s.io/v1
kind:RoleBinding
metadata:
 name: read-pods
namespace:default
subjects:
- kind: User
 name: zhangsan
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: pod-reader
 apiGroup: rbac.authorization.k8s.io

#將default命名空間的 pod-reader Role 授予 zhangsan 用戶，此后 zhangsan 用戶在default命名空間中將具有 pod-reader 的權(quán)限。

6.Resources

Kubernetes 集群內(nèi)一些資源一般以其名稱字符串來表示，這些字符串一般會(huì)在 API 的 URL 地址中出現(xiàn)； 同時(shí)某些資源也會(huì)包含子資源，例如 log 資源就屬于 pods 的子資源，API 中對(duì) Pod 日志的請(qǐng)求 URL 樣例如下：

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

kubectl get pods myapp-demo1 -n default

HTTP GET  https:///api/v1/namespaces/default/pods/myapp-demo1/log

#在這里，pods 對(duì)應(yīng)名字空間作用域的 Pod 資源，而 log 是 pods 的子資源。

如果要在 RBAC 授權(quán)模型中控制這些子資源的訪問權(quán)限，可以通過 / 分隔符來分隔資源和子資源實(shí)現(xiàn)。






AI寫代碼

#以下是一個(gè)定義允許某主體讀取 pods 同時(shí)訪問這些 Pod 的 log 子資源的 Role 定義樣例：
apiVersion:rbac.authorization.k8s.io/v1
kind:Role
metadata:
namespace:default
 name: pod-and-pod-logs-reader
rules:
- 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"

三、準(zhǔn)入控制（Admission Control）

1.概念

準(zhǔn)入控制是 API Server 的一個(gè)準(zhǔn)入控制器插件列表，通過添加不同的插件，實(shí)現(xiàn)額外的準(zhǔn)入控制規(guī)則。發(fā)送到 API Server 的請(qǐng)求都需要經(jīng)過這個(gè)列表中的每個(gè)準(zhǔn)入控制器插件的檢查，檢查不通過，則拒絕請(qǐng)求。
一般建議直接采用官方默認(rèn)的準(zhǔn)入控制器。

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

2.列舉幾個(gè)插件的功能

●NamespaceLifecycle：用于命名空間回收，防止在不存在的 namespace 上創(chuàng)建對(duì)象，防止刪除系統(tǒng)預(yù)置 namespace，刪除 namespace 時(shí)，連帶刪除它的所有資源對(duì)象。
●LimitRanger：用于配額管理，確保請(qǐng)求的資源量不會(huì)超過資源所在 Namespace 的 LimitRange 的限制。
●ServiceAccount：用于在每個(gè) Pod 中自動(dòng)化添加 ServiceAccount，方便訪問 API Server。
●ResourceQuota：基于命名空間的高級(jí)配額管理，確保請(qǐng)求的資源數(shù)量不會(huì)超過資源的 ResourceQuota 限制。
●NodeRestriction： 用于 Node 加入到 K8S 群集中以最小權(quán)限運(yùn)行。

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

3.資源限制 - Pod

Kubernetes對(duì)資源的限制實(shí)際上是通過cgroup來控制的，cgroup是容器的一組用來控制內(nèi)核如何運(yùn)行進(jìn)程的相關(guān)屬性集合。針對(duì)內(nèi)存、CPU 和各種設(shè)備都有對(duì)應(yīng)的 cgroup。
默認(rèn)情況下，Pod 運(yùn)行沒有 CPU 和內(nèi)存的限額。這意味著系統(tǒng)中的任何 Pod 將能夠像執(zhí)行該 Pod 所在的節(jié)點(diǎn)一樣， 消耗足夠多的 CPU 和內(nèi)存。一般會(huì)針對(duì)某些應(yīng)用的 pod 資源進(jìn)行資源限制，這個(gè)資源限制是通過 resources 的 requests 和 limits 來實(shí)現(xiàn)。requests 為創(chuàng)建 Pod 時(shí)初始要分配的資源，limits 為 Pod 最高請(qǐng)求的資源值。

示例：

spec:
 containers:
- image: xxxx
  imagePullPolicy: IfNotPresent
  name: auth
  ports:
 - containerPort: 8080
   protocol: TCP
  resources:
   limits:
    cpu: "2"
    memory: 1Gi
   requests:
    cpu: 250m
    memory: 250Mi

4.資源限制 - 命名空間

1）計(jì)算資源配額

apiVersion:v1
kind:ResourceQuota    #使用 ResourceQuota 資源類型
metadata:
 name: compute-resources
namespace: spark-cluster #指定命令空間
spec:
 hard:
  pods:"20"  #設(shè)置 Pod 數(shù)量最大值
  requests.cpu:"2"
  requests.memory:1Gi
  limits.cpu:"4"
  limits.memory:2Gi

2）配置對(duì)象數(shù)量配額限制

apiVersion: v1
kind: ResourceQuota
metadata:
 name: object-counts
 namespace: spark-cluster
spec:
 hard:
  configmaps: "10"
  persistentvolumeclaims: "4"    #設(shè)置 pvc 數(shù)量最大值
  replicationcontrollers: "20"  #設(shè)置 rc 數(shù)量最大值
  secrets: "10"
  services: "10"
  services.loadbalancers: "2"

#如果Pod沒有設(shè)置requests和limits，則會(huì)使用當(dāng)前命名空間的最大資源；如果命名空間也沒設(shè)置，則會(huì)使用集群的最大資源。
K8S 會(huì)根據(jù) limits 限制 Pod 使用資源，當(dāng)內(nèi)存超過 limits 時(shí) cgruops 會(huì)觸發(fā) OOM。

這里就需要?jiǎng)?chuàng)建 LimitRange 資源來設(shè)置 Pod 或其中的 Container 能夠使用資源的最大默認(rèn)值
apiVersion: v1
kind: LimitRange   #使用 LimitRange 資源類型
metadata:
 name: mem-limit-range
 namespace: test  #可以給指定的 namespace 增加一個(gè)資源限制
spec:
 limits:
 - default:     #default 即 limit 的值
   memory: 512Mi
   cpu: 500m
  defaultRequest:  #defaultRequest 即 request 的值
   memory: 256Mi
   cpu: 100m
  type: Container #類型支持 Container、Pod、PVC

鏈接：https://blog.csdn.net/weixin_68840588/article/details/141318944?spm=1001.2014.3001.5502