kubernetes基於角色的安全控制學習筆記

【認證和授權】

    任何資源提供使用是認證和授權是必不可少的功能，用於身份鑑別，授權是實現權限分配。

kubernetes基於插件實現這兩種功能，另外也支持准入控制，補充授權機制實現精準的訪問控制

    API SERVER做為集群的網關，所有的訪問請求都是經過它，並對每一次請求都經過驗證和權限控制。

所有檢查均正常才能訪問或者存儲數據到後端存儲系統etcd中

[用戶賬戶和用戶組]
請求有兩種類型

1    人    kubectl   rest接口    User Account 用戶賬號
    獨立於集群之外的服務管理的賬號，例如管理員分發的賬號密鑰，keystone一類的用戶存儲以及用戶名密碼
    通常用於複雜的業務邏輯控制，它作用與系統全局，因此需要全局唯一
2    pod    客戶端庫    Service Account 服務賬號
    用於k8s api管理的賬號，用於pod中的服務進程訪問k8s api提供的身份驗證
    隸屬於名稱空間，僅僅用於實現特定的操作任務。

system:unauthenticated： 未能通過任何一個授權插件檢驗的賬號，即未通過認證測試的用戶所屬的組
system:authenticated： 認證成功的用戶自動加入的組，用於快捷引用所有正常通過認證的用戶賬號
system:serviceaccount : 當前系統上所有的sa賬號組
system:serviceaccounts:： 特定名稱空間內所有的Service Account對象

api的請求要麼與普通用戶或者服務用戶綁定，要麼是匿名用戶請求
認證插件： 負責鑑定用戶身份，授權插件用於權限許可鑑別。
准入控制： 用於資源的創建、刪除、更新和連接操作時進行許可檢查。
kubernetes使用驗證機制對api的請求進行身份驗證。認證的方式：

    1    客戶端證書
    2    承載令牌
    3    身份驗證代理

以下屬性與訪問請求相關聯,至少為username和serviceaccount啟用一個驗證插件，如果驗證不通過返回401給客戶端
成功驗證後的用戶需要檢驗是否有權限操作

    1    username
    2    uid
    3    group
    4    extra

api支持的權限控制主要包含以下幾種

    1    node  基於pod的目標調度節點來實現對kubelete的訪問控制
    2    ABAC 基於屬性的訪問控制
    3    RBAC 基於角色的訪問控制
    4    webhook： 基於http回調機制通過外部rest服務就按察確認用戶授權的訪問控制
    還有兩種  AlwaysAllow和AlwaysDeny，而且自1.9版本起，External Admission Webhooks被分為MutatingAdmission-Webhook和ValidatingAdmissionWebhook兩種類型，分別用於在API中執行對象配置的變異和驗證操作

[服務賬號關聯和應用]

服務賬號就是： 用於讓pod對象內的容器進程訪問其他服務時提供的身份認證信息的賬戶，一個service account資源一般由用戶名和secret組成
創建服務賬號：serviceaccount是api servers上的一種資源，隸屬於某個名稱空間，用於pod與對象內部的應用程序在於api-server通訊時完成認證
每個pod對象均可附加其所屬名稱空間中的一個serviceaccount，且只能附加一個。不過一個service account資源可由所屬命令空間中的多個pod對象共同使

[創建服務賬號]

    kubectl  create service-account 命令進行創建，或者用聲明式讀取yaml文件進行創建
    apiVersion: v1
    kind: ServiceAccount
    metadata:
        name: sa-demo
        nameapace: default

[K8S的SSL/TLS認證]

    k8s集群的api server做為整個集群的通訊網關，contraller-manager、scheduler、kubelet以及kube-proxy均通過api server和etcd進行狀態更新和存儲，master的各組件需要ssl向外提供服務，集群內的各組件間進行通訊時還需要進行雙向認證，各節點的通訊以及與客戶端的通訊都應該以加密的方式進行身份驗證

etcd集群內的對等節點通訊： 基於tcp的2380端口進行事務通訊，對等網絡peer類型的數字證書實現通訊安全
etcd集群與客戶端的通訊： rest api基於ssl通訊，監聽2379端口,支持雙向認證。
api server與客戶端通訊基於https，有三種形式

       master： kube-schduler 和 kube-controller-manager
       node： 各kubelet和kube-proxy在啟動的時候由master節點進行數字簽名和辦法
       kubelet及其他形式的客戶端

[kubeconfig]
/etc/kubernetes/admin.conf是kubeconfig的文件，由kubeadm init自動生成。
使用kubectl config view命令可以查看當前使用配置文件路徑

[root@master .kube]# kubectl config view
apiVersion: v1
clusters:

• cluster:

  certificate-authority-data: DATA+OMITTED
  server: https://172.20.128.0:6443

  name: kubernetes

