kube-apiserver 參數(shù)

kube-apiserver對(duì)外暴露了Kubernetes API。它是的 Kubernetes 前端控制層。

參數(shù)分類解釋

審計(jì)參數(shù)：

詳見(jiàn)： https://kubernetes.io/docs/tasks/debug-application-cluster/audit/

• 審計(jì)提供了一組與安全相關(guān)的按時(shí)間順序排列的記錄，記錄了各個(gè)用戶，管理員或系統(tǒng)其他組件影響系統(tǒng)的活動(dòng)順序。
• 每個(gè)請(qǐng)求在每個(gè)階段都會(huì)生成一個(gè)事件，然后根據(jù)某個(gè)策略對(duì)其進(jìn)行預(yù)處理并寫入后端。策略確定記錄的內(nèi)容，后端保留記錄。
• 審計(jì)后端將審計(jì)事件持久保存到外部存儲(chǔ)。
• Kube-apiserver提供三個(gè)后端：記錄后端，將事件寫入磁盤;Webhook后端，它將事件發(fā)送到外部API;動(dòng)態(tài)后端，通過(guò)AuditSink API對(duì)象配置webhook后端。
• 每個(gè)請(qǐng)求都可以用相關(guān)的“階段”記錄。
  1、RequestReceived ：審計(jì)處理程序收到請(qǐng)求后立即生成的事件的階段，以及在處理程序鏈下委托之前生成事件的階段。
  2、ResponseStarted：一旦發(fā)送響應(yīng)頭，但在發(fā)送響應(yīng)主體之前。此階段僅針對(duì)長(zhǎng)時(shí)間運(yùn)行的請(qǐng)求（例如監(jiān)視）生成。
  3、ResponseComplete： 響應(yīng)正文已完成，不再發(fā)送字節(jié)。
  4、Panic：發(fā)生異常時(shí)產(chǎn)生的事件。

審核日志記錄功能會(huì)增加API服務(wù)器的內(nèi)存消耗，因?yàn)闉槊總€(gè)請(qǐng)求存儲(chǔ)了審核所需的某些上下文。此外，內(nèi)存消耗取決于審計(jì)日志記錄配置。

認(rèn)證參數(shù)：

詳見(jiàn) https://kubernetes.io/docs/reference/access-authn-authz/authentication/

• 建立TLS后，HTTP請(qǐng)求將移至“身份驗(yàn)證”步驟。認(rèn)證器的輸入是整個(gè)HTTP請(qǐng)求，認(rèn)證步驟通常只檢查 headers 或客戶端證書。
• 身份驗(yàn)證模塊包括客戶端證書，密碼和普通token，bootstrap token和 JWT token（用于 service accounts）。
• 當(dāng)啟用了多個(gè)認(rèn)證模塊時(shí)，一個(gè)認(rèn)證模塊成功認(rèn)證后將短路請(qǐng)求，不會(huì)進(jìn)行剩余模塊的認(rèn)證。API server 不能保證認(rèn)證的順序。
• 如果請(qǐng)求無(wú)法通過(guò)身份驗(yàn)證，則會(huì)被HTTP狀態(tài)碼 401 拒絕。
• 如果請(qǐng)求通過(guò)身份驗(yàn)證，插件會(huì)嘗試將以下屬性關(guān)聯(lián)到請(qǐng)求上：
  1、用戶名：標(biāo)識(shí)最終用戶的字符串。常用值可能是 kube-admin 或 jane@example.com。
  2、UID：標(biāo)識(shí)最終用戶的字符串，比用戶名更加一致且唯一。
  3、組：一組將用戶和常規(guī)用戶組相關(guān)聯(lián)的字符串。system:authenticated 組包含在所有已驗(yàn)證用戶的組列表中。
  4、額外字段：包含其他有用認(rèn)證信息的字符串列表的映射。
• Kubernetes usernames 用于訪問(wèn)控制決策和日志記錄，但它不是 user 對(duì)象，也不會(huì)在其對(duì)象庫(kù)中存儲(chǔ)用戶名或有關(guān)用戶的其他信息。

認(rèn)證器分類：

（1）509 客戶端證書：
啟用方法：--client-ca-file=SOMEFILE

驗(yàn)證方法：引用的文件必須包含一個(gè)或多個(gè)證書頒發(fā)機(jī)構(gòu)，用于驗(yàn)證提交給 API server 的客戶端證書。

驗(yàn)證后：使用 subject 的 Common Name（CN）作為請(qǐng)求的用戶名。客戶端證書還可以使用證書的 organization 字段來(lái)指示用戶的組成員身份。

