k8s叢集安裝學習筆記七
阿新 • • 發佈：2021-09-29
Kubernetes叢集安全
機制說明
Kubernetes 作為一個分散式叢集的管理工具，保證叢集的安全性是其一個重要的任務。 API Server 是叢集內部各個元件通訊的中介，也是外部控制的入口。所以 Kubernetes 的安全機制基本就是圍繞保護 API Server 來設計的。 Kubernetes 使用了認證（Authentication）、鑑權（Authorization）、准入控制（AdmissionControl）三步來保證API Server的安全。Authentication
>HTTP Token 認證：通過一個 Token 來識別合法使用者 HTTP Token 的認證是用一個很長的特殊編碼方式的並且難以被模仿的字串 - Token 來表達客戶的一Ⅰ、HTTPS 證書認證：
Ⅱ、需要認證的節點
兩種型別 Kubenetes 元件對 API Server 的訪問：kubectl、Controller Manager、Scheduler、kubelet、kube-proxy。 Kubernetes 管理的 Pod 對容器的訪問：Pod（dashborad 也是以 Pod 形式執行）。 安全性說明 Controller Manager、Scheduler 與 API Server 在同一臺機器，所以直接使用 API Server 的非安全埠訪問， --insecure-bind-address=127.0.0.1 。 kubectl、kubelet、kube-proxy 訪問 API Server 就都需要證書進行 HTTPS 雙向認證。kubectl get secret --all-namespaces預設情況下，每個 namespace 都會有一個 ServiceAccount，如果 Pod 在建立時沒有指定 ServiceAccount， 就會使用 Pod 所屬的 namespace 的 ServiceAccount
kubectl describe secret default-token-5gm9r --namespace=kube-system
總結
Authorization
上面認證過程，只是確認通訊的雙方都確認了對方是可信的，可以相互通訊。而鑑權是確定請求方有哪些資源的權限。 API Server 目前支援以下幾種授權策略 （通過 API Server 的啟動引數 “--authorization-mode” 設定）。 AlwaysDeny：表示拒絕所有的請求，一般用於測試。 AlwaysAllow：允許接收所有請求，如果叢集不需要授權流程，則可以採用該策略。 ABAC（Attribute-Based Access Control）：基於屬性的訪問控制，表示使用使用者配置的授權規則對使用者請求進行匹配和控制。 Webbook：通過呼叫外部 REST 服務對使用者進行授權。 RBAC（Role-Based Access Control）：基於角色的訪問控制，現行預設規則 。 RBAC 授權模式 RBAC（Role-Based Access Control）基於角色的訪問控制，在 Kubernetes 1.5 中引入，現行版本成為預設標準。 相對其它訪問控制方式，擁有以下優勢： 對叢集中的資源和非資源均擁有完整的覆蓋。 整個 RBAC 完全由幾個 API 物件完成，同其它 API 物件一樣，可以用 kubectl 或 API 進行操作。 可以在執行時進行調整，無需重啟 API Server 。 Ⅰ、RBAC 的 API 資源物件說明 RBAC 引入了 4 個新的頂級資源物件：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4 種物件型別均可以通過 kubectl 與 API 操作。 需要注意的是 Kubenetes 並不會提供使用者管理，那麼 User、Group、ServiceAccount 指定的使用者又是從哪裡來的呢？ Kubenetes 元件（kubectl、kube-proxy）或是其他自定義的使用者在向 CA 申請證書時，需要提供一個證書請求檔案。{
"CN": "admin",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "HangZhou",
"L": "XS",
"O": "system:masters",
"OU": "System"
}
]
}
API Server會把客戶端證書的 CN 欄位作為User，把 names.O 欄位作為Group，
kubelet 使用 TLS Bootstaping 認證時，API Server 可以使用 Bootstrap Tokens 或者 Token authenticationfile 驗證 =token，
無論哪一種，Kubenetes 都會為 token 繫結一個預設的 User 和 Group ，
Pod使用 ServiceAccount 認證時，service-account-token 中的 JWT 會儲存 User 資訊，
有了使用者資訊，再建立一對角色/角色繫結(叢集角色/叢集角色繫結)資源物件，就可以完成許可權綁定了。
Role and ClusterRole
在 RBAC API 中，Role 表示一組規則許可權，許可權只會增加(累加許可權)，不存在一個資源一開始就有很多許可權而通過RBAC 對其進行減少的操作； Role 可以定義在一個 namespace 中，如果想要跨 namespace 則可以建立ClusterRole。kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]ClusterRole 具有與 Role 相同的許可權角色控制能力，不同的是 ClusterRole 是叢集級別的，ClusterRole 可以用於: 叢集級別的資源控制( 例如 node 訪問許可權 ) 非資源型 endpoints( 例如 /healthz 訪問 ) 所有名稱空間資源控制(例如 pods )
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: # "namespace" omitted since ClusterRoles are not namespaced name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]好記性不如爛筆頭，最難不過堅持