1.訪問控制概述

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

客戶端

在Kubernetes集群中，客戶端通常有兩類：

• User Account：一般是獨立于kubernetes之外的其他服務管理的用戶賬號薪捍。
• Service Account：kubernetes管理的賬號币他，用于為Pod中的服務進程在訪問Kubernetes時提供身份標識尔当。

image.png

認證莲祸、授權(quán)與準入控制

ApiServer是訪問及管理資源對象的唯一入口。任何一個請求訪問ApiServer椭迎，都要經(jīng)過下面三個流程：

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

image.png

2 認證管理

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

• HTTP Base認證：通過用戶名+密碼的方式認證

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

• HTTP Token認證：通過一個Token來識別合法用戶

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

• HTTPS證書認證：基于CA根證書簽名的雙向數(shù)字證書認證方式

這種認證方式是安全性最高的一種方式艺配，但是同時也是操作起來最麻煩的一種方式。

image.png

HTTPS認證大體分為3個過程：

1.證書申請和下發(fā)

HTTPS通信雙方的服務器向CA機構(gòu)申請證書惋砂，CA機構(gòu)下發(fā)根證書、服務端證書及私鑰給申請者

2.客戶端和服務端的雙向認證

1> 客戶端向服務器端發(fā)起請求绳锅，服務端下發(fā)自己的證書給客戶端西饵，
   客戶端接收到證書后，通過私鑰解密證書鳞芙，在證書中獲得服務端的公鑰眷柔，
   客戶端利用服務器端的公鑰認證證書中的信息，如果一致原朝，則認可這個服務器
2> 客戶端發(fā)送自己的證書給服務器端驯嘱，服務端接收到證書后，通過私鑰解密證書喳坠，
   在證書中獲得客戶端的公鑰鞠评，并用該公鑰認證證書信息，確認客戶端是否合法

3.服務器端和客戶端進行通信

服務器端和客戶端協(xié)商好加密方案后壕鹉，客戶端會產(chǎn)生一個隨機的秘鑰并加密剃幌，然后發(fā)送到服務器端。
服務器端接收這個秘鑰后晾浴，雙方接下來通信的所有內(nèi)容都通過該隨機秘鑰加密

注意: Kubernetes允許同時配置多種認證方式负乡，只要其中任意一個方式認證通過即可

3.授權(quán)管理

授權(quán)發(fā)生在認證成功之后，通過認證就可以知道請求用戶是誰脊凰， 然后Kubernetes會根據(jù)事先定義的授權(quán)策略來決定用戶是否有權(quán)限訪問抖棘，這個過程就稱為授權(quán)。

每個發(fā)送到ApiServer的請求都帶上了用戶和資源的信息：比如發(fā)送請求的用戶狸涌、請求的路徑切省、請求的動作等，授權(quán)就是根據(jù)這些信息和授權(quán)策略進行比較帕胆，如果符合策略数尿，則認為授權(quán)通過，否則會返回錯誤惶楼。

API Server目前支持以下幾種授權(quán)策略：

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

RBAC(Role-Based Access Control) 基于角色的訪問控制晨汹，主要是在描述一件事情：給哪些對象授予了哪些權(quán)限

其中涉及到了下面幾個概念：

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

image.png

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

• Role淘这、ClusterRole：角色，用于指定一組權(quán)限
• RoleBinding巩剖、ClusterRoleBinding：角色綁定铝穷，用于將角色（權(quán)限）賦予給對象

Role、ClusterRole

一個角色就是一組權(quán)限的集合佳魔，這里的權(quán)限都是許可形式的（白名單）曙聂。

# Role只能對命名空間內(nèi)的資源進行授權(quán)，需要指定nameapce
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: dev
  name: authorization-role
rules:
- apiGroups: [""]  # 支持的API組列表,"" 空字符串鞠鲜，表示核心API群
  resources: ["pods"] # 支持的資源對象列表
  verbs: ["get", "watch", "list"] # 允許的對資源對象的操作方法列表

# ClusterRole可以對集群范圍內(nèi)資源宁脊、跨namespaces的范圍資源、非資源類型進行授權(quán)
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: authorization-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

需要詳細說明的是贤姆，rules中的參數(shù)：

• apiGroups: 支持的API組列表

"","apps", "autoscaling", "batch"

• resources：支持的資源對象列表

"services", "endpoints", "pods","secrets","configmaps","crontabs","deployments","jobs",
"nodes","rolebindings","clusterroles","daemonsets","replicasets","statefulsets",
"horizontalpodautoscalers","replicationcontrollers","cronjobs"

• verbs：對資源對象的操作方法列表

"get", "list", "watch", "create", "update", "patch", "delete", "exec"

RoleBinding榆苞、ClusterRoleBinding

角色綁定用來把一個角色綁定到一個目標對象上，綁定目標可以是User霞捡、Group或者ServiceAccount坐漏。

# RoleBinding可以將同一namespace中的subject綁定到某個Role下，則此subject即具有該Role定義的權(quán)限
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding
  namespace: dev
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: authorization-role
  apiGroup: rbac.authorization.k8s.io

# ClusterRoleBinding在整個集群級別和所有namespaces將特定的subject與ClusterRole綁定碧信，授予權(quán)限
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: authorization-clusterrole-binding
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

RoleBinding引用ClusterRole進行授權(quán)

RoleBinding可以引用ClusterRole仙畦，對屬于同一命名空間內(nèi)ClusterRole定義的資源主體進行授權(quán)。

