用戶使用 ?kubectl?、客戶端庫或通過發(fā)出 REST 請求來訪問 Kubernetes API。 human用戶和 Kubernetes 服務(wù)帳戶都可以被授權(quán)訪問 API。 當請求到達 API 時，它會經(jīng)歷幾個階段，如下圖所示：

專注于為中小企業(yè)提供做網(wǎng)站、成都做網(wǎng)站服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)岫巖免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上1000家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

運輸安全

在典型的 Kubernetes 集群中，API 服務(wù)于端口 443，受 TLS 保護。 API 服務(wù)器提供一個證書。 該證書可以使用私有證書頒發(fā)機構(gòu) (CA) 進行簽名，也可以基于鏈接到公認 CA 的公鑰基礎(chǔ)設(shè)施進行簽名。

如果您的集群使用私有證書頒發(fā)機構(gòu)，您需要將該 CA 證書的副本配置到客戶端的 ?~/.kube/config? 中，以便您可以信任連接并確信它沒有被攔截。

您的客戶端可以在此階段出示 TLS 客戶端證書。

驗證

建立 TLS 后，HTTP 請求將移至身份驗證步驟。這在圖中顯示為步驟 1。集群創(chuàng)建腳本或集群管理員將 API 服務(wù)器配置為運行一個或多個 Authenticator 模塊。

身份驗證步驟的輸入是整個 HTTP 請求；但是，它通常會檢查標頭和/或客戶端證書。

身份驗證模塊包括客戶端證書、密碼和普通令牌、引導(dǎo)令牌和 JSON Web 令牌（用于服務(wù)帳戶）。

可以指定多個認證模塊，依次嘗試每一個，直到其中一個成功。

如果請求無法通過身份驗證，則會以 HTTP 狀態(tài)代碼 401 拒絕該請求。否則，用戶將作為特定用戶名進行身份驗證，并且該用戶名可供后續(xù)步驟在其決策中使用。一些身份驗證器還提供用戶的組成員身份，而其他身份驗證器不提供。

雖然 Kubernetes 使用用戶名進行訪問控制決策和請求日志記錄，但它沒有用戶對象，也沒有在其 API 中存儲用戶名或其他有關(guān)用戶的信息。

授權(quán)

在請求被驗證為來自特定用戶之后，該請求必須被授權(quán)。 這在圖中顯示為步驟 2。

請求必須包含請求者的用戶名、請求的操作以及受該操作影響的對象。 如果現(xiàn)有策略聲明用戶有權(quán)完成所請求的操作，則該請求被授權(quán)。

例如，如果 Bob 具有以下策略，那么他只能讀取命名空間 ?projectCaribou ?中的 pod：

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "projectCaribou",
        "resource": "pods",
        "readonly": true
    }
}

如果 Bob 發(fā)出以下請求，則該請求被授權(quán)，因為允許他讀取 ?projectCaribou ?命名空間中的對象：

{
  "apiVersion": "authorization.K8S.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "projectCaribou",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    }
  }
}

如果 Bob 請求寫入（?create?或?update?）?projectCaribou ?命名空間中的對象，他的授權(quán)將被拒絕。如果 Bob 請求讀?。?get?）不同命名空間（例如 ?projectFish?）中的對象，那么他的授權(quán)將被拒絕。

Kubernetes 授權(quán)要求您使用通用 REST 屬性與現(xiàn)有的組織范圍或云提供商范圍的訪問控制系統(tǒng)進行交互。使用 REST 格式很重要，因為這些控制系統(tǒng)可能會與 Kubernetes API 之外的其他 API 交互。

Kubernetes 支持 ABAC 模式、RBAC 模式、Webhook 模式等多種授權(quán)模塊。當管理員創(chuàng)建集群時，他們配置應(yīng)該在 API 服務(wù)器中使用的授權(quán)模塊。如果配置了多個授權(quán)模塊，Kubernetes 會檢查每個模塊，如果有任何模塊授權(quán)請求，則請求可以繼續(xù)。如果所有模塊都拒絕該請求，則該請求被拒絕（HTTP 狀態(tài)代碼 403）。

準入控制

準入控制模塊是可以修改或拒絕請求的軟件模塊。除了授權(quán)模塊可用的屬性外，準入控制模塊還可以訪問正在創(chuàng)建或修改的對象的內(nèi)容。

準入控制器對創(chuàng)建、修改、刪除或連接（代理）對象的請求進行操作。準入控制器不會對僅讀取對象的請求進行操作。配置多個準入控制器時，按順序調(diào)用。

這在圖中顯示為步驟 3。

與身份驗證和授權(quán)模塊不同，如果任何準入控制器模塊拒絕，則請求會立即被拒絕。

除了拒絕對象，準入控制器還可以為字段設(shè)置復(fù)雜的默認值。

一旦請求通過了所有準入控制器，就會使用相應(yīng) API 對象的驗證例程對其進行驗證，然后將其寫入對象存儲（如步驟 4 所示）。

Auditing

Kubernetes auditing提供了一組與安全相關(guān)的、按時間順序排列的記錄，記錄了集群中的操作順序。 集群審核用戶、使用 Kubernetes API 的應(yīng)用程序以及控制平面本身生成的活動。

API 服務(wù)器端口和 IP

前面的討論適用于發(fā)送到 API 服務(wù)器安全端口的請求（典型情況）。 API 服務(wù)器實際上可以在 2 個端口上服務(wù)：

默認情況下，Kubernetes API 服務(wù)器在 2 個端口上提供 HTTP：

1. 本地主機端口:
• 用于測試和引導(dǎo)，以及主節(jié)點的其他組件（調(diào)度程序、控制器管理器）與 API 對話
• 沒有 TLS
• 默認為 8080 端口
• 默認 IP 是 localhost，使用 ?--insecure-bind-address? 標志進行更改。
• 請求繞過身份驗證和授權(quán)模塊。
• 由準入控制模塊處理的請求。
• 受需要擁有主機訪問權(quán)限的保護
2. “安全端口”：
• 盡可能使用
• 使用 TLS。 使用 ?--tls-cert-file? 設(shè)置證書，使用 ?--tls-private-key-file? 標志設(shè)置密鑰。
• 默認為端口 6443，使用 ?--secure-port? 標志進行更改。
• 默認 IP 是第一個非本地主機網(wǎng)絡(luò)接口，使用 ?--bind-address? 標志進行更改。
• 由身份驗證和授權(quán)模塊處理的請求。
• 由準入控制模塊處理的請求。
• 身份驗證和授權(quán)模塊運行。

當前文章：創(chuàng)新互聯(lián)kubernetes教程：KubernetesAPI訪問控制
路徑分享：http://uogjgqi.cn/article/djcsgpd.html