一文搞懂K8s中的RBAC認證授權

概述

官方文檔：

https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authorization/
https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/

Kubernetes作為一個分布式集群的管理工具，保證集群的安全性是其一個重要的任務。所謂的安全性其實就是保證對Kubernetes的各種客戶端進行認證和鑒權操作。

在K8S中，當我們試圖通過API與集群資源交互時，必定經過集群資源管理對象入口kube-apiserver。顯然不是隨隨便便來一個請求它都歡迎的，每個請求都需要經過合規檢查，包括Authentication(身份驗證)、Authorization(授權)和Admission Control(準入控制)。通過一系列驗證后才能完成交互。

Authentication（認證）：身份鑒別，只有正確的賬號才能夠通過認證
Authorization（授權）：判斷用戶是否有權限對訪問的資源執行特定的動作
Admission Control（準入控制）：用于補充授權機制以實現更加精細的訪問控制功能。

認證賬號分類

在K8S體系中有兩種賬號類型：

User accounts（用戶賬號），即針對human user的；
Service accounts（服務賬號），即針對pod的。

這兩種賬號都可以訪問 API server，都需要經歷認證、授權、準入控制等步驟

當然，除了上面兩種之外，還有一個組的概念，這就是Group，主要是用于將用戶或服務賬號（ServiceAccount）分組，以便可以對整個組應用統一的權限策略。

認證管理方式

Kubernetes集群安全的最關鍵點在于如何識別并認證客戶端身份，它提供了3種客戶端身份認證方式：

HTTP Base認證

這種方式通過通過用戶名+密碼的方式認證。把“用戶名:密碼”用BASE64算法進行編碼后的字符串放在HTTP請求中的Header Authorization域里發送給服務端。服務端收到后進行解碼，獲取用戶名及密碼，然后進行用戶身份認證的過程。

HTTP Token認證

這種認證方式是用一個很長的難以被模仿的字符串--Token來表明客戶身份的一種方式。每個Token對應一個用戶名，當客戶端發起API調用請求時，需要在HTTP Header里放入Token，API Server接到Token后會跟服務器中保存的token進行比對，然后進行用戶身份認證的過程。

HTTPS認證（推薦！！）

基于CA根證書簽名的雙向數字證書認證方式，這種認證方式是安全性最高的一種方式，也是生產環境中最常用的一種。但是同時也是操作起來最麻煩的一種方式。

授權管理方式

授權發生在認證成功之后，通過認證就可以知道請求用戶是誰，然后Kubernetes會根據事先定義的授權策略來決定用戶是否有權限訪問，這個過程就稱為授權。

每個發送到ApiServer的請求都帶上了用戶和資源的信息：比如發送請求的用戶、請求的路徑、請求的動作等，授權就是根據這些信息和授權策略進行比較，如果符合策略，則認為授權通過，否則會返回錯誤。

API Server目前支持以下幾種授權策略：

AlwaysDeny：表示拒絕所有請求，一般用于測試
AlwaysAllow：允許接收所有請求，相當于集群不需要授權流程（Kubernetes默認的策略）
ABAC：基于屬性的訪問控制，表示使用用戶配置的授權規則對用戶請求進行匹配和控制
Webhook：通過調用外部REST服務對用戶進行授權
Node：是一種專用模式，用于對kubelet發出的請求進行訪問控制
RBAC：基于角色的訪問控制（kubeadm安裝方式下的默認選項）

RBAC介紹

RBAC(Role-Based Access Control) 基于角色的訪問控制，主要是在描述一件事情：給哪些對象授予了哪些權限
其中涉及到了下面幾個概念：

對象：User、Groups、ServiceAccount
角色：代表著一組定義在資源上的可操作動作(權限)的集合
綁定：將定義好的角色跟用戶綁定在一起

RBAC引入了4個頂級資源對象：

