Kubernetes 已成為現代雲原生環境中用於容器編航和管理的事實標準。隨著組織採用 Kubernetes，確保妥善的安全性和訪問控制變得至關重要。基於角色的訪問控制（RBAC）是 Kubernetes 提供的一種強大機制，用於定義和管理群集內的權限。在本博客文章中，我們將探索 Kubernetes 中的 RBAC，特別侧重於 ClusterRole 和 ClusterRoleBinding，這兩種控制群集級別訪問的基本組件。
理解基於角色的訪問控制（RBAC）
Kubernetes 中的 RBAC 允許管理員基於角色和綁定來定義細粒度的權限並控制對資源的訪問。它遵循最小權限原則，確保用戶、服務賬戶和組只具有執行他們預期操作的必要權限。
ClusterRole
ClusterRole 是一組定義對集群範疇資源執行操作權限的規則。與 Role 不同，Role 是在命名空間下的並限於特定命名空間，ClusterRoles 在整個集群中都適用。ClusterRoles 定義可以執行的操作，例如創建、更新、刪除或查看像 Pods、Deployments、Services 等資源。 Kubernetes 提供了一組預定義的 ClusterRoles，如 cluster-admin、view 和 edit，但你也可以創建符合特定需求的自定義 ClusterRoles。
ClusterRoleBinding
ClusterRoleBindings 將 ClusterRoles 與用戶、服務賬戶或組關聯。他們在整個集群中給特定主題授予由 ClusterRole 定義的權限。通過 ClusterRoleBinding，您可以控制誰可以訪問哪些資源，並為各種團隊、項目或應用程序定義細粒度的訪問策略。 ClusterRoleBindings 可以在與主題相同的命名空間或不同的命名空間中創建，提供了靈活的訪問控制管理方式。
實踐示例
假設您有一個開發團隊，他們需要對集群有只讀訪問權限以進行監控。您可以創建一個名為 read-only 的ClusterRole，配以如 get、list 和 watch 對 pods、services 和 namespaces 的適當權限。然後，您可以創建一個 ClusterRoleBinding，將此 ClusterRole 與開發人員組或他們的服務賬戶相關聯。這樣，開發人員將具有受限的訪問權限，確保他們無法對資源進行任何修改。
創建 ClusterRole 和 ClusterRoleBinding
要創建 ClusterRole，您可以定義類似於以下的 YAML 清單：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: read-only
rules:
- apiGroups: [""]
resources: ["pods", "services", "namespaces"]
verbs: ["get", "list", "watch"]要創建 ClusterRoleBinding，您可以定義類似於以下的 YAML 描述文件：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-only-binding
subjects:
- kind: Group
name: developers
roleRef:
kind: ClusterRole
name: read-only
apiGroup: rbac.authorization.k8s.io使用 kubectl apply -f <filename.yaml> 應用這些清單，並且 ClusterRole 和 ClusterRoleBinding 將在群集中創建。
結論
基於角色的訪問控制（RBAC）是 Kubernetes 的一個重要特性，使管理員能夠有效地控制對群集資源的訪問。 ClusterRoles 和 ClusterRoleBindings 的使用允許進行細粒度權限，並促進最小權限原則的實現。通過理解和實施 Kubernetes 中的 RBAC，組織可以加強其群集的安全性，並確保用戶、服務賬戶和組對資源的合適訪問。因此，利用 RBAC 來精通您的 Kubernetes 部署中的訪問控制，並採納安全且可擴展的集群管理。
請記住，安全是一個持續的過程，而 RBAC 只是其中的一部分。定期審視並更新您的訪問策略，以符合您不斷發展的環境，並確保您的 Kubernetes 部署保持受保護。