Configuring Permissions in Kubernetes With RBAC

Kubernetes · 發表 2018-11-04 16:14:23

摘要： Configuring permissions in Kubernetes with RBAC 原文確保控制誰有權訪問您的資訊系統以及使用者可以訪問的內容是身份和訪問管理系統的目標。它是安全管理的基本流程之一，應該徹底解決。在 Kubernetes 中，身份和...

Configuring permissions in Kubernetes with RBAC

ofollow,noindex" target="_blank">原文

確保控制誰有權訪問您的資訊系統以及使用者可以訪問的內容是身份和訪問管理系統的目標。它是安全管理的基本流程之一，應該徹底解決。

在 Kubernetes 中，身份和使用者管理未整合在平臺中，應由外部 IAM 平臺（如 Keycloak，Active Directory，Google 的 IAM 等）進行管理。但是，身份驗證和授權由 Kubernetes 處理。

在本文中，我們將重點關注 Kubernetes 中 IAM 的授權方面，更具體地說，關於如何使用基於角色的訪問控制模型確保使用者對相應的資源具有正確的許可權。

先決條件

RBAC 是 Kubernetes 1.8 的穩定功能。在本文中，我們假設您使用的是 Kubernetes 1.9+。我們還假設您的叢集中已通過 Kubernetes API 伺服器中的--authorization-mode = RBAC 選項啟用了 RBAC。您可以通過執行命令kubectl api-versions 來檢查這一點; 如果啟用了 RBAC，您應該看到 API 版本.rbac.authorization.k8s.io/v1 。

RBAC 核心內容概覽

Kubernetes 中的 RBAC 模型基於三個要素：

Roles：定義每個 Kubernetes 資源型別的許可權
Subjects：使用者（人或機器使用者）或使用者組
RoleBindings：定義哪些 subjects 具有哪些 roles

讓我們來探索這些元素是如何工作的。

在下面的示例中，您可以看到一個允許在名稱空間“mynamespace”中獲取，列出和監視 pod 的角色：

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

要為使用者提供上面角色中描述的許可權，必須建立一個 RoleBinding。在下面的示例中，RoleBinding“example-rolebinding”將角色“example-role”繫結到使用者“example-user”：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-rolebinding
namespace: mynamespace
subjects:
- kind: User
name: example-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: example-role
apiGroup: rbac.authorization.k8s.io

應該注意的是，Roles 和 RoleBindings 是名稱空間的，這意味著只能為與 Role 和 RoleBinding 位於同一名稱空間的 Kubernetes 資源提供許可權。此外，毫無疑問，RoleBinding 只能引用其名稱空間中存在的角色。

Roles, ClusterRoles, RoleBindings 和 ClusterRoleBindings

在前面的示例中，我們使用了 Roles 和 RoleBindings。但是，也有可能使用 ClusterRoles 和 ClusterRoleBindings，它們在以下情況下很有用：

/healthz

Roles 和 RoleBindings 的叢集版本的定義與非叢集版本非常相似。如果我們採用前面的示例並對其進行調整，我們將具有以下定義。

ClusterRole：

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

ClusterRoleBinding:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-clusterrolebinding
subjects:
- kind: User
name: example-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: example-clusterrole
apiGroup: rbac.authorization.k8s.io

如何在 Roles 和 ClusterRoles 中啟用許可權

在第一個示例中，我們向用戶授予了獲取，觀察和列出 pod 的基本許可權。讓我們探索我們對不同資源和許可權的其他可能性。

在下面的示例中，Role 允許使用 Deployment 資源執行任何操作：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: mynamespace
name: example-role-2
rules:
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

請注意，在這種情況下，apiGroups 欄位已填入 Deployment 的 API 組。根據 Kubernetes 版本，部署資源可在 APIapps/v1 或extensions/v1beta2 中找到; API 組是斜槓之前的部分。

我們可以在角色中定義多個規則，如下例所示：

rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
resources: ["jobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

在這種情況下，我們根據目標資源是 Pod 還是 Job 授予不同的許可權。

我們還可以通過名稱來定位資源，如下例所示：

rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["my-config"]
verbs: ["get"]

如何將 Subject 繫結到 Role 或 ClusterRole

在第一個示例中，我們已經瞭解瞭如何將人類使用者繫結到角色。但是，也可以繫結服務帳戶 service account（非人類使用者）或一組人類使用者和/或服務帳戶 service account。

在下面的示例中，RoleBindingexample-rolebinding 繫結 ServiceAccountex-sto 到 Roleexample-role ：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-rolebinding
namespace: mynamespace
subjects:
- kind: ServiceAccount
name: example-sa
namespace: mynamespace
roleRef:
kind: Role
name: example-role
apiGroup: rbac.authorization.k8s.io

您可以使用以下命令建立 ServiceAccount：

kubectl create serviceaccount example-sa --namespace mynamespace

在之前的 RoleBinding 定義中，我們還可以替換 subjects 以繫結 group。在下面的示例中，我們繫結 frontend-adminsgroup：

subjects:
- kind: Group
name: "frontend-admins"
apiGroup: rbac.authorization.k8s.io

另一種可能性是繫結服務帳戶組(service account group)。在這裡，我們繫結 mynamespace 名稱空間中的所有服務帳戶(service account)：

subjects:
- kind: Group
name: system:serviceaccounts:mynamespace
apiGroup: rbac.authorization.k8s.io

或者是叢集中所有的 service account：

subjects:
- kind: Group
name: system:serviceaccounts
apiGroup: rbac.authorization.k8s.io

關於 Kubernetes 的 RBAC 的最後一件事

我們已經瞭解瞭如何使用基於角色的訪問控制模型向用戶或服務賬戶(service account)授予許可權。這是在 Kubernetes 中實現授權的有效方式，它可能是最受歡迎的方法，但它不是唯一可用的模型：您還可以使用其他模型，如 ABAC（基於屬性的訪問控制），節點授權模型和 Webhook 模式。我們將在後續文章中描述這些內容，以及 Kubernetes 中的另一個 IAM 功能：身份驗證。

Configuring Permissions in Kubernetes With RBAC