一種很常用的做法就是音婶，集群管理員為集群范圍預定義好一組角色（ClusterRole）慨畸，
然后在多個命名空間中重復使用這些ClusterRole。
這樣可以大幅提高授權(quán)管理工作效率衣式，也使得各個命名空間下的基礎性授權(quán)規(guī)則與使用體驗保持一致寸士。

# 雖然authorization-clusterrole是一個集群角色，但是因為使用了RoleBinding
# 所以heima只能讀取dev命名空間中的資源
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding-ns
  namespace: dev
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

實戰(zhàn)：創(chuàng)建一個只能管理dev空間下Pods資源的賬號

1.創(chuàng)建賬號

# 1) 創(chuàng)建證書
[root@k8s-master01 pki]# cd /etc/kubernetes/pki/
[root@k8s-master01 pki]# (umask 077;openssl genrsa -out devman.key 2048)

# 2) 用apiserver的證書去簽署
# 2-1) 簽名申請碴卧，申請的用戶是devman,組是devgroup
[root@k8s-master01 pki]# openssl req -new -key devman.key -out devman.csr -subj "/CN=devman/O=devgroup"     
# 2-2) 簽署證書
[root@k8s-master01 pki]# openssl x509 -req -in devman.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out devman.crt -days 3650

# 3) 設置集群弱卡、用戶、上下文信息
[root@k8s-master01 pki]# kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.109.100:6443

[root@k8s-master01 pki]# kubectl config set-credentials devman --embed-certs=true --client-certificate=/etc/kubernetes/pki/devman.crt --client-key=/etc/kubernetes/pki/devman.key

[root@k8s-master01 pki]# kubectl config set-context devman@kubernetes --cluster=kubernetes --user=devman

# 切換賬戶到devman
[root@k8s-master01 pki]# kubectl config use-context devman@kubernetes
Switched to context "devman@kubernetes".

# 查看dev下pod住册，發(fā)現(xiàn)沒有權(quán)限
[root@k8s-master01 pki]# kubectl get pods -n dev
Error from server (Forbidden): pods is forbidden: User "devman" cannot list resource "pods" in API group "" in the namespace "dev"

# 切換到admin賬戶
[root@k8s-master01 pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

2.創(chuàng)建Role和RoleBinding婶博，為devman用戶授權(quán)

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: dev
  name: dev-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  
---

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding
  namespace: dev
subjects:
- kind: User
  name: devman
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io

[root@k8s-master01 pki]# kubectl create -f dev-role.yaml
role.rbac.authorization.k8s.io/dev-role created
rolebinding.rbac.authorization.k8s.io/authorization-role-binding created

3.切換賬戶，再次驗證

# 切換賬戶到devman
[root@k8s-master01 pki]# kubectl config use-context devman@kubernetes
Switched to context "devman@kubernetes".

# 再次查看
[root@k8s-master01 pki]# kubectl get pods -n dev
NAME                                 READY   STATUS             RESTARTS   AGE
nginx-deployment-66cb59b984-8wp2k    1/1     Running            0          4d1h
nginx-deployment-66cb59b984-dc46j    1/1     Running            0          4d1h
nginx-deployment-66cb59b984-thfck    1/1     Running            0          4d1h

# 為了不影響后面的學習,切回admin賬戶
[root@k8s-master01 pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

4.準入控制
通過了前面的認證和授權(quán)之后荧飞，還需要經(jīng)過準入控制處理通過之后凡人，apiserver才會處理這個請求名党。

準入控制是一個可配置的控制器列表，可以通過在Api-Server上通過命令行設置選擇執(zhí)行哪些準入控制器：

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,
                      DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

只有當所有的準入控制器都檢查通過之后挠轴，apiserver才執(zhí)行該請求传睹，否則返回拒絕。

當前可配置的Admission Control準入控制如下：

• AlwaysAdmit：允許所有請求
• AlwaysDeny：禁止所有請求岸晦，一般用于測試
• AlwaysPullImages：在啟動容器之前總?cè)ハ螺d鏡像
• DenyExecOnPrivileged：它會攔截所有想在Privileged Container上執(zhí)行命令的請求
• ImagePolicyWebhook：這個插件將允許后端的一個Webhook程序來完成admission controller的功能欧啤。
• Service Account：實現(xiàn)ServiceAccount實現(xiàn)了自動化
• SecurityContextDeny：這個插件將使用SecurityContext的Pod中的定義全部失效
• ResourceQuota：用于資源配額管理目的，觀察所有請求启上，確保在namespace上的配額不會超標
• LimitRanger：用于資源限制管理邢隧，作用于namespace上，確保對Pod進行資源限制
• InitialResources：為未設置資源請求與限制的Pod冈在，根據(jù)其鏡像的歷史資源的使用情況進行設置
• NamespaceLifecycle：如果嘗試在一個不存在的namespace中創(chuàng)建資源對象倒慧，則該創(chuàng)建請求將被拒絕。當刪除一個namespace時讥邻，系統(tǒng)將會刪除該namespace中所有對象迫靖。
• DefaultStorageClass：為了實現(xiàn)共享存儲的動態(tài)供應院峡，為未指定StorageClass或PV的PVC嘗試匹配默認的StorageClass兴使，盡可能減少用戶在申請PVC時所需了解的后端存儲細節(jié)
• DefaultTolerationSeconds：這個插件為那些沒有設置forgiveness tolerations并具有notready:NoExecute和unreachable:NoExecute兩種taints的Pod設置默認的“容忍”時間，為5min
• PodSecurityPolicy：這個插件用于在創(chuàng)建或修改Pod時決定是否根據(jù)Pod的security context和可用的PodSecurityPolicy對Pod的安全策略進行控制