使用啟動引導權杖進行身分驗證

啟動引導權杖是一種簡單的承載權杖，旨在用於建立新叢集或將新節點加入現有叢集時使用。它建置用於支援 kubeadm，但也可以在其他情境中供希望在沒有 kubeadm 的情況下啟動叢集的使用者使用。它也建置為透過 RBAC 策略與 kubelet TLS 啟動引導系統搭配運作。

啟動引導權杖總覽

啟動引導權杖定義為特定類型 (bootstrap.kubernetes.io/token) 的密鑰，位於 kube-system 命名空間中。API 伺服器中的啟動引導驗證器接著會讀取這些密鑰。過期的權杖會由控制器管理員中的 TokenCleaner 控制器移除。權杖也用於為特定的 ConfigMap 建立簽章，該 ConfigMap 用於透過 BootstrapSigner 控制器進行的「探索」程序。

權杖格式

啟動引導權杖採用 abcdef.0123456789abcdef 的格式。更正式地說，它們必須符合正規表示式 [a-z0-9]{6}\.[a-z0-9]{16}。

權杖的第一部分是「權杖 ID」，被視為公開資訊。它用於在不洩漏用於身分驗證的密鑰部分的情況下參考權杖。第二部分是「權杖密鑰」，應僅與信任的對象共用。

啟用啟動引導權杖身分驗證

可以使用 API 伺服器上的以下旗標啟用啟動引導權杖驗證器

--enable-bootstrap-token-auth

啟用後，啟動引導權杖可以用作承載權杖憑證，以驗證對 API 伺服器的請求。

Authorization: Bearer 07401b.f395accd246ae52d

權杖以使用者名稱 system:bootstrap:<token id> 進行身分驗證，並且是群組 system:bootstrappers 的成員。其他群組可能會在權杖的密鑰中指定。

可以透過在控制器管理員上啟用 tokencleaner 控制器來自動刪除過期的權杖。

--controllers=*,tokencleaner

啟動引導權杖密鑰格式

每個有效的權杖都由 kube-system 命名空間中的密鑰支援。您可以在此處找到完整設計文件。

以下是密鑰的外觀。

apiVersion: v1
kind: Secret
metadata:
  # Name MUST be of form "bootstrap-token-<token id>"
  name: bootstrap-token-07401b
  namespace: kube-system

# Type MUST be 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
stringData:
  # Human readable description. Optional.
  description: "The default bootstrap token generated by 'kubeadm init'."

  # Token ID and secret. Required.
  token-id: 07401b
  token-secret: f395accd246ae52d

  # Expiration. Optional.
  expiration: 2017-03-10T03:22:11Z

  # Allowed usages.
  usage-bootstrap-authentication: "true"
  usage-bootstrap-signing: "true"

  # Extra groups to authenticate the token as. Must start with "system:bootstrappers:"
  auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress

密鑰的類型必須是 bootstrap.kubernetes.io/token，名稱必須是 bootstrap-token-<token id>。它也必須存在於 kube-system 命名空間中。

usage-bootstrap-* 成員表示此密鑰的預期用途。必須將值設定為 true 才能啟用。

• usage-bootstrap-authentication 表示權杖可以用作承載權杖向 API 伺服器進行身分驗證。
• usage-bootstrap-signing 表示權杖可以用於簽署 cluster-info ConfigMap，如下所述。

expiration 欄位控制權杖的到期時間。過期的權杖在用於身分驗證時會被拒絕，在 ConfigMap 簽署期間會被忽略。到期值使用 RFC3339 編碼為絕對 UTC 時間。啟用 tokencleaner 控制器以自動刪除過期的權杖。

使用 kubeadm 進行權杖管理

您可以使用 kubeadm 工具來管理執行中叢集上的權杖。請參閱 kubeadm token 文件 以取得詳細資訊。

ConfigMap 簽署

除了身分驗證之外，權杖還可以用於簽署 ConfigMap。這在叢集啟動引導程序早期使用，在用戶端信任 API 伺服器之前。簽署的 ConfigMap 可以透過共用的權杖進行身分驗證。

透過在控制器管理員上啟用 bootstrapsigner 控制器來啟用 ConfigMap 簽署。

--controllers=*,bootstrapsigner

簽署的 ConfigMap 是 kube-public 命名空間中的 cluster-info。典型的流程是用戶端在未經驗證且忽略 TLS 錯誤的情況下讀取此 ConfigMap。然後，它透過查看嵌入在 ConfigMap 中的簽章來驗證 ConfigMap 的酬載。

ConfigMap 可能如下所示

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-info
  namespace: kube-public
data:
  jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
  kubeconfig: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: <really long certificate data>
        server: https://10.138.0.2:6443
      name: ""
    contexts: []
    current-context: ""
    kind: Config
    preferences: {}
    users: []    

ConfigMap 的 kubeconfig 成員是一個僅填寫叢集資訊的組態檔。此處傳達的重點是 certificate-authority-data。未來可能會擴展此功能。

簽章是使用「分離」模式的 JWS 簽章。為了驗證簽章，使用者應根據 JWS 規則 (base64 編碼，同時捨棄任何尾隨的 =) 編碼 kubeconfig 酬載。然後，將編碼的酬載用於透過將其插入 2 個點之間來形成完整的 JWS。您可以使用完整的權杖 (例如 07401b.f395accd246ae52d) 作為共用密鑰，使用 HS256 方案 (HMAC-SHA256) 驗證 JWS。使用者必須驗證是否使用了 HS256。

請參閱 kubeadm 實作細節 章節以取得更多資訊。