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

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

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

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

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

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

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

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

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

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

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

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

下面是一個示例 webhook 配置：

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

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

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

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

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

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

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

然后就可以通過 Kubernetes API 來創(chuàng)建、更新和刪除這些對象。例如，下面是一個簡單的 RBAC 示例：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

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

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

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

四，Pod的安全策略配置

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

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

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

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

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

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

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

在配置完 Pod 安全策略后，需要創(chuàng)建一個 ClusterRoleBinding 對象來將該安全策略綁定到 ServiceAccount 上：

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

這個例子中創(chuàng)建了一個名為?restrict-privilege?的 PodSecurityPolicy，并將其綁定到了默認的 ServiceAccount 上。這樣，在使用該 ServiceAccount 創(chuàng)建 Pod 或 Deployment 時，就會自動應(yīng)用這個安全策略。文章來源地址http://www.zghlxwxcb.cn/news/detail-620851.html

到了這里，關(guān)于在CSDN學(xué)Golang云原生（Kubernetes集群安全）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！