Kubernetes RBAC 角色權限控制

RBAC 概述與核心概念

RBAC（Role-Based Access Control，角色型存取控制）是 Kubernetes 中用於管理授權的機制。透過 RBAC，管理員可以精細控制使用者、群組或服務帳戶對 Kubernetes API 資源的存取權限。

RBAC 的核心概念包含四個主要物件：

Role：定義一組權限規則，限定於特定 Namespace
ClusterRole：定義一組權限規則，作用於整個叢集
RoleBinding：將 Role 綁定到使用者、群組或 ServiceAccount
ClusterRoleBinding：將 ClusterRole 綁定到使用者、群組或 ServiceAccount

Role 與 ClusterRole 差異

Role

Role 是 Namespace 層級的資源，只能授權存取同一 Namespace 內的資源。

1
2
3
4
5
6
7
8
9
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole

ClusterRole 是叢集層級的資源，可以授權存取：

叢集範圍的資源（如 nodes）
非資源端點（如 /healthz）
跨所有 Namespace 的資源

1
2
3
4
5
6
7
8
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding 與 ClusterRoleBinding

RoleBinding

RoleBinding 將 Role 或 ClusterRole 的權限授予特定 Namespace 內的主體。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

ClusterRoleBinding 將 ClusterRole 的權限授予整個叢集的主體。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

建立 Role 範例

以下範例建立一個可以管理 Deployment 的 Role：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: deployment-manager
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

使用 kubectl 建立：

1
kubectl apply -f deployment-manager-role.yaml

建立 RoleBinding 範例

將上述 Role 綁定到特定使用者：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: deployment-manager-binding
  namespace: development
subjects:
- kind: User
  name: developer@example.com
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: ci-bot
  namespace: development
roleRef:
  kind: Role
  name: deployment-manager
  apiGroup: rbac.authorization.k8s.io

ServiceAccount 整合

ServiceAccount 是 Kubernetes 中用於 Pod 身份識別的機制。可以透過 RBAC 授權 ServiceAccount 存取資源。

建立 ServiceAccount

1
2
3
4
5
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-service-account
  namespace: production

綁定權限到 ServiceAccount

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-configmap-reader
  namespace: production
subjects:
- kind: ServiceAccount
  name: app-service-account
  namespace: production
roleRef:
  kind: Role
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io

在 Pod 中使用 ServiceAccount

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: production
spec:
  serviceAccountName: app-service-account
  containers:
  - name: app
    image: my-app:latest

常用的內建 ClusterRole

Kubernetes 提供多個預設的 ClusterRole：

ClusterRole	說明
`cluster-admin`	超級管理員，擁有所有資源的完整權限
`admin`	可以管理 Namespace 內的大部分資源
`edit`	可以讀寫 Namespace 內的大部分資源，但不能修改 Role 或 RoleBinding
`view`	唯讀存取 Namespace 內的大部分資源，不能存取 Secret

使用內建 ClusterRole 的範例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-edit
  namespace: staging
subjects:
- kind: User
  name: developer@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

檢查權限（kubectl auth can-i）

使用 kubectl auth can-i 命令檢查權限：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 檢查目前使用者是否可以建立 Pod
kubectl auth can-i create pods

# 檢查是否可以在特定 Namespace 刪除 Deployment
kubectl auth can-i delete deployments --namespace production

# 以特定使用者身份檢查權限
kubectl auth can-i list secrets --namespace default --as jane

# 以 ServiceAccount 身份檢查權限
kubectl auth can-i get configmaps --as system:serviceaccount:default:my-sa

# 列出所有允許的操作
kubectl auth can-i --list --namespace default

最佳實踐

最小權限原則：只授予執行任務所需的最小權限，避免使用過於寬鬆的權限設定。
使用 Namespace 隔離：善用 Namespace 來隔離不同團隊或環境的資源，搭配 Role 和 RoleBinding 進行權限控制。
避免使用 cluster-admin：除非絕對必要，否則不要授予 cluster-admin 權限。
定期審查權限：定期檢視和清理不再需要的 RoleBinding 和 ClusterRoleBinding。
使用 ServiceAccount：為每個應用程式建立專屬的 ServiceAccount，而非使用預設帳戶。
限制資源動詞：根據實際需求選擇適當的動詞（verbs），避免使用萬用字元 *。
善用聚合 ClusterRole：透過標籤聚合多個 ClusterRole，簡化權限管理。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: []