Role：普通角色，只能對命名空間內的資源進行授權，需要指定nameapce，可以指定一組權限
ClusterRole：集群角色，可以對集群范圍內資源、跨namespaces的范圍資源、非資源類型進行授權
RoleBinding：將 Role 中定義的權限綁定到特定命名空間內的用戶、組或服務賬戶。只能引用同一命名空間中的 Role。若需在多個命名空間使用相同權限，需為每個命名空間創建單獨的 RoleBinding。
ClusterRoleBinding：將 ClusterRole 中定義的權限綁定到集群范圍內的用戶、組或服務賬戶。

RoleBinding和ClusterRoleBinding區別

RoleBinding
將 Role 中定義的權限綁定到特定命名空間內的用戶、組或服務賬戶。
只能引用同一命名空間中的 Role。
若需在多個命名空間使用相同權限，需為每個命名空間創建單獨的 RoleBinding。

ClusterRoleBinding
將 ClusterRole 中定義的權限綁定到集群范圍內的用戶、組或服務賬戶。
綁定的 ClusterRole 可以是集群級資源（如 Nodes）或非資源型 URL（如/healthz）。
可用于授予跨命名空間的權限（如查看所有命名空間的 Pods）。

ClusterRole 與 RoleBinding 的組合
雖然 ClusterRoleBinding 只能綁定 ClusterRole，但RoleBinding 可以綁定 ClusterRole，此時權限會被限制在 RoleBinding 所在的命名空間內。

Role詳解

在 Kubernetes 中，Role 是一種用于定義命名空間（Namespace）內權限的資源對象，屬于 RBAC（基于角色的訪問控制）系統的核心組件之一。通過 Role，你可以精確控制用戶或服務賬戶對命名空間內資源的操作權限，遵循最小權限原則（Least Privilege Principle）。

定義Role資源清單

示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  # 可選，默認為當前命名空間，對應某個空間的操作權限
  namespace: default
  name: develop-role
rules:
  # 規則1：操作核心組和 apps 組的 pods、deployments，僅允許 get 和 list
- apiGroups: ["","apps"]
  resources: ["pods","deployments"]
  verbs: ["get", "list"]
  
  # 規則2：操作核心組和 apps 組的 configmaps、secrets、daemonsets，僅允許 get 和 list
- apiGroups: ["","apps"]
  resources: ["configmaps","secrets","daemonsets"]
  verbs: ["get", "list"]
  
  # 規則3：操作核心組的 secrets，允許 delete 和 create
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["delete","create"]

資源清單詳解

rules：權限規則列表，每條規則包含：

apiGroups：API 組（如 ""、apps、networking.k8s.io）。
resources：資源類型（如 pods、deployments）。
verbs：操作權限（如 get、create、delete）。
resourceNames（可選）：限定特定資源名稱（如 web-pod）。
nonResourceURLs（可選）：非資源 URL（如 /healthz，僅 ClusterRole 支持）。

apiGroups，API 組（分組標識）

作用

用于標識 Kubernetes 資源所屬的 API 分組，不同的資源屬于不同的 API 組，便于對資源進行分類管理。
Kubernetes 將核心資源（如 pods、services）歸為核心組（Core Group），非核心資源（如 deployments、daemonsets）歸為非核心組（如 apps、networking.k8s.io 等）。

取值規則：

核心組（Core Group）：
- apiGroups 取值為 [""]（空字符串），對應 Kubernetes API 中的 v1 版本資源。
- 常見資源：pods、services、configmaps、secrets、namespaces 等。
非核心組：
- apiGroups 取值為具體的組名（如 apps、batch、networking.k8s.io），對應不同 API 版本的資源。
- 常見資源：
  - apps 組：deployments、daemonsets、replicasets 等。
  - networking.k8s.io 組：ingresses、networkpolicies 等。
  - batch 組：jobs、cronjobs 等。

示例：

apiGroups: [""]：匹配核心組資源（如 pods、secrets）。
apiGroups: ["apps"]：匹配 apps 組資源（如 deployments、daemonsets）。
apiGroups: ["*"]：匹配所有 API 組（包括核心組和非核心組），需謹慎使用。集群管理員就是這一個

