Kubernetes 叢集元件安全性強化

– 8 分鐘閱讀

Kubernetes 叢集的安全性至關重要，本篇除了探討如何加固 kube-apiserver 和 kubelet 的安全性外，也涵蓋 etcd、kube-scheduler 和 kube-controller-manager 等關鍵元件的安全措施，包含設定 HTTPS 憑證、RBAC 授權、稽核日誌、憑證輪換以及最小許可權原則等。此外，文章也提供 CoreDNS 的安全強化方法，例如啟用 health 外掛程式和整合 Istio，並介紹如何使用 kube-bench 工具進行安全基準測試與風險評估，提供全面的 Kubernetes 叢集安全強化。

Kubernetes 叢集元件的安全性強化

Kubernetes 叢集的安全性是確保整個系統穩健運作的關鍵。本章節將探討如何強化 Kubernetes 叢集中的關鍵元件，包括 kube-apiserver 和 kubelet。

強化 kube-apiserver 的安全性

kube-apiserver 是 Kubernetes 叢集的核心元件，負責處理所有對叢集的請求。為了確保其安全性，需要進行多項設定和調整。

使用 AlwaysPullImages

AlwaysPullImages 准入控制確保節點上的映像檔無法在沒有正確憑證的情況下被使用。這可以防止惡意的 Pod 利用節點上已有的映像檔啟動容器。

啟用 PodSecurityPolicy

PodSecurityPolicy 用於定義 Pod 的安全敏感標準。啟用此功能可以有效限制 Pod 的行為，增強叢集安全性。

設定稽核日誌

確保 --audit-log-path 設定為安全位置的檔案，並調整 maxage、maxsize 和 maxbackup 引數以滿足合規要求。

啟用 RBAC 授權模式

RBAC（Role-Based Access Control）是建議使用的授權模式。相比 ABAC，RBAC 更易於使用和管理，適合頻繁擴充套件的環境。

使用有效的 HTTPS 憑證

確保 kube-apiserver 對 kubelet 的請求使用有效的 HTTPS 憑證。設定 --kubelet-certificate-authority、--kubelet-client-key 和 --kubelet-client-certificate 以強化安全性。

其他安全性建議

  • 停用 AlwaysAllow 授權模式
  • 啟用 service-account-lookup
  • 使用服務帳戶金鑰檔案
  • 啟用 etcd 的授權請求
  • 不停用 ServiceAccount 准入控制器
  • 使用安全的 TLS 連線
  • 啟用進階稽核功能

Minikube 中的 kube-apiserver 設定範例

在 Minikube 中，可以透過以下命令檢視 kube-apiserver 的設定：

$ ps aux | grep kube-api

輸出結果顯示了 kube-apiserver 的啟動引數，例如：

root 4016 6.1 17.2 495148 342896 ? Ssl 01:03 0:16 kube-apiserver --advertise-address=192.168.99.100 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/var/lib/minikube/certs/ca.crt ...

程式碼解析：

ps aux | grep kube-api

此命令用於查詢包含 kube-api 字串的行程資訊。

內容解密：

  1. ps 命令用於顯示目前系統中的行程資訊。
  2. aux 選項表示顯示所有使用者的行程詳細資訊。
  3. | 是管道符號，將前一個命令的輸出作為後一個命令的輸入。
  4. grep kube-api 用於過濾包含 kube-api 的行程資訊。

強化 kubelet 的安全性

kubelet 是執行在每個節點上的代理程式，負責管理節點上的容器和 Pod。

停用匿名認證

確保 --anonymous-auth=false 以防止未經認證的請求被視為匿名請求。

設定授權模式

透過設定檔指定授權模式，確保不包含 AlwaysAllow。

旋換 kubelet 憑證

使用 RotateCertificates 和 RotateKubeletServerCertificate 設定自動旋換伺服器憑證。

提供 CA 組合

設定 ClientCAFile 以驗證客戶端憑證。

停用唯讀埠

預設情況下，kubelet 的唯讀埠是啟用的，應停用它以防止未經授權的存取。

