TLS bootstrap · kubernetes完整攻略

## TLS Bootstrap 本文檔介紹如何為 kubelet 設置 TLS 客戶端證書引導（bootstrap）。 Kubernetes 1.4 引入了一個用于從集群級證書頒發機構（CA）請求證書的 API。此 API 的原始目的是為 kubelet 提供 TLS 客戶端證書。可以在 [這里](https://github.com/kubernetes/kubernetes/pull/20439) 找到該提議，在 [feature #43](https://github.com/kubernetes/features/issues/43) 追蹤該功能的進度。 ## kube-apiserver 配置您必須提供一個 token 文件，該文件中指定了至少一個分配給 kubelet 特定 bootstrap 組的 “bootstrap token”。該組將作為 controller manager 配置中的默認批準控制器而用于審批。隨著此功能的成熟，您應該確保 token 被綁定到基于角色的訪問控制（RBAC）策略上，該策略嚴格限制了與證書配置相關的客戶端請求（使用 bootstrap token）。使用 RBAC，將 token 范圍劃分為組可以帶來很大的靈活性（例如，當您配置完成節點后，您可以禁用特定引導組的訪問）。 ### Token 認證文件 Token 可以是任意的，但應該可以表示為從安全隨機數生成器（例如大多數現代操作系統中的 /dev/urandom）導出的至少128位熵。生成 token 有很多中方式。例如： `head -c 16 /dev/urandom | od -An -t x | tr -d ' '` 產生的 token 類似于這樣： `02b50b05283e98dd0fd71db496ef01e8`。 Token 文件應該類似于以下示例，其中前三個值可以是任何值，引用的組名稱應如下所示： ```bash 02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:kubelet-bootstrap" ``` 在 kube-apiserver 命令中添加 `--token-auth-file=FILENAME` 標志（可能在您的 systemd unit 文件中）來啟用 token 文件。查看 [該文檔](https://kubernetes.io/docs/admin/authentication/#static-token-file) 獲取更多詳細信息。 ### 客戶端證書 CA 包在 kube-apiserver 命令中添加 `--client-ca-file=FILENAME` 標志啟用客戶端證書認證，指定包含簽名證書的證書頒發機構包（例如 `--client-ca-file=/var/lib/kubernetes/ca.pem`）。 ### kube-controller-manager 配置請求證書的 API 向 Kubernetes controller manager 中添加證書頒發控制循環。使用磁盤上的 [cfssl](https://blog.cloudflare.com/introducing-cfssl/) 本地簽名文件的形式。目前，所有發型的證書均為一年有效期和并具有一系列關鍵用途。 ### 簽名文件您必須提供證書頒發機構，這樣才能提供頒發證書所需的密碼資料。 kube-apiserver 通過指定的 `--client-ca-file=FILENAME` 標志來認證和采信該 CA。CA 的管理超出了本文檔的范圍，但建議您為 Kubernetes 生成專用的 CA。假定證書和密鑰都是 PEM 編碼的。 Kube-controller-manager 標志為： ``` --cluster-signing-cert-file="/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key" ``` ### 審批控制器在 kubernetes 1.7 版本中，實驗性的 “組自動批準” 控制器被棄用，新的 `csrapproving` 控制器將作為 [kube-controller-manager](https://kubernetes.io/docs/admin/kube-controller-manager) 的一部分，被默認啟用。控制器使用 [`SubjectAccessReview` API](https://kubernetes.io/docs/admin/authorization/#checking-api-access) 來確定給定用戶是否已被授權允許請求 CSR，然后根據授權結果進行批準。為了防止與其他批準者沖突，內置審批者沒有明確地拒絕 CSR，只是忽略未經授權的請求。控制器將 CSR 分為三個子資源： 1. `nodeclient` ：用戶的客戶端認證請求 `O=system:nodes`， `CN=system:node:(node name)`。 2. `selfnodeclient`：更新具有相同 `O` 和 `CN` 的客戶端證書的節點。 3. `selfnodeserver`：更新服務證書的節點（ALPHA，需要 feature gate）。當前，確定 CSR 是否為 `selfnodeserver` 請求的檢查與 kubelet 的憑據輪換實現（Alpha 功能）相關聯。因此，`selfnodeserver` 的定義將來可能會改變，并且需要 Controller Manager 上的`RotateKubeletServerCertificate` feature gate。該功能的進展可以在 [kubernetes/feature/#267](https://github.com/kubernetes/features/issues/267) 上追蹤。 ``` --feature-gates=RotateKubeletServerCertificate=true ``` 以下 RBAC `ClusterRoles` 代表 `nodeClient`、`selfnodeclient` 和 `selfnodeserver` 功能。在以后的版本中可能會自動創建類似的角色。 ```yaml # A ClusterRole which instructs the CSR approver to approve a user requesting # node client credentials. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: approve-node-client-csr rules: - apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/nodeclient"] verbs: ["create"] --- # A ClusterRole which instructs the CSR approver to approve a node renewing its # own client credentials. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: approve-node-client-renewal-csr rules: - apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/selfnodeclient"] verbs: ["create"] --- # A ClusterRole which instructs the CSR approver to approve a node requesting a # serving cert matching its client cert. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: approve-node-server-renewal-csr rules: - apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/selfnodeserver"] verbs: ["create"] ``` 這些權力可以授予給憑證，如 bootstrap token。例如，要復制由已被移除的自動批準標志提供的行為，由單個組批準所有的 CSR： ``` # REMOVED: This flag no longer works as of 1.7. --insecure-experimental-approve-all-kubelet-csrs-for-group="kubelet-bootstrap-token" ``` 管理員將創建一個 `ClusterRoleBinding` 來定位該組。 ```yaml # Approve all CSRs for the group "kubelet-bootstrap-token" kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: auto-approve-csrs-for-group subjects: - kind: Group name: kubelet-bootstrap-token apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: approve-node-client-csr apiGroup: rbac.authorization.k8s.io ``` 要讓節點更新自己的憑據，管理員可以構造一個 `ClusterRoleBinding` 來定位該節點的憑據。 ```yaml kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: node1-client-cert-renewal subjects: - kind: User name: system:node:node-1 # Let "node-1" renew its client certificate. apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: approve-node-client-renewal-csr apiGroup: rbac.authorization.k8s.io ``` 刪除該綁定將會阻止節點更新客戶端憑據，一旦其證書到期，實際上就會將其從集群中刪除。 ## kubelet 配置要向 kube-apiserver 請求客戶端證書，kubelet 首先需要一個包含 bootstrap 身份驗證 token 的 kubeconfig 文件路徑。您可以使用 `kubectl config set-cluster`，`set-credentials` 和 `set-context` 來構建此 kubeconfig 文件。為 `kubectl config set-credentials` 提供 `kubelet-bootstrap` 的名稱，并包含 `--token = <token-value>`，如下所示： ```bash kubectl config set-credentials kubelet-bootstrap --token=${BOOTSTRAP_TOKEN} --kubeconfig=bootstrap.kubeconfig ``` 啟動 kubelet 時，如果 `--kubeconfig` 指定的文件不存在，則使用 bootstrap kubeconfig 向 API server 請求客戶端證書。在批準 `kubelet` 的證書請求和回執時，將包含了生成的密鑰和證書的 kubeconfig 文件寫入由 `-kubeconfig` 指定的路徑。證書和密鑰文件將被放置在由 `--cert-dir` 指定的目錄中。啟動 kubelet 時啟用 bootstrap 用到的標志： ```bash --experimental-bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig" ``` 此外，在1.7中，kubelet 實現了 **Alpha** 功能，使其客戶端和/或服務器都能輪轉提供證書。可以分別通過 kubelet 中的 `RotateKubeletClientCertificate` 和 `RotateKubeletServerCertificate` 功能標志啟用此功能，但在未來版本中可能會以向后兼容的方式發生變化。 ```bash --feature-gates=RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true ``` `RotateKubeletClientCertificate` 可以讓 kubelet 在其現有憑據到期時通過創建新的 CSR 來輪換其客戶端證書。 `RotateKubeletServerCertificate` 可以讓 kubelet 在其引導客戶端憑據后還可以請求服務證書，并輪換該證書。服務證書目前不要求 DNS 或 IP SANs。 ## kubectl 審批簽名控制器不會立即簽署所有證書請求。相反，它會一直等待直到適當特權的用戶被標記為 “已批準” 狀態。這最終將是由外部審批控制器來處理的自動化過程，但是對于 alpha 版本的 API 來說，可以由集群管理員通過 kubectl 命令手動完成。管理員可以使用 `kubectl get csr` 命令列出所有的 CSR，使用 `kubectl describe csr <name>` 命令描述某個 CSR的詳細信息。在 1.6 版本以前，[沒有直接的批準/拒絕命令](https://github.com/kubernetes/kubernetes/issues/30163) ，因此審批者需要直接更新 Status 信息（[查看如何實現](https://github.com/gtank/csrctl)）。此后的 Kubernetes 版本中提供了 `kubectl certificate approve <name>` 和 `kubectl certificate deny <name>` 命令。