resources：資源類型（具體操作對象）

作用

定義允許操作的 Kubernetes 資源類型，需使用資源的完整名稱（不支持簡稱）。
資源類型需與 apiGroups 配合使用，例如：
- apiGroups: [""] + resources: ["pods"]：操作核心組的 pods 資源。
- apiGroups: ["apps"] + resources: ["deployments"]：操作 apps 組的 deployments 資源。

取值規則：

單一資源：直接填寫資源全稱（如 pods、configmaps）。
資源集合：
- 使用 * 匹配同一組下的所有資源（如 resources: ["*"]）。
- 使用 resourceName 匹配特定名稱的資源（需結合 verbs 中的 get、update 等操作）。

- apiGroups: [""]
  resources: ["pods"]
  resourceNames: ["web-pod"]  # 僅操作名為 "web-pod" 的 Pod
  verbs: ["get"]

verbs：操作權限（允許的動作）

作用

定義對指定資源允許執行的操作，用于控制用戶或服務賬戶的行為權限。

常見 verbs 分類

基礎操作：
- get：獲取單個資源，如 kubectl get pod <name>
- list：列出資源列表，如 kubectl list pods
- create：創建資源，如 kubectl create pod
- update：更新資源，如 kubectl apply 或 kubectl edit
- delete：刪除資源，如 kubectl delete pod <name>
高級操作：
- patch：部分更新資源，如 kubectl patch pod <name> -p '{"spec": {...}}'）
- watch：監控資源變化，如 kubectl get pods --watch
- exec：進入 Pod 執行命令，如 kubectl exec -it <pod> /bin/sh
- connect：建立連接，如 kubectl port-forward
特殊操作：
*：允許所有操作（需謹慎使用）。
list 和 watch 通常配合使用，用于實現資源監控（如 Dashboard 或控制器）。

示例：

verbs: ["get", "list"]：允許查看資源（獲取單個或列表）。
verbs: ["create", "delete"]：允許創建和刪除資源。
verbs: ["*"]：允許對資源執行所有操作（危險操作，僅用于測試或管理員角色）。

Role實戰

# 定義Role
[root@master ~/role]# cat role-default.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: custom-role
rules:
  # 規則1：操作核心組和 apps 組的 pods、deployments，僅允許 get 和 list
- apiGroups: ["","apps"]
  resources: ["pods","deployments"]
  verbs: ["get", "list"]

  # 規則2：操作核心組和 apps 組的 configmaps、secrets、daemonsets，僅允許 get 和 list
- apiGroups: ["","apps"]
  resources: ["configmaps","secrets","daemonsets"]
  verbs: ["get", "list"]

  # 規則3：操作核心組的 secrets，允許 delete 和 create
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["delete","create"]

# 創建Role
[root@master ~/role]# kubectl apply -f role-default.yaml
role.rbac.authorization.k8s.io/custom-role created

查看Role

# 查看Role
[root@master ~/role]# kubectl get role -o wide
NAME          CREATED AT
custom-role   2025-06-07T06:34:52Z
[root@master ~/role]# kubectl describe role custom-role
Name:         custom-role
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources         Non-Resource URLs  Resource Names  Verbs
  ---------         -----------------  --------------  -----
  secrets           []                 []              [get list delete create]
  configmaps        []                 []              [get list]
  daemonsets        []                 []              [get list]
  deployments       []                 []              [get list]
  pods              []                 []              [get list]
  configmaps.apps   []                 []              [get list]
  daemonsets.apps   []                 []              [get list]
  deployments.apps  []                 []              [get list]
  pods.apps         []                 []              [get list]
  secrets.apps      []                 []              [get list]

ClusterRole詳解

在 Kubernetes 中，ClusterRole 是一種用于定義集群級別權限的資源對象，屬于 RBAC（基于角色的訪問控制）系統的核心組件之一。與只能作用于單個命名空間的 Role 不同，ClusterRole 可以跨命名空間授權，或用于集群級資源（如節點、命名空間）的訪問控制。

核心概念

ClusterRole 是一個集群級別的資源，用于定義對集群范圍資源或非資源 URL 的操作權限。
可以用于以下場景：

對集群級資源（如 Node、PersistentVolume）的訪問控制。
對所有命名空間資源（如 Pod、Deployment）的跨命名空間訪問。
對非資源端點（如 /healthz、/metrics）的訪問控制。

ClusterRole資源清單文件

ClusterRole資源清單文件和上述Role是一致的

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <clusterrole-name>  # ClusterRole 的名稱
rules:
- apiGroups: [""]  # API 組列表
  resources: ["nodes"]  # 資源類型列表（集群級資源）
  verbs: ["get", "list", "watch"]  # 操作權限
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["*"]  # 所有操作權限
  resourceNames: ["backend"]  # 可選，限定特定資源名稱
- nonResourceURLs: ["/healthz", "/metrics"]  # 非資源 URL（僅 ClusterRole 支持）
  verbs: ["get"]

ClusterRole實戰

# 定義ClusterRole
[root@master ~/role]# cat ClusterRole-1.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-clusterrole
rules:
  # 規則1：操作核心組和 apps 組的 pods、deployments，僅允許 get 和 list
- apiGroups: ["","apps"]
  resources: ["pods","deployments"]
  verbs: ["get", "list"]

  # 規則2：操作核心組和 apps 組的 configmaps、secrets、daemonsets，僅允許 get 和 list
- apiGroups: ["","apps"]
  resources: ["configmaps","secrets","daemonsets"]
  verbs: ["get", "list"]

  # 規則3：操作核心組的 secrets，允許 delete 和 create
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["delete","create"]


# 創建Role
[root@master ~/role]# kubectl apply -f ClusterRole-1.yaml
clusterrole.rbac.authorization.k8s.io/custom-clusterrole created

查看ClusterRole

# 查看Role
[root@master ~/role]# kubectl get clusterrole custom-clusterrole
NAME                 CREATED AT
custom-clusterrole   2025-06-07T06:44:54Z

[root@master ~/role]# kubectl describe clusterrole custom-clusterrole
Name:         custom-clusterrole
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources         Non-Resource URLs  Resource Names  Verbs
  ---------         -----------------  --------------  -----
  secrets           []                 []              [get list delete create]
  configmaps        []                 []              [get list]
  daemonsets        []                 []              [get list]
  deployments       []                 []              [get list]
  pods              []                 []              [get list]
  configmaps.apps   []                 []              [get list]
  daemonsets.apps   []                 []              [get list]
  deployments.apps  []                 []              [get list]
  pods.apps         []                 []              [get list]
  secrets.apps      []                 []              [get list]

集群中默認的ClusterRole

[root@master ~/role]# kubectl get clusterrole | grep -v system
NAME                                                                   CREATED AT
admin                                                                  2025-05-24T05:57:58Z
calico-cni-plugin                                                      2025-05-24T05:58:41Z
calico-crds                                                            2025-05-24T05:59:30Z
calico-extension-apiserver-auth-access                                 2025-05-24T05:59:30Z
calico-kube-controllers                                                2025-05-24T05:58:41Z
calico-node                                                            2025-05-24T05:58:41Z
calico-typha                                                           2025-05-24T05:58:40Z
calico-webhook-reader                                                  2025-05-24T05:59:30Z
cluster-admin                                                          2025-05-24T05:57:57Z
custom-clusterrole                                                     2025-06-07T06:44:54Z
edit                                                                   2025-05-24T05:57:58Z
kubeadm:get-nodes                                                      2025-05-24T05:57:59Z
tigera-operator                                                        2025-05-24T05:58:37Z
view                                                                   2025-05-24T05:57:58Z

其中主要關注這四個