（2）靜態(tài) Token 文件：
啟用方法：--token-auth-file=SOMEFILE 。(token 文件是一個(gè) csv 文件，每行至少包含三列：token、用戶名、用戶 uid，其次是可選的組名。token 會(huì)無(wú)限期地持續(xù)下去，并且不重新啟動(dòng) API server 的話就無(wú)法更改token列表。)

驗(yàn)證方法：
API server 從文件讀取 bearer token，期望請(qǐng)求的 Authorization header 中包含 Bearer token 的值。

（3）Bootstrap Token Authenticator：
啟用方法： --enable-bootstrap-token-auth;Controller Manager 的 --controllers 參數(shù)啟用 TokenCleaner 。

驗(yàn)證方法：Kubernetes 中包含了一個(gè)名為 Bootstrap Token 的動(dòng)態(tài)管理的 bearer token。這些 token 使用 Secret 存儲(chǔ)在 kube-system namespace 中，在那里它們可以被動(dòng)態(tài)管理和創(chuàng)建。Controller Manager 中包含了 TokenCleaner 控制器，用于在 bootstrap token 過(guò)期時(shí)將其刪除。這些 token 的形式是 [a-z0-9]{6}.[a-z0-9]{16}。第一部分是 Token ID，第二部分是 Token Secret。

驗(yàn)證后：請(qǐng)求將被認(rèn)證為 system:bootstrap:<Token ID> 。被包含在 system:bootstrappers 組中。
詳細(xì)可參考
https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/

(4)靜態(tài)密碼文件
啟用方法：--basic-auth-file=SOMEFILE。基本身份驗(yàn)證憑證將無(wú)限期地保留，不重啟API服務(wù)器無(wú)法更改密碼。目前僅支持基本身份驗(yàn)證。基本身份認(rèn)證是一個(gè) csv 文件，至少包含3列：密碼、用戶名、用戶 ID、組名（可選）。

驗(yàn)證方法：需要Authorization header 中包含 Basic BASE64ENCODED(USER:PASSWORD) 的值。

(5)Service Account Token
Service account 是一個(gè)自動(dòng)啟用的驗(yàn)證器，它使用簽名的 bearer token 來(lái)驗(yàn)證請(qǐng)求。該插件包括兩個(gè)可選參數(shù)：

• --service-account-key-file 一個(gè)包含簽名 bearer token 的 PEM 編碼文件。如果未指定，將使用 API server 的 TLS 私鑰。
• service-account-lookup 如果啟用，從 API 中刪除掉的 token 將被撤銷。
  Service account 通常由 API server 自動(dòng)創(chuàng)建，并通過(guò) ServiceAccount 注入控制器，關(guān)聯(lián)到集群中運(yùn)行的 Pod 上。Bearer token 掛載到 pod 中，并允許集群進(jìn)程與 API server 通信。 帳戶可以使用 PodSpec 的 serviceAccountName 字段顯式地與Pod關(guān)聯(lián)。

# 使用 kubectl create serviceaccount (NAME) 命令。這將在當(dāng)前的 namespace 和相關(guān)連的 secret 中創(chuàng)建一個(gè) service account。
$ kubectl create serviceaccount jenkins
# 創(chuàng)建出的 secret 中擁有 API server 的公共 CA 和前面的 JSON Web Token（JWT），secret 基于 base64 編碼。
$ kubectl get secret jenkins-token-1yvwg -o yaml
apiVersion: v1
data:
  ca.crt: (APISERVER'S CA BASE64 ENCODED)
  namespace: ZGVmYXVsdA==
  token: (BEARER TOKEN BASE64 ENCODED)
kind: Secret
metadata:
  # ...
type: kubernetes.io/service-account-token

經(jīng)過(guò)簽名的 JWT 可以用作 bearer token 與給定的 service account 進(jìn)行身份驗(yàn)證，在請(qǐng)求中放置 bearer token。

驗(yàn)證后：用戶名 system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)，組 system:serviceaccounts 和 system:serviceaccounts:(NAMESPACE)。

(6)OpenID Connect Token
OpenID Connect 是由 OAuth2 供應(yīng)商提供的 OAuth2，特別是 Azure Active Directory、Salesforce 和 Google。
https://jimmysong.io/kubernetes-handbook/guide/authentication.html#openid-connect-token

(7)Webhook Token 認(rèn)證
Webhook 認(rèn)證是用來(lái)認(rèn)證 bearer token 的 hook。
https://jimmysong.io/kubernetes-handbook/guide/authentication.html#webhook-token-%E8%AE%A4%E8%AF%81