強化 Kubernetes 叢集安全：etcd、kube-scheduler 和 kube-controller-manager 的安全措施

Kubernetes 叢集的安全性取決於其各個元件的安全組態。除了 kube-apiserver 外，etcd、kube-scheduler 和 kube-controller-manager 也是至關重要的元件。本篇文章將探討如何強化這些元件的安全性，以確保 Kubernetes 叢集的整體安全。

保護 etcd

etcd 是 Kubernetes 用於儲存叢集狀態、組態和敏感資訊（如 Secrets）的關鍵值儲存系統。只有 kube-apiserver 應該被允許存取 etcd。若 etcd 被攻破，可能導致整個叢集被攻陷。

etcd 安全措施：

  1. 限制節點存取：使用 Linux 防火牆確保只有需要存取 etcd 的節點才能存取。
  2. 確保 API 伺服器使用 TLS：使用 --cert-file 和 --key-file 引數確保與 etcd 的通訊是加密的。
  3. 使用有效的憑證：啟用 --client-cert-auth 以確保客戶端使用有效的憑證進行通訊，並設定 --auto-tls 為 false 以避免使用自簽憑證。
  4. 靜態資料加密：將 --encryption-provider-config 傳遞給 API 伺服器，以確保儲存在 etcd 中的資料被加密。

Minikube 中的 etcd 組態範例如下：

$ ps aux | grep etcd
root 3992 1.9 2.4 10612080 48680 ? Ssl 01:03 0:18 etcd --advertise-client-urls=https://192.168.99.100:2379
--cert-file=/var/lib/minikube/certs/etcd/server.crt --client-cert-auth=true --data-dir=/var/lib/minikube/etcd --initial-advertise-peer-urls=https://192.168.99.100:2380 --initial-cluster=minikube=https://192.168.99.100:2380 --key-file=/var/lib/minikube/certs/etcd/server.key --listen-client-urls=https://127.0.0.1:2379,https://192.168.99.100:2379 --listen-metrics-urls=http://127.0.0.1:2381 --listen-peer-urls=https://192.168.99.100:2380 --name=minikube --peer-cert-file=/var/lib/minikube/certs/etcd/peer.crt --peer-client-cert-auth=true --peer-key-file=/var/lib/minikube/certs/etcd/peer.key --peer-trusted-ca-file=/var/lib/minikube/certs/etcd/ca.crt --snapshot-count=10000 --trusted-ca-file=/var/lib/minikube/certs/etcd/ca.crt

程式碼解析：

此命令顯示了 etcd 的執行組態，主要包括以下幾個安全相關的引數：

  • --cert-file 和 --key-file：指定 etcd 使用的伺服器憑證和私鑰，確保客戶端與 etcd 之間的通訊是加密的。
  • --client-cert-auth=true：啟用客戶端憑證驗證，確保只有持有有效憑證的客戶端才能存取 etcd。
  • --listen-client-urls：指定 etcd 監聽客戶端請求的 URL，支援 HTTPS 以加密通訊。

加固 kube-scheduler

kube-scheduler 負責為 Pod 分配節點。若 kube-scheduler 被攻破，可能影響叢集中 Pod 的效能和可用性。

kube-scheduler 安全措施：

  1. 停用效能分析：將 --profiling 設定為 false，以減少攻擊面。
  2. 停用對 kube-scheduler 的外部連線：確保 AllowExtTrafficLocalEndpoints 被停用，以防止外部連線到 kube-scheduler。
  3. 啟用 AppArmor：確保 AppArmor 在 kube-scheduler 上啟用，以加強安全性。

Minikube 中的 kube-scheduler 組態範例如下：

$ ps aux | grep kube-scheduler
root 3939 0.5 2.0 144308 41640 ? Ssl 01:03 0:02 kube-scheduler --authentication-kubeconfig=/etc/kubernetes/scheduler.conf --authorization-kubeconfig=/etc/kubernetes/scheduler.conf --bind-address=0.0.0.0 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true

程式碼解析：

