Kubernetes 叢集的安全性至關重要，稽核與 RBAC 是不可或缺的機制。本文詳細說明如何設定 Kubernetes 稽核功能，記錄叢集操作並追蹤安全事件。同時，引導讀者運用 audit2rbac 工具，根據稽核日誌反向生成 RBAC 策略，有效解決許可權組態問題。此外，文章也提供 Kubernetes Dashboard 的安全佈署建議，避免直接暴露服務帶來的風險，提升叢集整體安全性。透過 Ingress 設定與 TLS 加密，確保 Dashboard 的存取通道安全可靠。
Kubernetes 稽核與 RBAC 策略除錯
啟用 Kubernetes 稽核功能
在 Kubernetes 中，稽核（Auditing）功能用於記錄叢集中的所有操作請求，包括 API 請求等。啟用稽核功能可以幫助我們更好地瞭解叢集的操作情況，並在需要時進行問題排查。
設定稽核政策
- 首先，建立一個名為
policy.yaml的檔案，並將稽核政策寫入其中。該政策定義了哪些事件需要被記錄。 - 將
policy.yaml複製到/etc/kubernetes/audit目錄下。
修改 API 伺服器設定
編輯 API 伺服器的設定檔，通常位於
/etc/kubernetes/manifests/kube-apiserver.yaml。在
command欄位中新增以下引數：- --audit-policy-file=/etc/kubernetes/audit/policy.yaml - --audit-log-path=/var/log/k8s/audit.log - --audit-log-maxage=30 - --audit-log-maxbackup=10 - --audit-log-maxsize=100這些引數指定了稽核政策檔案的位置、稽核日誌的儲存路徑以及日誌的輪替策略。
在
volumeMounts欄位中新增以下設定：- mountPath: /usr/share/ca-certificates name: usr-share-ca-certificates readOnly: true - mountPath: /var/log/k8s name: var-log-k8s readOnly: false - mountPath: /etc/kubernetes/audit name: etc-kubernetes-audit readOnly: true這些設定將主機上的目錄掛載到容器中，以便存取稽核政策檔案和儲存稽核日誌。
在
volumes欄位中新增以下設定：- hostPath: path: /usr/share/ca-certificates type: DirectoryOrCreate name: usr-share-ca-certificates - hostPath: path: /var/log/k8s type: DirectoryOrCreate name: var-log-k8s - hostPath: path: /etc/kubernetes/audit type: DirectoryOrCreate name: etc-kubernetes-audit這些設定定義了主機上的路徑與容器內掛載點的對應關係。
儲存並離開檔案。KinD 將自動偵測到設定檔的變更並重新啟動 API 伺服器的 Pod。
#### 內容解密：
--audit-policy-file指定了稽核政策檔案的路徑。--audit-log-path指定了稽核日誌的儲存路徑。volumeMounts和volumes設定確保了容器能夠存取主機上的稽核政策檔案和儲存稽核日誌。
驗證稽核功能
- 使用
kubectl get pods -n kube-system命令檢查 API 伺服器的 Pod 是否重新啟動。 - 使用
docker exec命令進入容器並檢視稽核日誌：$ docker exec cluster01-control-plane tail /var/log/k8s/audit.log - 檢視輸出的稽核日誌，可以看到類別似以下的 JSON 資料：
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"473e8161-e243-4c5d-889c-42f478025cc2","stage":"ResponseComplete","requestURI":"/apis/crd.projectcalico.org/v1/clusterinformations/default","verb":"get","user":{"username":"system:serviceaccount:kube-system:calico-kube-controllers","uid":"38b96474-2457-4ec9-a146-9a63c2b8182e","groups":["system:serviceaccounts","system:serviceaccounts:kube-system","system:authenticated"]},"sourceIPs":["172.17.0.2"],"userAgent":"Go-http-client/2.0","objectRef":{"resource":"clusterinformations","name":"default","apiGroup":"crd.projectcalico.org","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2020-05-20T00:27:07.378345Z","stageTimestamp":"2020-05-20T00:27:07.381227Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"calico-kube-controllers\" of ClusterRole \"calico-kube-controllers\" to ServiceAccount \"calico-kube-controllers/kube-system\"}}
#### 內容解密：
- 稽核日誌記錄了 Kubernetes 中的操作請求，包括請求的使用者、資源、操作型別等資訊。
- 可以透過分析稽核日誌來瞭解叢集的操作情況和安全事件。
使用 audit2rbac 除錯 RBAC 策略
- 登出 OpenUnison，然後重新登入，但移除
k8s-cluster-admins群組並新增cn=k8s-create-ns,cn=users,dc=domain,dc=com群組。 - 登入後，嘗試建立一個名為
not-going-to-work的名稱空間：PS C:\Users\mlb> kubectl create ns not-going-to-work Error from server (Forbidden): namespaces is forbidden: User "mlbiamext" cannot create resource "namespaces" in API group "" at the cluster scope - 根據錯誤訊息，建立一個名為
cluster-create-ns的 ClusterRole：apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-create-ns rules: - apiGroups: [""] resources: ["namespaces"] verbs: ["create"]
#### 內容解密：
audit2rbac工具可以根據稽核日誌反向生成 RBAC 策略物件，幫助除錯 RBAC 相關問題。- 建立 ClusterRole 和 ClusterRoleBinding 可以為使用者或群組授予特定的許可權。
使用 RBAC 進行 Kubernetes 叢集的存取控制與稽核
在 Kubernetes 中，根據角色的存取控制（Role-Based Access Control, RBAC）是管理叢集資源存取許可權的重要機制。正確組態 RBAC 原則可以有效提升叢集的安全性，並實作多租戶環境下的資源隔離。
建立與除錯 RBAC 原則
- 建立 ClusterRole 與 ClusterRoleBinding
要賦予特定使用者特定的叢集層級許可權，需要建立 ClusterRole 與 ClusterRoleBinding。以下範例展示如何建立允許使用者 mlbiamext 建立名稱空間的 ClusterRole 與對應的 ClusterRoleBinding：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-create-ns
rules:
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["create"]
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-create-ns
subjects:
- kind: User
name: mlbiamext
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-create-ns
apiGroup: rbac.authorization.k8s.io
內容解密：
ClusterRole定義了一個叢集層級的角色，允許對namespaces資源執行create操作。ClusterRoleBinding將mlbiamext使用者與cluster-create-nsClusterRole 繫結，使該使用者具備建立名稱空間的許可權。
- 使用 audit2rbac 工具進行 RBAC 除錯
當遇到複雜的 RBAC 問題時，可以使用 audit2rbac 工具分析稽核日誌，自動生成所需的 RBAC 原則。
首先，下載並解壓縮 audit2rbac 工具：
root@cluster01-control-plane:/# curl -L https://github.com/liggitt/audit2rbac/releases/download/v0.8.0/audit2rbac-linux-amd64.tar.gz > audit2rbac-linux-amd64.tar.gz
root@cluster01-control-plane:/# tar -xvzf audit2rbac-linux-amd64.tar.gz
執行 audit2rbac 分析稽核日誌：
root@cluster01-control-plane:/# ./audit2rbac --filename=/var/log/k8s/audit.log --user=mlbiamext
該命令將生成一個包含所需許可權的 ClusterRole 與 ClusterRoleBinding：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: audit2rbac:mlbiamext
rules:
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["create"]
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: audit2rbac:mlbiamext
subjects:
- kind: User
name: mlbiamext
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: audit2rbac:mlbiamext
apiGroup: rbac.authorization.k8s.io
內容解密：
audit2rbac分析稽核日誌後，生成了一個 ClusterRole 與對應的 ClusterRoleBinding，使mlbiamext使用者具備建立名稱空間的許可權。- 這種方式可以快速定位並解決 RBAC 相關問題。
最佳實踐：使用群組而非個別使用者進行授權
為了提高管理的靈活性，建議使用群組而非個別使用者進行授權：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: create-ns-audit2rbac
subjects:
- kind: Group
name: cn=k8s-create-ns,cn=users,dc=domain,dc=com
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: create-ns-audit2rbac
apiGroup: rbac.authorization.k8s.io
內容解密：
- 將許可權授予特定群組，使該群組下的所有使用者自動具備對應許可權，簡化管理流程。
Kubernetes Dashboard 的安全佈署
Kubernetes Dashboard 是叢集管理的重要工具，但其預設的存取方式可能存在安全風險。本章節將介紹如何安全地佈署與存取 Kubernetes Dashboard。
為什麼需要安全佈署 Kubernetes Dashboard
許多叢集管理者直接使用 kubectl port-forward 或代理功能存取 Dashboard，這種方式存在以下問題：
- 安全風險：直接暴露 Dashboard 可能被未授權的使用者存取。
- 使用者經驗差：需要手動設定埠轉發，操作繁瑣。
正確的佈署與存取方式
- 啟用身份驗證與授權
確保 Dashboard 後端服務具備身份驗證與授權機制，例如透過 Kubernetes 的 RBAC 系統進行細粒度許可權控制。
- 使用 Ingress 資源暴露服務
透過 Ingress 資源，可以安全地將 Dashboard 暴露給外部使用者，同時支援 HTTPS 等加密傳輸協定。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: kubernetes-dashboard
spec:
tls:
- hosts:
- dashboard.example.com
secretName: tls-secret
rules:
- host: dashboard.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: kubernetes-dashboard
port:
number: 80
圖表翻譯：
此 Ingress 組態展示瞭如何透過 TLS 安全地暴露 Kubernetes Dashboard。其中包含：
- TLS 組態，用於 HTTPS 連線。
- 路由規則，將
dashboard.example.com的請求轉發至後端服務。