如何使用服務帳戶加固 k8s 集群

Question

我正在尋找使用服務帳戶來強化我的集群。 現在所有的 pod 都在使用默認的服務賬戶。 我認為我的方法是為集群中當前的 pod 創建一個單獨的服務帳戶。 我現在的困惑是了解我為每個 pod 分配主題（即服務帳戶）的角色/clusterRoles（權限）？ 對於某些 pod，我將如何確定它是否甚至需要訪問集群 API？

我的集群包含以下內容（出於隱私考慮，我刪除了 IP）：

kubectl get all
NAME                                                        READY   STATUS    RESTARTS   AGE
pod/nginx-ingress-ingress-nginx-controller   1/1     Running   0          
 
NAME                                                       TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)                      AGE
service/kubernetes                                         ClusterIP         <none>                         443/TCP                      123d
service/nginx-ingress-ingress-nginx-controller             LoadBalancer                                      80:31180/TCP,443:31405/TCP   116d
service/nginx-ingress-ingress-nginx-controller-admission   ClusterIP         <none>                          443/TCP                      116d
 
NAME                                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-ingress-ingress-nginx-controller   1/1     1            1           116d
 
NAME                                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-ingress-ingress-nginx-controller                1         1         1       7d19h
 
 
root@osboxes:/home/osboxes# kubectl get all -n <>
NAME                               READY   STATUS    RESTARTS   AGE
pod/mariadb-0               1/1     Running   0          5d19h
pod/web2                    1/1     Running   0          7d17h
 
NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/mariadb   ClusterIP                           <none>        3306/TCP   123d
service/web       ClusterIP                           <none>        80/TCP     116d
 
NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/web2          1/1     1            1           7d17h
 
NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/web2-6f8d8bcc76          1         1         1       7d17h
 
NAME                              READY   AGE
statefulset.apps/mariadb          1/1     123d
 
 
kubectl get all -n cert-manager
NAME                                          READY   STATUS    RESTARTS   AGE
pod/cert-manager-6b5c6b786d-cc448             1/1     Running   0          5d19h
pod/cert-manager-cainjector-6bc9d758b-sdb8l   1/1     Running   0          9d
pod/cert-manager-webhook-586d45d5ff-jsh54     1/1     Running   0          9d
 
NAME                           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/cert-manager           ClusterIP                     <none>        9402/TCP   12d
service/cert-manager-webhook   ClusterIP                     <none>        443/TCP    12d
 
NAME                                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cert-manager              1/1     1            1           12d
deployment.apps/cert-manager-cainjector   1/1     1            1           12d
deployment.apps/cert-manager-webhook      1/1     1            1           12d
 
NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/cert-manager-6b5c6b786d             1         1         1       7d20h
replicaset.apps/cert-manager-6bbf595697             0         0         0       12d
replicaset.apps/cert-manager-788ff5c97d             0         0         0       7d21h
replicaset.apps/cert-manager-cainjector-6bc9d758b   1         1         1       12d
replicaset.apps/cert-manager-webhook-586d45d5ff     1         1         1       12d

Answer 1

不僅僅是更改默認服務帳戶，您還需要遵循 NSA/CISA Kubernetes Hardening Guide 。

對於 Pod 安全實施：

對 Pod 執行安全要求可以通過兩種機制在 Kubernetes 中本地完成：

1. 稱為 Pod 安全准入的 beta1 版本功能 - 生產 Kubernetes 管理員應采用 Pod 安全准入，因為該功能在 Kubernetes 版本 1.23 中默認啟用。 Pod 安全准入基於將 pod 分類為特權、基線和受限，並提供比 PSP 更直接的實現。 有關 Pod 安全准入的更多信息，請參見在線文檔2。
2. 一個名為 Pod 安全策略 (PSP) 的已棄用功能 - 在過渡到 Pod 安全許可時使用 PSP 的管理員可以使用附錄 C：Pod 安全策略中的信息來增強其 PSP。

保護 Pod 服務帳戶令牌：

默認情況下，Kubernetes 在創建 Pod 時會自動提供服務帳戶，並在運行時將帳戶的秘密令牌掛載到 Pod 中。 許多容器化應用程序不需要直接訪問服務帳戶，因為 Kubernetes 編排在后台透明地發生。 如果應用程序遭到破壞，網絡參與者可以收集 Pod 中的帳戶令牌並用於進一步破壞集群。 當應用程序不需要直接訪問服務帳戶時，Kubernetes 管理員應確保 Pod 規范禁用正在掛載的秘密令牌。 這可以使用 Pod 的 YAML 規范中的“ automountServiceAccountToken: false ”指令來完成。

在某些情況下，容器化應用程序使用預配置的服務帳戶令牌向外部服務（例如雲平台）進行身份驗證。 在這些情況下，禁用帳戶令牌可能是不可行的。 相反，集群管理員應確保實施 RBAC 以限制集群內的 Pod 權限。

RBAC ：

基於角色的訪問控制 (RBAC) 是一種根據組織內各個用戶的角色來調節對計算機或網絡資源的訪問的方法。

RBAC 授權使用 rbac.authorization.k8s.io API 組來驅動授權決策，允許您通過 Kubernetes API 動態配置策略。