此命令顯示了 kube-scheduler 的執行組態，主要包括以下幾個安全相關的引數：

  • --authentication-kubeconfig 和 --authorization-kubeconfig：指定 kube-scheduler 用於身份驗證和授權的組態檔案，確保其與 API 伺服器的安全通訊。
  • --leader-elect=true：啟用 Leader 選舉機制，確保在高用性組態中，只有一個 kube-scheduler 例項處於活躍狀態。

加固 kube-controller-manager

kube-controller-manager 管理叢集的控制迴圈，監控叢集狀態並試圖將其調整至預期狀態。若 kube-controller-manager 被攻破，可能導致叢集更新被拒絕。

kube-controller-manager 安全措施：

  1. 使用服務帳戶憑證：使用 --use-service-account-credentials，結合 RBAC，確保控制迴圈以最小許可權執行。

Minikube 中的 kube-controller-manager 組態範例如下：

$ ps aux | grep kube-controller-manager
root 3927 1.8 4.5 209520 90072 ? Ssl 01:03 0:11 kube-controller-manager --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --bind-address=0.0.0.0 --client-ca-file=/var/lib/minikube/certs/ca.crt --cluster-signing-cert-file=/var/lib/minikube/certs/ca.crt --cluster-signing-key-file=/var/lib/minikube/certs/ca.key --controllers=*,bootstrapsigner,tokencleaner --kubeconfig=/etc/kubernetes/controller-manager.conf --leader-elect=true --requestheader-client-ca-file=/var/lib/minikube/certs/front-proxy-ca.crt --root-ca-file=/var/lib/minikube/certs/ca.crt --service-account-private-key-file=/var/lib/minikube/certs/sa.key --use-service-account-credentials=true

程式碼解析：

此命令顯示了 kube-controller-manager 的執行組態，主要包括以下幾個安全相關的引數：

  • --use-service-account-credentials=true：確保每個控制器使用自己的服務帳戶憑證執行，遵循最小許可權原則。
  • --service-account-private-key-file：指定用於簽署服務帳戶 token 的私鑰檔案，增加安全性。

Kubernetes 叢集元件的安全性強化

在 Kubernetes 叢集中，安全性是非常重要的議題。叢集管理員需要確保叢集中的各個元件都遵循安全最佳實踐，以降低被攻擊的風險。本章節將介紹如何強化 Kubernetes 叢集元件的安全性。

CoreDNS 的安全性強化

CoreDNS 是 Kubernetes 叢集中的預設 DNS 伺服器。它提供了服務、Pod 和容器之間的名稱解析功能。CoreDNS 取代了舊有的 kube-dns，因為後者存在一些安全漏洞和效能問題。

編輯 CoreDNS 的設定檔

要編輯 CoreDNS 的設定檔，可以使用 kubectl 命令：

$ kubectl -n kube-system edit configmap coredns

