Kubernetes 權限管理

kubernetes 主要經過 APIServer 對外提供服務，對於這樣的系統集羣來講，請求訪問的安全性是很是重要的考慮因素。若是不對請求加以限制，那麼會致使請求被濫用，甚至被黑客攻擊。

kubernetes 對於訪問 API 來講提供了兩個步驟的安全措施：認證和受權。認證解決用戶是誰的問題，受權解決用戶能作什麼的問題。經過合理的權限管理，可以保證系統的安全可靠。

下圖是 API 訪問要通過的三個步驟，前面兩個是認證和受權，第三個是 Admission Control，它也能在必定程度上提升安全性，不過更可能是資源管理方面的做用。

NOTE： 只有經過 HTTPS 訪問的時候纔會經過認證和受權，HTTP 不須要。

k8s-aaa.png

Authentication (認證)

All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users.

當您（真人用戶）訪問集羣（例如使用kubectl命令）時，apiserver 會將您認證爲一個特定的 User Account（目前一般是admin，除非您的系統管理員自定義了集羣配置）。Pod 容器中的進程也能夠與 apiserver 聯繫。 當它們在聯繫 apiserver 的時候，它們會被認證爲一個特定的 Service Account（例如default）。

normal users

normal users 由外部系統管理，並不禁 kubernetes 管理，kubernetesq API中也沒有關於 normal users 的定義，因此不能經過 kubernetes API 建立和管理。

service accounts

Service Account 用來訪問 kubernetes API，經過 kubernetes API 建立和管理，每一個 account 只能在一個 namespace 上生效，存儲在 kubernetes API 中的 Secrets 資源。kubernetes 會默認建立，而且會自動掛載到 Pod 中的 /run/secrets/kubernetes.io/serviceaccount 目錄下。

Authorization （受權）

RBAC（Role-Based Access Control）

要啓用RBAC，請使用--authorization-mode=RBAC啓動API Server。

RBAC 是官方纔 1.6 版本以後推薦使用的受權方式，由於它比較靈活，並且可以很好地實現資源隔離效果。

這種方法引入了一個重要的概念：Role，翻譯成角色。全部的權限都是圍繞角色進行的，也就是說角色自己會包含一系列的權限規則，代表某個角色能作哪些事情。好比管理員能夠操做全部的資源，某個 namespace 的用戶只能修改該 namespace的內容，或者有些角色只容許讀取資源。角色和 pods、services 這些資源同樣，能夠經過 API 建立和刪除，所以用戶能夠很是靈活地根據需求建立角色。

Role與ClusterRole

在RBAC API中，一個角色包含了一套表示一組權限的規則。 權限以純粹的累加形式累積（沒有」否認」的規則）。 角色能夠由命名空間（namespace）內的Role對象定義，而整個Kubernetes集羣範圍內有效的角色則經過ClusterRole對象實現。

一個Role對象只能用於授予對某一單一命名空間中資源的訪問權限。 如下示例描述了」default」命名空間中的一個Role對象的定義，用於授予對pod的讀訪問權限：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # 空字符串""代表使用core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole對象能夠授予與Role對象相同的權限，但因爲它們屬於集羣範圍對象， 也可使用它們授予對如下幾種資源的訪問權限：

• 集羣範圍資源（例如節點，即node）
• 非資源類型endpoint（例如」/healthz」）
• 跨全部命名空間的命名空間範圍資源（例如pod，須要運行命令kubectl get pods --all-namespaces來查詢集羣中全部的pod）

下面示例中的ClusterRole定義可用於授予用戶對某一特定命名空間，或者全部命名空間中的secret（取決於其綁定方式）的讀訪問權限：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # 鑑於ClusterRole是集羣範圍對象，因此這裏不須要定義"namespace"字段
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding與ClusterRoleBinding

角色綁定將一個角色中定義的各類權限授予一個或者一組用戶。 角色綁定包含了一組相關主體（即subject, 包括用戶——User、用戶組——Group、或者服務帳戶——Service Account）以及對被授予角色的引用。 在命名空間中能夠經過RoleBinding對象授予權限，而集羣範圍的權限授予則經過ClusterRoleBinding對象完成。

RoleBinding能夠引用在同一命名空間內定義的Role對象。 下面示例中定義的RoleBinding對象在」default」命名空間中將」pod-reader」角色授予用戶」jane」。 這一受權將容許用戶」jane」從」default」命名空間中讀取pod。

# 如下角色綁定定義將容許用戶"jane"從"default"命名空間中讀取pod。
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
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

參考

• kubernetes 權限管理
• Securing a Cluster

 

做者：猴子精h 連接：https://www.jianshu.com/p/e14203450bc3 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。