Kubernetes訪問控制之鑒權方法詳解

更新時間：2023年09月12日 11:40:00 作者：宏勢

這篇文章主要為大家介紹了Kubernetes訪問控制之鑒權方法詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

RBAC鑒權

鑒權是確定請求方有哪些資源的權限，API Server目前支持RBAC鑒權、Node鑒權、ABAC鑒權 和 Webhook模式

基于角色（Role）的訪問控制（RBAC）是一種基于組織中用戶的角色來調節(jié)控制對計算機或網(wǎng)絡資源的訪問的方法。

要啟用 RBAC，在啟動 API 服務器時將 --authorization-mode 參數(shù)設置為一個逗號分隔的列表并確保其中包含 RBAC

API對象

RBAC API 聲明了四種 Kubernetes 對象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding

Role 或 ClusterRole 中包含一組代表相關權限的規(guī)則。這些權限是純粹累加的（不存在拒絕某操作的規(guī)則）

Role 定義命名空間內權限，ClusterRole是定義跨命名空間的權限

Role定義例子如下：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default      ##如果kind是ClusterRole，無須指定，代表集群級別
  name: pod-reader
rules:
- apiGroups: [""]             #"" indicates the core API group 具體參考kubectl api-resources
  resources: ["pods"]         # 資源names, 子資源例子：["pods/log"]
  verbs: ["get", "watch", "list"]  #允許動作

如果是Role，代表能訪問default空間下的所有Pod，如果是ClusterRolo代表能訪問所有空間下的Pod

-指定固定某個資源名稱

rules:
- apiGroups: [""]
  # 在 HTTP 層面，用來訪問 ConfigMap 資源的名稱為 "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

-指定非資源端點

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURL 中的 '*' 是一個全局通配符
  verbs: ["get", "post"]

RoleBinding 將Role定義的權限授予用戶/用戶組/服務賬號（統(tǒng)稱主體subject）

ClusterRoleBinding 只能將ClusterRole定義的權限授予用戶/用戶組/服務賬號（統(tǒng)稱主體subject）
將pod-reader角色授予普通用戶myuser

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User       #支持User，Group，ServiceAccount 三種類型
  name: myuser
  apiGroup: rbac.authorization.k8s.io
roleRef:
   kind: Role
   name: pod-reader
   apiGroup: rbac.authorization.k8s.io

一個 RoleBinding 也可以引用某 ClusterRole 并將該 ClusterRole 綁定到 RoleBinding 所在的名字空間

聚合的ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # 控制面自動填充這里的規(guī)則

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# 當你創(chuàng)建 "monitoring-endpoints" ClusterRole 時，
# 下面的規(guī)則會被添加到 "monitoring" ClusterRole 中
rules:
- apiGroups: [""]
  resources: ["services", "endpointslices", "pods"]
  verbs: ["get", "list", "watch"]

名稱	類型	說明
default	ServiceAccount	每個命名空間自帶
system:anonymous	User	匿名用戶
system:serviceaccounts	Group	任務名字空間的服務賬號都屬于這個組
system:serviceaccounts:空間名字	Group	該名字空間下的服務賬號都屬于這個組
system:authenticated	Group	所有通過身份認證的用戶都屬于這個組
system:unauthenticated	Group	所有未通過身份認證的用戶都屬于這個組
system:masters	Group	超級管理員cluster-admin所屬的組

默認ClusterRole	對應默認ClusterRoleBinding	說明
cluster-admin	cluster-admin，綁定system:master組	超級管理員角色
admin	無	大多數(shù)對象進行讀/寫操作包括角色和角色綁定
edit	無	大多數(shù)對象進行讀/寫操作角色
view	無	只有訪問權限角色
system:discovery	system:discovery,綁定組 system:authenticated	允許以只讀方式訪問 API 發(fā)現(xiàn)端點

Node鑒權

節(jié)點鑒權是一種特殊用途的鑒權模式，專門對 kubelet 發(fā)出的 API 請求進行授權,通過--authorization-mode=Node 啟動API服務器開啟

為了獲得節(jié)點鑒權器的授權，kubelet 必須使用一個憑證以表示它在 system:nodes 組中，用戶名為 system:node:<nodeName>

ABAC鑒權

基于屬性的訪問控制（Attribute-based access control - ABAC）定義了訪問控制范例，其中通過使用將屬性組合在一起的策略來向用戶授予訪問權限

指定策略文件 --authorization-policy-file=SOME_FILENAME

文件內容格式JSON lines，例如：

Alice 可以對所有資源做任何事情

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}

kubelet 可以讀取任何 pod

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}

一般都是使用RBAC + Node鑒權

以上就是Kubernetes訪問控制之鑒權的詳細內容，更多關于Kubernetes訪問控制鑒權的資料請關注腳本之家其它相關文章！

您可能感興趣的文章: