1. 概述
Kubernetes 對(duì)于訪問 API 來說提供了兩個(gè)步驟的安全措施：認(rèn)證和授權(quán)氧骤。認(rèn)證解決用戶是誰的問題，授權(quán)解決用戶能做什么的問題吃引。通過合理的權(quán)限管理筹陵，能夠保證系統(tǒng)的安全可靠刽锤。
Kubernetes集群的所有操作基本上都是通過kube-apiserver這個(gè)組件進(jìn)行的，它提供HTTP RESTful形式的API供集群內(nèi)外客戶端調(diào)用惶翻。需要注意的是：認(rèn)證授權(quán)過程只存在HTTPS形式的API中姑蓝。也就是說鹅心，如果客戶端使用HTTP連接到kube-apiserver吕粗，那么是不會(huì)進(jìn)行認(rèn)證授權(quán)的。所以說旭愧，可以這么設(shè)置颅筋，在集群內(nèi)部組件間通信使用HTTP，集群外部就使用HTTPS输枯，這樣既增加了安全性议泵，也不至于太復(fù)雜。
下圖是 API 訪問要經(jīng)過的三個(gè)步驟桃熄，前面兩個(gè)是認(rèn)證和授權(quán)先口，第三個(gè)是 Admission Control，它也能在一定程度上提高安全性瞳收，不過更多是資源管理方面的作用碉京。
2. 整體結(jié)構(gòu)
安全控制認(rèn)證與授權(quán)功能主要由AuthN和AuthZ功能完成。AuthN負(fù)責(zé)用戶身份的認(rèn)證螟深，AuthZ負(fù)責(zé)根據(jù)用戶身份對(duì)其行為做權(quán)限控制谐宙。
2.1 AuthN 系統(tǒng)
2.1.1 簡(jiǎn)介
Kubernetes 的 AuthN 系統(tǒng)主要完成了以下工作:
根據(jù)配置驗(yàn)證用戶憑證，通常是 Bearer Token 或者 Basic Auth Password界弧。
解析用戶信息凡蜻，包括 Username，Groups垢箕，Uid 等划栓。這些信息將用于之后的 Authz 系統(tǒng)授權(quán)。
2.1.2 認(rèn)證模式
一般有以下幾種用戶身份認(rèn)證模式:
X509 Client Certs —— Client Certs 模式
通過傳入 --client-ca-file 到 Apiserver 開啟条获。其中證書的 /CN （common name）表示用戶名茅姜，/O （organization）表示 Groups。
Client Cert 模式通常用于某些受信任的組件訪問 Apiserver月匣，如 Kubernetes 各個(gè)組件訪問 Apiserver钻洒。-
Static Token File —— 靜態(tài) Token 文件模式
通過傳入 --token-auth-file 到 Apiserver 開啟。以下是其中一條記錄的模版锄开。HTTP 請(qǐng)求在 Header 中傳入 Authorization: Bearer Token 來認(rèn)證素标。
image.png -
Static Password File —— 靜態(tài) Password 文件模式
通過傳入 --basic-auth-file 到 Apiserver 開啟。以下是其中一條記錄的模版萍悴。HTTP 請(qǐng)求在 Header 中傳入 Authorization:Basicbase64(user:password)來認(rèn)證头遭。
image.png Service Account Tokens
Service Account Token 主要是用來給 Pod 提供訪問 Apiserver 的權(quán)限寓免。當(dāng) Pod 通過 Service Account 訪問 Apiserver 時(shí)，用戶名為 system:serviceaccount: (NAMESPACE):(SERVICEACCOUNT)计维，并且屬于system: serviceaccounts和system: serviceaccounts:(NAMESPACE) 這兩個(gè) Group袜香。當(dāng)一個(gè) Pod 使用 InClusterConfig 創(chuàng)建 Client 訪問 Apiserver 時(shí)，Client 會(huì)自動(dòng)載入 Service Account 的 Token鲫惶。OIDC Token
OIDC 是除了 WebHook 外 Kubernetes 提供的唯一一個(gè)動(dòng)態(tài)的 AuthN 方案蜈首。相比較于上面幾種方案的小打小鬧，OIDC 提供了標(biāo)準(zhǔn)的 AuthN 流程欠母，真正能夠作為 Kubernetes 系統(tǒng)用戶認(rèn)證的企業(yè)級(jí)解決方案欢策。
2.1.3 OpenID Connect Tokens 認(rèn)證
OpenID Connect 是一些由OAuth2提供商支持的OAuth2，特別是Azure Active Directory赏淌，Salesforce和Google踩寇。OAuth2的協(xié)議的主要擴(kuò)展是增加一個(gè)額外字段，返回了一個(gè)叫ID token的access token六水。這個(gè)token是被服務(wù)器簽名的JSON Web Token (JWT) 俺孙，具有眾所周知的字段，比如用戶的email掷贾。
為了識(shí)別用戶睛榄，驗(yàn)證使用來自O(shè)Auth2 token響應(yīng)的id_token (而不是 access_token)作為bearer token。token如何包含在請(qǐng)求中可以參考下圖：
使用OpenID認(rèn)證胯盯，API Server需要配置
- --oidc-issuer-url懈费，如https://accounts.google.com
- --oidc-client-id，如kubernetes
- --oidc-username-claim博脑，如sub
- --oidc-groups-claim憎乙，如groups
- --oidc-ca-file，如/etc/kubernetes/ssl/kc-ca.pem
2.1.4 Webhook Token 認(rèn)證
Webhook Token 認(rèn)證方式可以讓用戶使用自己的認(rèn)證方式叉趣，用戶只需要按照約定的請(qǐng)求格式和應(yīng)答格式提供 HTTPS 服務(wù)泞边，當(dāng)用戶把 Bearer Token 放到請(qǐng)求的頭部，kubernetes 會(huì)把 token 發(fā)送給事先配置的地址進(jìn)行認(rèn)證疗杉，如果認(rèn)證結(jié)果成功阵谚，則認(rèn)為請(qǐng)求用戶合法。 這種方式下有三個(gè)參數(shù)可以配置：
- –authentication-token-webhook-config-file ：kubeconfig 文件說明如果訪問認(rèn)證服務(wù)器
- –authentication-token-webhook-cache-ttl ：認(rèn)證結(jié)果要緩存多久烟具，默認(rèn)是兩分鐘
- --runtime-config=authentication.k8s.io/v1beta1=true梢什。
Webhook 的配置文件具體如下：
Webhook Service 需要實(shí)現(xiàn) TokenReview 的接口：
2.1.5 認(rèn)證代理
API Server需要配置
--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-
# 為了防止頭部欺騙，證書是必選項(xiàng)
--requestheader-client-ca-file
# 設(shè)置允許的CN列表朝聋∥宋纾可選。
--requestheader-allowed-names
2.1.6 Keystone Password 認(rèn)證
Keystone 是 openstack 提供的認(rèn)證和授權(quán)組件冀痕，這個(gè)方法對(duì)于已經(jīng)使用 openstack 來搭建 Iaas 平臺(tái)的公司比較適用荔睹，直接使用 keystone 可以保證 Iaas 和 Caas 平臺(tái)保持一致的用戶體系狸演。
需要API Server在啟動(dòng)時(shí)指定--experimental-keystone-url=<AuthURL>，而https時(shí)還需要設(shè)置--experimental-keystone-ca-file=SOMEFILE僻他。
2.1.7 匿名請(qǐng)求
如果請(qǐng)求沒有通過以上任何方式的認(rèn)證宵距，正常情況下應(yīng)該是直接返回 401 錯(cuò)誤。但是 kubernetes 還提供另外一種選擇吨拗，給沒有通過認(rèn)證的請(qǐng)求一個(gè)特殊的用戶名 system:anonymous 和組名 system:unauthenticated 满哪。
這樣的話，可以跟下面要講的授權(quán)結(jié)合起來丢胚，為匿名請(qǐng)求設(shè)置一些特殊的權(quán)限翩瓜，比如只能讀取當(dāng)前 namespace 的 pod 信息受扳，方便用戶訪問携龟。
如果使用AlwaysAllow以外的認(rèn)證模式，則匿名請(qǐng)求默認(rèn)開啟勘高，但可用--anonymous-auth=false禁止匿名請(qǐng)求峡蟋。
2.2 AuthZ
2.2.1 簡(jiǎn)介
Kubernetes 的 AuthZ 系統(tǒng)主要完成了以下幾件事情:
解析 HTTP 請(qǐng)求，獲取請(qǐng)求的各種屬性
根據(jù)屬性和 AuthN 獲取的用戶信息华望，依次匹配 AuthZ 規(guī)則蕊蝗，如果成功則通過，如果全部失敗則返回禁止訪問赖舟。
不同于 AuthN 方案蓬戚，AuthZ 方案在 Kubernetes 中和其 API 風(fēng)格有相當(dāng)大的關(guān)聯(lián)。由于嚴(yán)格遵循 RESTful 標(biāo)準(zhǔn)定義 API宾抓，Kubernetes 在提取 HTTP 請(qǐng)求屬性和定義 AuthZ 規(guī)則等方面有了極大的便利子漩。
下面是 Kubernetes 提供的兩種 AuthZ 方案 —— ABAC 和 RBAC。
2.2.2 ABAC
ABAC 全稱 Attribute Based Access Control（基于屬性的訪問控制）石洗。通過 --authorization-mode=ABAC 開啟幢泼，并且通過 --authorization-policy-file 指定策略文件。
以下是 ABAC 的一條記錄的例子：
可以發(fā)現(xiàn) ABAC 定義的字段基本上就是來自于上述的 Attributes 接口能夠獲取的信息讲衫。另外值得一提的是 Kubernetes 中的 ABAC 沒有動(dòng)態(tài)方案缕棵，修改策略文件后必須重啟 Apiserver。
2.2.3 RBAC
RBAC 全稱 Role Based Access Control（基于角色的訪問控制）涉兽， 通過 --authorization-mode=RBAC 開啟招驴。
目前和 RBAC 相關(guān)的 Resource 有以下 4 種：
Role
RoleBinding
ClusterRole
ClusterRoleBinding
Role 和 RoleBinding 是 NameSpace 下的資源，而 ClusterRole 和 ClusterRoleBinding 是系統(tǒng)級(jí)的資源枷畏。1.8 后 RBAC 所屬的資源已經(jīng)從 v1beta1 升級(jí)到 v1别厘。
2.2.3.1 Role
Role 的例子如下：
2.2.3.2 ClusterRole
ClusterRole 的例子如下：
ClusterRole 可以用來定義全局的 Resource。當(dāng)使用 ClusterRoleBinding 綁定時(shí)矿辽，表示能訪問所有 NameSpace 下的資源（如上述的 secrets）丹允，當(dāng)使用 RoleBinding 綁定時(shí)郭厌，表示只能訪問 RoleBinding 所屬的 NameSpace 下的資源。
2.2.3.3 RoleBinding
RoleBinding 的例子如下：
RoleBinding 負(fù)責(zé)綁定 Subjects 和某一個(gè) Role 或者 ClusterRole雕蔽。
2.2.3.4 ClusterRoleBinding
ClusterRoleBinding 的例子如下：
ClusterRoleBinding 能夠綁定 Subjects 和 ClusterRole折柠。
2.2.3.5 Subjects
Subjects 分為以下 3 種類型，Subjects 來自于 AuthN 的結(jié)果批狐。
User
Group
ServiceAccount
2.2.4 Authz 的Webhook配置
AuthZ 系統(tǒng)也可以通過 Webhook 實(shí)現(xiàn)扇售。不過比起 AuthN，AuthZ 系統(tǒng)通常沒有必要使用 Webhook嚣艇。
通過傳入
--authorization-webhook-config-file
開啟承冰，另外還要添加
--runtime-config=authorization.k8s.io/v1beta1=true。
Webhook 的配置文件如下：
Webhook Service 需要實(shí)現(xiàn) SubjectAccessReview 的接口
