最後，我們要來介紹安全性相關的服務，目前有兩個作為權限的管理機制，分別是 Cloud IAM 與 RBAC。Cloud IAM 是 GCP 專案本身的權限管理，於 k8s 上著重於叢集的權限；而 RBAC 著重於 k8s 內部資源的權限管理。

k8s 兩大身分使用者

• 一般使用者
  • 受 Cloud IAM 管理
• 服務帳戶
  • 受 k8s 管理
  • 僅用於叢集內部範圍
  • 可以用於不同的命名空間
  • 可以 mapping Google 服務帳戶，例如 Workload Identity

與 GKE 相關的 Cloud IAM 權限

• Kubernetes Engine 管理者：具備 Kubernetes 叢集及其 Kubernetes API 物件的完整管理權。
• Kubernetes Engine 開發人員：具備 Kubernetes 叢集中 Kubernetes API 物件的完整權限。
• Kubernetes Engine 檢視者：具備 Kubernetes Engine 資源的唯讀權限。
• Kubernetes Engine 叢集管理者：可管理 Kubernetes 叢集。
• Kubernetes Engine 叢集檢視者：可取得及列出 GKE 叢集。

命名空間 (namespace) 介紹

命名空間可以跨節點 (node)，不同節點的 pod 可以設定同一個命名空間名稱，以達到邏輯分層機制。初始會有三個命名空間：

• Default：預設 Pod 會佈署到這裡
• Kube-system：是給 Control Plane 使用，預設會隱藏起來
• kube-public：可以將沒有要對外服務的 Workload 可以佈署到這裡

角色的存取控制 (RBAC) 介紹

角色的存取控制 (Role-Based Access Control, RBAC) 是可以基於組織用戶中的角色來控制主機服務與網路資源的方法。

結構

角色設定

對象可以有：user, group, ServiceAccount

Role (rule+subject)

• 需指定 Namespace

官方範例：

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

ClusterRole

• 不需要指定 namespace，套用所有 namespace

官方範例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

在 GKE 要存取雲端服務

傳統建立流程 (會產生實體金鑰會有洩漏風險)

• 在 Cloud IAM 建立服務帳戶
• 給予合適的最小權限
• 產生該服務帳戶的金鑰
• 然後建立 Secret object 放入金鑰

新版建立流程 (不用產生實體金鑰)

• 在 Cloud IAM 建立服務帳戶
• 給予合適的最小權限
• 將服務帳戶 mapping，使該服務帳戶可以被 k8s 使用
• 在 GKE 端，告訴 GKE 說你可以代表 IAM 的指定服務帳戶

參考來源

• Google Cloud OnBoard：Google Kubernetes Engine 入門
• Using RBAC Authorization| kubernetes