一，ABAC授權(quán)模式

Kubernetes ABAC（Attribute-Based Access Control）授權(quán)模式是一種基于屬性的訪問(wèn)控制模型，它可以根據(jù)用戶或組的屬性決定是否允許他們?cè)L問(wèn) Kubernetes 集群中的資源。

在使用 ABAC 授權(quán)模式時(shí)，管理員需要定義一些規(guī)則來(lái)限制哪些用戶或組有權(quán)訪問(wèn)集群中的不同資源。這些規(guī)則通常包括一個(gè)或多個(gè)屬性和一個(gè)操作，如“查看”、“創(chuàng)建”、“修改”或“刪除”。

下面是一些示例規(guī)則：

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1","kind": "Policy","spec": {"user": "admin","namespace": "*","resource": "*","readonly": true}
}

這個(gè)示例規(guī)則表示只有 admin 用戶能夠讀取任何命名空間下的所有資源。

要啟用 ABAC 授權(quán)模式，管理員必須在 kube-apiserver 的啟動(dòng)參數(shù)中添加 --authorization-mode=ABAC，并指定存儲(chǔ)策略文件路徑（通過(guò) --authorization-policy-file 選項(xiàng)）。另外，還需在 kubelet 的啟動(dòng)參數(shù)中添加 --authorization-mode=ABAC 選項(xiàng)。

需要注意的是，在 Kubernetes v1.19 版本之后，已經(jīng)棄用了 ABAC 授權(quán)模式，并且在將來(lái)的版本中將被移除。建議使用更安全、更靈活的 RBAC （Role-Based Access Control）或其他授權(quán)模式。

二，Webhook授權(quán)模式

Kubernetes Webhook 授權(quán)模式是一種基于 HTTP 回調(diào)的訪問(wèn)控制模型，它可以通過(guò)向外部 Web 服務(wù)發(fā)送請(qǐng)求來(lái)判斷用戶是否有權(quán)限訪問(wèn) Kubernetes 集群中的資源。

在使用 Webhook 授權(quán)模式時(shí)，管理員需要定義一個(gè) HTTP 回調(diào) URL，然后將該 URL 注冊(cè)到 Kubernetes API Server 中。當(dāng)用戶發(fā)起請(qǐng)求時(shí)，API Server 會(huì)將請(qǐng)求信息發(fā)送到該 URL 上，并等待一個(gè)命名為 "status" 的 JSON 對(duì)象作為響應(yīng)。

Webhook 授權(quán)模式中的回調(diào)服務(wù)可以進(jìn)行各種自定義邏輯來(lái)決定用戶是否有權(quán)限訪問(wèn)集群中的資源。例如，它可以查詢 LDAP 或 Active Directory 來(lái)獲取用戶組成員身份、檢查 JWT token 簽名或者從 RBAC 角色映射文件中讀取策略。

下面是一個(gè)示例 webhook 配置：

apiVersion: v1
kind: ConfigMap
metadata:name: my-auth-config
data:authz.yaml: |clusterName: my-k8s-clusterendpoint: https://my-webhook-service-endpoint.com/authz-check

這個(gè)配置表明了 webhook 認(rèn)證所需要的參數(shù)：集群名稱和認(rèn)證服務(wù)端點(diǎn) URL。

要啟用 Webhook 授權(quán)模式，管理員需要在 kube-apiserver 的啟動(dòng)參數(shù)中添加 --authorization-mode=Webhook，并指定配置文件路徑（通過(guò) --authorization-webhook-config-file 選項(xiàng)）。另外還需啟動(dòng) webhook 容器并監(jiān)聽(tīng) API 請(qǐng)求。

三，RBAC授權(quán)模式

Kubernetes RBAC (Role-Based Access Control) 授權(quán)模式是一種基于角色和權(quán)限的訪問(wèn)控制模型，它可以對(duì) Kubernetes 集群中的資源進(jìn)行精細(xì)化的授權(quán)管理。

在使用 RBAC 授權(quán)模式時(shí)，管理員需要定義三種類型的對(duì)象：