admin:主要用于授權命名空間的讀寫權限
cluster-admin:超級管理員，擁有集群的所有權限
edit:允許對大多數對象讀寫操作，不允許查看或者修改角色，角色綁定。
view:允許對命名空間大多數對象只讀權限，不允許查看角色，角色綁定和secret

RoleBinding詳解

在 Kubernetes（K8s）中，RoleBinding 是實現權限控制（RBAC，Role-Based Access Control）的核心資源之一，用于將角色（Role）與用戶、服務賬戶或組關聯起來，從而賦予其對特定資源的操作權限。

RoleBinding 僅在單個命名空間內生效，用于授予對命名空間內資源的訪問權限（如 Pod、Service 等）。

若需跨命名空間或集群級權限（如管理節點、命名空間本身），需使用 ClusterRoleBinding（關聯 ClusterRole）。

作用

將 Role（角色）定義的權限授予主體（Subjects），主體可以是：

用戶賬戶（User Accounts）：K8s 中的外部用戶（如管理員、開發人員），通常通過認證插件（如 X509、OIDC）管理。
服務賬戶（Service Accounts）：K8s 內部用于 Pod 中容器訪問 API 的賬戶，自動創建于命名空間中。
組（Groups）：用戶組（如通過認證插件定義的組），用于批量授權。

RoleBinding資源清單文件

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-rolebinding  # RoleBinding 名稱
  namespace: dev-namespace   # 作用的命名空間
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role         # 引用的角色類型（必須是 Role 或 ClusterRole）
  name: developer    # 引用的角色名稱
subjects:          # 被授權的主體列表
- kind: User        # 主體類型（User/ServiceAccount/Group）
  name: alice       # 主體名稱
  apiGroup: ""      # User 和 Group 的 apiGroup 為空
- kind: ServiceAccount
  name: my-app-sa
  namespace: dev-namespace  # 服務賬戶所在的命名空間（若與 RoleBinding 同命名空間可省略）
- kind: Group
  name: my-group            # 組名
  apiGroup: ""

字段說明

metadata
- namespace：必填，指定 RoleBinding 生效的命名空間。
- name：RoleBinding 的唯一名稱。
roleRef：引用要綁定的角色，支持兩種類型：
- Role：命名空間內的角色，授予對該命名空間內資源的權限。
- ClusterRole：集群級角色，可通過 RoleBinding 綁定到命名空間，授予該命名空間內資源的權限（需角色定義中包含命名空間作用域的規則）。
subjects：定義被授權的主體，每個主體包含：
- kind：主體類型，取值為 User、ServiceAccount 或 Group。
- name：主體名稱（如用戶名、服務賬戶名、組名）。
- namespace：僅當主體為服務賬戶且與 RoleBinding 不在同一命名空間時需指定。

RoleBinding與ClusterRole

雖然 RoleBinding 通常綁定 Role，但也可以綁定 ClusterRole，前提是該 ClusterRole 的規則適用于命名空間內的資源。例如：

# 使用 ClusterRole 定義命名空間內權限
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]
  resourceNames: []  # 不限制具體資源名稱，作用于整個命名空間

# 通過 RoleBinding 將 ClusterRole 綁定到命名空間
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: clusterrole-binding
  namespace: dev-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole  # 引用集群級角色
  name: namespace-pod-reader
subjects:
- kind: User
  name: charlie
  apiGroup: ""

ClusterRoleBinding詳解

在 Kubernetes（K8s）中，ClusterRoleBinding 是實現集群級權限控制的核心資源，用于將集群級角色（ClusterRole）與用戶、服務賬戶或組關聯，從而賦予其跨命名空間或集群級資源的訪問權限。

ClusterRoleBinding 不局限于單個命名空間，而是對整個集群生，可用于授權對集群級資源（如 Nodes、Namespaces、PersistentVolumes）或所有命名空間資源（如所有 Pod、ConfigMaps）的訪問。

作用

將 ClusterRole 定義的權限授予主體（Subjects），主體可以是：