(8)認(rèn)證代理
可以配置 API server 從請(qǐng)求 header 的值中識(shí)別用戶，例如 X-Remote-User。這樣的設(shè)計(jì)是用來(lái)與請(qǐng)求 header 值的驗(yàn)證代理結(jié)合使用。
https://jimmysong.io/kubernetes-handbook/guide/authentication.html#%E8%AE%A4%E8%AF%81%E4%BB%A3%E7%90%86

(9)匿名請(qǐng)求
未被其他已配置身份驗(yàn)證方法拒絕的請(qǐng)求將被視為匿名請(qǐng)求，用戶名：system:anonymous 、組名：system:unuthenticated
ABAC 和 RBAC 授權(quán)人需要明確授權(quán) system:annoymous 或 system:unauthenticated 組，因此授予對(duì) * 用戶或 * 組訪問(wèn)權(quán)的傳統(tǒng)策略規(guī)則不包括匿名用戶。

授權(quán)參數(shù)：

RBAC模式: https://kubernetes.io/docs/reference/access-authn-authz/rbac/

ABAC模式: https://kubernetes.io/docs/reference/access-authn-authz/abac/

Node模式: https://kubernetes.io/docs/reference/access-authn-authz/node/

Node模式：

• 為了獲得Node授權(quán)者的授權(quán)，kubelet必須使用憑證說(shuō)明它在system:nodes組中，用戶名為system:node:<nodeName>，該格式應(yīng)該與為 kubelet 作為 kubelet TLS 引導(dǎo)的創(chuàng)建的標(biāo)識(shí)相匹配。
• Node 授權(quán)者可以允許 kubelet 執(zhí)行 以下 API 操作：
  1、讀操作：服務(wù)、端點(diǎn)、節(jié)點(diǎn)、Pod、Secret、ConfigMap、persistent volume claims、綁定到kubelet節(jié)點(diǎn)的pod相關(guān)的持久卷
  2、寫操作：節(jié)點(diǎn)和節(jié)點(diǎn)狀態(tài)、pod和pod狀態(tài)、事件
  3、與認(rèn)證相關(guān)的操作：對(duì)TLS引導(dǎo)的certificationsigningrequests API的讀/寫訪問(wèn)權(quán)限、能夠?yàn)槲傻纳矸蒡?yàn)證/授權(quán)檢查創(chuàng)建tokenreviews和subjectaccessreviews

API啟用參數(shù)：

https://kubernetes.io/docs/reference/using-api/api-overview/

準(zhǔn)入?yún)?shù)：

https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
準(zhǔn)入控制器在請(qǐng)求經(jīng)過(guò)身份驗(yàn)證和授權(quán)之后、對(duì)象持久化之前，攔截對(duì)Kubernetes API服務(wù)器的請(qǐng)求。控制器被編譯為 kube-apiserver二進(jìn)制文件，只能由集群管理員配置。
準(zhǔn)入控制器可以是“validating”，“mutating”或兩者。變異控制器可以修改他們 admit 的對(duì)象; 驗(yàn)證控制器不會(huì)。
準(zhǔn)入控制過(guò)程分兩個(gè)階段進(jìn)行。在第一階段，運(yùn)行 mutating admission controllers。在第二階段，運(yùn)行 validating admission controllers。有些控制器會(huì)運(yùn)行兩次。如果任一階段中的任何控制器拒絕請(qǐng)求，則立即拒絕整個(gè)請(qǐng)求，并向最終用戶返回錯(cuò)誤。
準(zhǔn)入控制器有時(shí)可能具有副作用，即，作為請(qǐng)求處理的一部分來(lái)改變相關(guān)資源。比如增加配額使用量。任何副作用都需要相應(yīng)的回收或協(xié)調(diào)過(guò)程。

NodeRestriction：

• 限制 kubelet 修改 node 和 pod 對(duì)象的權(quán)限。 為了啟用該功能，kubelet 要使用 system: nodes 組中的證書。用戶名如下 system:node:<nodeName>。這種 kubelet只允許修改自己節(jié)點(diǎn)的 API 對(duì)象 和 綁定在該節(jié)點(diǎn)上的 POD API 對(duì)象。
• 對(duì)于 Kubernetes 1.11+, kubelet 不能修改其NodeAPI對(duì)象中的污點(diǎn)。
• 對(duì)于 Kubernetes 1.13+, kubelet 不能刪除其NodeAPI對(duì)象，并強(qiáng)制對(duì)其前綴kubernetes.io/或k8s.io/前綴下的標(biāo)簽進(jìn)行修改。
• 未來(lái)版本可能會(huì)添加其他限制，以確保kubelet具有正確操作所需的最小權(quán)限集。