1. Role：角色，用來(lái)定義一組權(quán)限；
2. RoleBinding：角色綁定，將一個(gè)角色與一個(gè)用戶或用戶組關(guān)聯(lián)起來(lái)；
3. ClusterRole：集群級(jí)別的角色，用來(lái)定義一組跨命名空間的權(quán)限；

然后就可以通過(guò) Kubernetes API 來(lái)創(chuàng)建、更新和刪除這些對(duì)象。例如，下面是一個(gè)簡(jiǎn)單的 RBAC 示例：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:namespace: defaultname: pod-reader
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "watch", "list"]---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:name: read-podsnamespace: default
subjects:
- kind: User # 用戶類型為 User 或 Group name: test-user # 要授權(quán)的用戶名或用戶組名 
roleRef:kind: Role # 角色類型為 Role 或 ClusterRole name: pod-reader # 要綁定到的角色名稱 apiGroup: rbac.authorization.k8s.io

這個(gè)例子中創(chuàng)建了一個(gè) PodReader 的角色，并將其綁定到了 test-user 用戶上。該角色的權(quán)限是只讀訪問(wèn) Pods 資源，而且這個(gè)角色只能在 default 命名空間中使用。

要啟用 RBAC 授權(quán)模式，管理員需要在 kube-apiserver 的啟動(dòng)參數(shù)中添加 --authorization-mode=RBAC。如果你使用的是 Kubernetes v1.6 及以上版本，則該參數(shù)默認(rèn)已開(kāi)啟。

四，Pod的安全策略配置

Kubernetes 的 Pod 安全策略可以幫助我們提高集群的安全性。以下是一些常見(jiàn)的 Pod 安全策略配置：

1. 禁止特權(quán)容器：特權(quán)容器是具有 Linux 的 root 權(quán)限和訪問(wèn)主機(jī)名字空間、網(wǎng)絡(luò)名字空間等權(quán)限的容器。禁止使用特權(quán)容器可以有效地避免攻擊者利用容器逃脫沙盒。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:name: restrict-privilege
spec:privileged: falseallowPrivilegeEscalation: false

1. 文件系統(tǒng)只讀：將文件系統(tǒng)設(shè)置為只讀，可以防止攻擊者在運(yùn)行時(shí)修改敏感信息或植入木馬。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:name: readonly-fs
spec:volumes:- configMap- downwardAPI- emptyDir- persistentVolumeClaim- projected - secret fsGroup:rule: RunAsAny # 繼承宿主機(jī)用戶組 runAsUser:rule: RunAsAny # 繼承宿主機(jī)用戶 seLinux:rule: RunAsAny # 繼承宿主機(jī) SELinux 標(biāo)簽 supplementalGroups:rule: MustRunAs # 必須以指定用戶組運(yùn)行 

1. AppArmor 或 Seccomp：AppArmor 和 Seccomp 是兩種 Linux 安全模塊，它們可以限制容器的系統(tǒng)調(diào)用和文件系統(tǒng)訪問(wèn)權(quán)限。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:name: restrict-apparmor-seccomp
spec:seLinux:rule: RunAsAny # 繼承宿主機(jī) SELinux 標(biāo)簽 supplementalGroups:rule: MustRunAs # 必須以指定用戶組運(yùn)行 volumes:- configMap- downwardAPI- emptyDir- persistentVolumeClaim allowedUnsafeSysctls:- "kernel.msg*"forbiddenSysctls:- "net.ipv4.ip_forward"

在配置完 Pod 安全策略后，需要?jiǎng)?chuàng)建一個(gè) ClusterRoleBinding 對(duì)象來(lái)將該安全策略綁定到 ServiceAccount 上：

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:name: psp-admin-binding
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRole name: psp-admin 
subjects:
- kind: ServiceAccount name: default namespace: default

這個(gè)例子中創(chuàng)建了一個(gè)名為?restrict-privilege?的 PodSecurityPolicy，并將其綁定到了默認(rèn)的 ServiceAccount 上。這樣，在使用該 ServiceAccount 創(chuàng)建 Pod 或 Deployment 時(shí)，就會(huì)自動(dòng)應(yīng)用這個(gè)安全策略。