用戶賬戶（User Accounts）：K8s 中的外部用戶（如集群管理員）。
服務賬戶（Service Accounts）：K8s 內部用于 Pod 中容器訪問 API 的賬戶。
組（Groups）：用戶組（如通過認證插件定義的組）。

ClusterRoleBinding資源清單文件

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding  # ClusterRoleBinding 名稱
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole  # 必須是 ClusterRole
  name: cluster-admin  # 引用的 ClusterRole 名稱
subjects:
- kind: User        # 主體類型
  name: admin-user  # 用戶名
  apiGroup: ""
- kind: Group
  name: system:serviceaccounts  # 所有服務賬戶所在的組
  apiGroup: ""

字段說明

metadata
- name：ClusterRoleBinding 的唯一名稱（集群級別）。
roleRef
- 引用要綁定的集群角色，必須是 ClusterRole，不能是普通 Role。
- ClusterRole 可以是：
  - 集群級資源權限（如管理節點、命名空間）。
  - 所有命名空間資源的權限（如查看所有命名空間中的 Pod）。
  - 非資源端點權限（如 /healthz、/metrics）。
subjects
- 定義被授權的主體，結構與 RoleBinding 相同，但服務賬戶需指定命名空間（若有）。

Role和ClusterRole的區別

特性	Role	ClusterRole
作用范圍	單個命名空間內	集群范圍（所有命名空間或集群級資源）
定義位置	屬于命名空間資源（需指定 namespace）	集群級資源（無需 namespace 字段）
可授權的資源類型	命名空間內資源（如 Pod、Service）	1. 集群級資源（如 Nodes、Namespaces） 2. 所有命名空間的資源（如所有 Pod） 3. 非資源端點（如 /healthz、/metrics）
綁定方式	通過 RoleBinding 綁定到主體	1. 通過 RoleBinding 綁定到單個命名空間（需角色規則適用于命名空間資源） 2. 通過 ClusterRoleBinding 綁定到整個集群
典型場景	授權命名空間內的操作（如開發人員管理自己命名空間的資源）	1. 集群管理員權限 2. 跨命名空間操作 3. 訪問集群級資源

RoleBinding和ClusterRoleBinding的區別

特性	RoleBinding	ClusterRoleBinding
作用范圍	單個命名空間內	集群范圍（所有命名空間或集群級資源）
綁定的角色類型	1. Role（命名空間內角色） 2. ClusterRole（需角色規則適用于命名空間資源）	僅 ClusterRole（集群級角色）
定義位置	屬于命名空間資源（需指定 namespace）	集群級資源（無需 namespace 字段）
典型場景	授權用戶/服務賬戶操作特定命名空間內的資源（如開發人員管理 dev 命名空間的 Pod）	1. 集群管理員權限 2. 跨命名空間操作 3. 訪問集群級資源（如 Nodes）

posted @ 2025-06-08 12:57 huangSir-devops 閱讀(359) 評論(0) 收藏舉報

刷新頁面返回頂部

作者：你的名字

出處：你的博客鏈接

本文版權歸作者和博客園共有，歡迎轉載，但必須給出原文鏈接，并保留此段聲明，否則保留追究法律責任的權利。

huangSir-devops

一文搞懂K8s中的RBAC認證授權

概述

認證賬號分類

認證管理方式

HTTP Base認證

HTTP Token認證

HTTPS認證（推薦！！）

授權管理方式

RBAC介紹

Role詳解

定義Role資源清單

資源清單詳解

rules：權限規則列表，每條規則包含：

apiGroups，API 組（分組標識）

resources：資源類型（具體操作對象）

verbs：操作權限（允許的動作）

Role實戰

ClusterRole詳解

核心概念

ClusterRole資源清單文件

ClusterRole實戰

集群中默認的ClusterRole

RoleBinding詳解

作用

RoleBinding資源清單文件

字段說明

RoleBinding與ClusterRole

ClusterRoleBinding詳解

作用

ClusterRoleBinding資源清單文件

字段說明

Role和ClusterRole的區別

RoleBinding和ClusterRoleBinding的區別

公告