在 Minikube 中，CoreDNS 的設定檔預設如下：

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health {
            lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

強化 CoreDNS 的安全性

要強化 CoreDNS 的安全性，可以採取以下措施：

  • 確保 health 外掛程式未被停用：health 外掛程式用於監控 CoreDNS 的狀態，可以透過在 Corefile 中新增 health 來啟用它。
  • 為 CoreDNS 啟用 istio：istio 是一種服務網格，可以提供服務發現、負載平衡和身份驗證等功能。

使用 kube-bench 評估叢集的安全性組態

Center for Internet Security (CIS) 發布了 Kubernetes 的安全基準，可以用於評估叢集的安全性組態。kube-bench 是一個自動化工具，可以執行 CIS 基準測試，並提供測試結果。

執行 kube-bench

可以在節點上直接執行 kube-bench：

$ kube-bench node --benchmark cis-1.4

對於在 GKE、EKS 和 AKS 上託管的叢集，可以將 kube-bench 作為 Pod 執行：

$ kubectl apply -f job-gke.yaml
$ kubectl get pods
NAME                  READY   STATUS      RESTARTS   AGE
kube-bench-2plpm   0/1     Completed   0          5m20s
$ kubectl logs kube-bench-2plpm
[INFO] 4 Worker Node Security Configuration
[INFO] 4.1 Worker Node Configuration Files
[WARN] 4.1.1 Ensure that the kubelet service file permissions are set to 644 or more restrictive (Not Scored)
......
== Summary ==
0 checks PASS
0 checks FAIL
37 checks WARN
0 checks INFO

分析 kube-bench 的測試結果

需要調查測試結果中標記為 FAIL 的檢查項，並制定風險緩解計劃。

重點回顧
  • CoreDNS 的安全性強化：編輯 Corefile、啟用 health 外掛程式和 istio。
  • 使用 kube-bench 評估叢集的安全性組態：執行 kube-bench、分析測試結果。

在下一章中，我們將探討 Kubernetes 中的身份驗證和授權機制。

Kubernetes 中的請求處理流程與安全機制

Kubernetes 的安全機制主要依賴於認證（Authentication）、授權（Authorization）和准入控制（Admission Control）三個核心元件。本章將探討 Kubernetes 如何處理請求，並介紹相關的安全組態和工具。

Kubernetes 請求處理流程

在 Kubernetes 中，所有對叢集狀態的修改請求都由 kube-apiserver 處理。該元件首先驗證請求的來源，透過一個或多個認證模組，包括客戶端憑證、密碼或令牌等。如果請求未被所有模組拒絕，則會被標記為匿名請求。kube-apiserver 可以組態為允許匿名請求。

一旦請求來源得到驗證，接著會透過授權模組檢查請求是否被允許執行特定操作。Kubernetes 支援多種授權模組，如屬性基礎存取控制（ABAC）、角色基礎存取控制（RBAC）和 Webhook 等。

最後，准入控制器會修改或拒絕請求。准入控制器分為兩類別：變更准入控制器和驗證准入控制器。前者會修改請求，而後者則驗證請求是否符合特定條件。如果任何准入控制器拒絕請求，則會傳回錯誤給使用者，且請求不會被 kube-apiserver 處理。

Kubernetes 認證機制

Kubernetes 中的請求可能來自外部使用者、服務帳戶或 Kubernetes 元件。如果請求來源未知，則會被視為匿名請求。根據組態，匿名請求可能會被允許或丟棄。在 v1.6+ 版本中，預設允許匿名存取以支援 RBAC 和 ABAC 授權模式。

Kubernetes 使用多種認證策略，包括：

  1. 客戶端憑證：使用 X509 憑證授權單位（CA）憑證是最常見的認證策略。可以透過 --client-ca-file 引數啟用。
  2. 靜態令牌檔案：使用靜態令牌檔案進行認證。
  3. 靜態密碼檔案：使用靜態密碼檔案進行認證。

使用客戶端憑證進行認證

要使用客戶端憑證進行認證，需要以下步驟：

  1. 產生私鑰：可以使用 openssl、easyrsa 或 cfssl 產生私鑰。
openssl genrsa -out priv.key 4096
  1. 產生憑證簽署請求（CSR）：使用私鑰和設定檔產生 CSR。
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn

[ dn ]
CN = test
O = dev

[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth

openssl req -config ./csr.cnf -new -key priv.key -nodes -out new.csr
  1. 簽署 CSR：建立 Kubernetes CertificateSigningRequest 請求。
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: mycsr
spec:
  groups:
    - system:authenticated
  request: <base64 encoded CSR>
  usages:
    - client auth

內容解密：

此段落描述瞭如何使用客戶端憑證進行 Kubernetes 認證。首先，需要產生私鑰和 CSR。接著，建立 Kubernetes CertificateSigningRequest 請求以簽署 CSR。最後，使用簽署後的憑證進行認證。

Open Policy Agent（OPA）

OPA 是一種開源工具，可用於實作跨微服務的授權策略。在 Kubernetes 中，OPA 可以用作驗證准入控制器，以提供更細粒度的授權控制。

OPA 的優點

  • 提供更細粒度的授權控制
  • 可與多種 Kubernetes 元件整合
  • 支援動態更新授權策略
玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。