contexts:

• context:

  cluster: kubernetes
  user: kubernetes-admin

  name: kubernetes-admin@kubernetes

current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:

• name: kubernetes-admin
  user:

  client-certificate-data: REDACTED
  client-key-data: REDACTED
  

apiserver的客戶端程序 kubectl kubelet kube-controller-manager都可以基於kubeconfig配置文件接入多個集群

kubeconfig常用命令

    - kubectl config set-cluster：設置kubeconfig的clusters配置段。
    - kubectl config set-credentials：設置kubeconfig的users配置段。
    - kubectl config set-context：設置kubeconfig的contexts配置段。
    - kubectl config use-context：設置kubeconfig的current-context配置段

[TLS bootstrapping機制]

    - kubelet使用TLS bootstrap token的kubeconfig文件向kube-apiserver發送請求。
    - kubelet自行生成私鑰和簽署請求，而後發給集群上的證書籤署進程，由控制器自動完成簽署過程，即稱為k8s bootstrap 。
    - kubeadm啟動了節點加入集群時的證書自動簽署功能因此加入過程中kubeadm init命令成功後即完成。

[基於角色的訪問控制]

RBAC是一種授權的機制，用於界定誰能夠或者不能夠操作哪個或哪類資源。

    誰： useraccount  或者 serviceaccount
    操作： 要執行的具體操作，增刪改查。1.5版本引進，1.6版本為beta版本，1.8版本為穩定版

優點：

    1、對資源型和非資源型的url資源完美覆蓋
    2、整個RBAC有少數的幾個api對象實現，與其他的資源一樣可以基於kubectl和api進行操作
    3、支持進程運行時操作，不需要重啟api server即可生效

類型：

    支持Role和ClusterRole兩種類型
    Role: 支持名稱空間內的資源權限集合
    ClusterRole ： 支持集群級別的資源權限控制，一般作用於整個集群
    對這兩種資源進行賦權的時候用到RoleBinding和ClusterRoleBinding
    RoleBinding:  用於將Role許可權益綁定到一個用戶和一組用戶上
    ClusterRoleBinding:  把ClusterRole中定義的許可權限綁定在一個或一組用戶之上

【Role和RoleBinding】

除了還可以用配置清單創建Role，還可以使用命令快速創建
kubectl create role services-admin --verb="" --resource="services,services/" -n testing

RoleBinding

kubectl config use-context kube-user1@kubernetes
kubectl get pod -n testing
kubectl get service -n testing 可以看到為拒絕狀態

快速創建RoleBinding的命令
kubectl create rolebinding admin-services --role=service-admin --user=kube-user1 -n testing

【ClusterRole和ClusterRoleBinding】

ClusterRole

ClusterRole是集群級別的資源，它不屬於名稱空間，故在此處其配置不應該使用metadata.namespace字段，這也可以通過獲取nodes-reader的狀態信息來進行驗證。kube-user1用戶此前綁定的pods-reader和services-admin角色屬於名稱空間，它們無法給予此用戶訪問集群級別nodes資源的權限，所有的非名稱空間級別的資源都無法通過RoleBinding綁定至用戶並賦予用戶相關的權限，這些是屬於ClusterRoleBinding的功能。

【limitRange資源limitRange准入控制器】
未指定資源限制屬性的容器可能會因故吞掉所有工作節點上的所有可用計算資源，妥當的做法是使用limitRange資源為每個名稱空間指定最小和最大計算資源用量
在名稱空間上定義了LimitRange對象之後，客戶端提交創建或修改的資源對象將受到LimitRanger控制器的檢查，任何違反LimitRange對象定義的資源最大用量的請求將被直接拒絕。

LimitRange支持三種資源的限制：
容器 ， pod和 persistentVolumeClaim，pod和容器主要是cpu和內存的限制。persistentVolumeClaim是對存儲空間的限制範圍。

【ResourceQuota資源與准入控制器】

儘管LimitRange資源能限制單個容器、Pod及PVC等相關計算資源或存儲資源的用量，但用戶依然可以創建數量眾多的此類資源對象進而侵佔所有的系統資源。於是，Kubernetes提供了ResourceQuota資源用於定義名稱空間的對象數量或系統資源配額，它支持限制每種資源類型的對象總數，以及所有對象所能消耗的計算資源及存儲資源總量等。
用戶創建或更新資源的操作違反配額約束將導致請求失敗，APIServer以HTTP狀態代碼“403 FORBIDDEN”作為響應，並顯示一條消息以提示可能違反的約束

【PodSecurityPolicy】
是集群級別的資源類型，用於控制用戶在配置pod資源的期望狀態時可以設定的特權類的屬性
如是否可以使用特權容器，根命名空間、和主機文件系統等，以及可以使用的主機忘了和端口，卷類型和linux capabilities。