CA 注入器

cainjector 有助於設定 CA 憑證，適用於：變更 Webhook、驗證 Webhook、轉換 Webhook 和 API 服務

特別是，cainjector 會填充四種 API 類型的 caBundle 欄位：ValidatingWebhookConfiguration、MutatingWebhookConfiguration、CustomResourceDefinition 和 APIService。前三種資源類型用於配置 Kubernetes API 伺服器如何連接到 Webhook。此 caBundle 資料由 Kubernetes API 伺服器載入，並用於驗證 Webhook API 伺服器的服務憑證。APIService 用於表示一個擴展 API 伺服器。APIService 的 caBundle 可以使用 CA 憑證填充，用於驗證 API 伺服器的服務憑證。

我們會將這四種 API 類型稱為可注入資源。

一個可注入的資源必須具有以下其中一個註釋：cert-manager.io/inject-ca-from、cert-manager.io/inject-ca-from-secret 或 cert-manager.io/inject-apiserver-ca，具體取決於注入的來源。這會在下面更詳細地說明。

cainjector 從三個來源之一複製 CA 資料：Kubernetes Secret、cert-manager Certificate 或 Kubernetes API 伺服器 CA 憑證（cainjector 本身用於驗證其與 Kubernetes API 伺服器的 TLS 連線）。

如果來源是 Kubernetes Secret，則該資源也必須具有 cert-manager.io/allow-direct-injection: "true" 註釋。這三種來源類型會在下面更詳細地說明。

範例

以下範例示範如何使用三種 cainjector 的來源。在每個情況下，我們都使用 ValidatingWebhookConfiguration 作為可注入的資源，但您也可以改為使用 MutatingWebhookConfiguration 或 CustomResourceDefinition 定義。

從 Certificate 資源注入 CA 資料

以下是一個 ValidatingWebhookConfiguration 的範例，它配置了 cert-manager.io/inject-ca-from 註釋，這將使 cainjector 使用 cert-manager Certificate 中的 CA 資料來填充 caBundle 欄位。

注意：此範例不部署 Webhook 伺服器，僅部署了部分 Webhook 配置，但它應該足以幫助您了解 cainjector 的作用

apiVersion: v1
kind: Namespace
metadata:
  name: example1

---

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: webhook1
  annotations:
    cert-manager.io/inject-ca-from: example1/webhook1-certificate
webhooks:
- name: webhook1.example.com
  admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: webhook1
      namespace: example1
      path: /validate
      port: 443
  sideEffects: None

---

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: webhook1-certificate
  namespace: example1
spec:
  secretName: webhook1-certificate
  dnsNames:
  - webhook1.example1
  issuerRef:
    name: selfsigned

---

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned
  namespace: example1
spec:
  selfSigned: {}

您應該會發現 caBundle 的值現在與 Certificate 的 Secret 中的 CA 值相同

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io webhook1 -o yaml | grep caBundle
kubectl -n example1 get secret webhook1-certificate -o yaml | grep ca.crt

在短時間後，Kubernetes API 伺服器將讀取新的 caBundle 值，並使用它來驗證與 Webhook 伺服器的 TLS 連線。

從 Secret 資源注入 CA 資料

以下是另一個 ValidatingWebhookConfiguration 的範例，這次配置了 cert-manager.io/inject-ca-from-secret 註釋，這將使 cainjector 使用 Kubernetes Secret 中的 CA 資料來填充 caBundle 欄位。

注意：此範例不部署 Webhook 伺服器，僅部署了部分 Webhook 配置，但它應該足以幫助您了解 cainjector 的作用

apiVersion: v1
kind: Namespace
metadata:
  name: example2

---

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: webhook2
  annotations:
    cert-manager.io/inject-ca-from-secret: example2/example-ca
webhooks:
- name: webhook2.example.com
  admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: webhook2
      namespace: example2
      path: /validate
      port: 443
  sideEffects: None

---

apiVersion: v1
kind: Secret
metadata:
  name: example-ca
  namespace: example2
  annotations:
    cert-manager.io/allow-direct-injection: "true"
type: kubernetes.io/tls
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM5akNDQWQ2Z0F3SUJBZ0lRTkdJZ24yM3BQYVpNbk9MUjJnVmZHakFOQmdrcWhraUc5dzBCQVFzRkFEQVYKTVJNd0VRWURWUVFERXdwRmVHRnRjR3hsSUVOQk1CNFhEVEl3TURreU5ERTFOREEwTVZvWERUSXdNVEl5TXpFMQpOREEwTVZvd0ZURVRNQkVHQTFVRUF4TUtSWGhoYlhCc1pTQkRRVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFECmdnRVBBRENDQVFvQ2dnRUJBS2F3RzVoMzlreHdyNEl0WCtHaDNYVWQrdTVJc2ZlSFdoTTc4TTRQTmZFeXhQMXoKRmNLN1d0MHJFMkwwNUppYmQ4ZjNpb3k5OXNnQ3I4OEw2SWxYZTB0RnkzNysxenJ4TFluR2hDQnZzZjltd0hLbgpIVTEvNERwQjROZkhPbFllNE9tbHVoNE9HdmZINU1EbDh5OWZGMjhXRXVBQ2dwdmpCUWxvRDNlVjJ5UmJvQ2kyCmtSTDJWYTFZL0FQZEpWK21VYkFvZmg0bllmUmNLRTJsSUg0RG5ZdXFPU3JaaituZUQ2M2RTSktxcHQ5K2luN2YKNHljZ2pQYU93MmdyKzhLK291QTlSQTV1VDI3SVNJcUJDcEV6elRqbVBUUWNvUTYxZGF0aDZkc1lsTEU4aWZWUwp4RWZuVEdQKy94M0FXQXR4eU5lanVuZGFXbVNFL3h5OHh0K0FxblVDQXdFQUFhTkNNRUF3RGdZRFZSMFBBUUgvCkJBUURBZ0trTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3SFFZRFZSME9CQllFRkowNkc5eEc2V1VBTHB6T3JYaHAKV2dsTm5qMkFNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUI3ZG9CZnBLR3o4VlRQSnc0YXhpdisybzJpMHE1SQpSRzU2UE81WnhKQktZQlRROElHQmFOSm1yeGtmNTJCV0ttUGp4cXlNSGRwWjVBU00zOUJkZVUzRGtEWHp4RkgwCjM5RU12UnhIUERyMGQ4cTFFbndQT0xZY1hzNjJhYjdidE11cTJUMFNNZzRYMkY5VmNKTW5YdjlrNnA0VGZNR3MKVThCQnJhVGhUZm53ejBsWXMyblFjdzNmZjZ1bG1wWlk4K3BTak1aVDNJZHZOMFA4Y2hOdUlmUFRHWDJmSlo2NQpxcUUrelRoU3hIeXFTOTVoczhsd1lRRUhGQlVsalRnMCtQZThXL0hOSXZBOU9TYWw1U3UvdlhydmcxN04xdHVyCk5XcWRyZU5OVm1ubXMvTFJodmthWTBGblRvbFNBRkNXWS9GSDY5ZzRPcThiMHVyK3JVMHZOZFFXCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  tls.key: ""
  tls.crt: ""

您應該會發現 caBundle 的值現在與 Secret 中的 ca.crt 值相同

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io webhook2  -o yaml | grep caBundle

在短時間後，Kubernetes API 伺服器將讀取新的 caBundle 值，並使用它來驗證與 Webhook 伺服器的 TLS 連線。

此基於 Secret 的注入機制可以獨立於先前描述的基於 Certificate 的機制運作。它可以在沒有安裝 cert-manager CRD 的情況下運作，並且即使 cert-manager CRD 和相關的 Webhook 伺服器尚未配置，它也可以運作。

注意：因此，cert-manager 使用基於 Secret 的注入機制來引導其自身的 Webhook 伺服器。cert-manager Webhook 伺服器會在啟動時產生自己的私鑰和自我簽署憑證，並將它們放置在 Secret 中。

注入 Kubernetes API 伺服器 CA

以下是另一個 ValidatingWebhookConfiguration 的範例，這次配置了 cert-manager.io/inject-apiserver-ca: "true" 註釋，這將使 cainjector 使用 Kubernetes API 伺服器所使用的相同 CA 憑證來填充 caBundle 欄位。

注意：此範例不部署 Webhook 伺服器，僅部署了部分 Webhook 配置，但它應該足以幫助您了解 cainjector 的作用

apiVersion: v1
kind: Namespace
metadata:
  name: example3

---

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: webhook3
  annotations:
    cert-manager.io/inject-apiserver-ca: "true"
webhooks:
- name: webhook3.example.com
  admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: webhook3
      namespace: example3
      path: /validate
      port: 443
  sideEffects: None

您應該會發現 caBundle 的值現在與您的 KubeConfig 檔案中使用的 CA 相同

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io webhook3 -o yaml | grep caBundle
kubectl config  view --minify --raw | grep certificate-authority-data

在短時間後，Kubernetes API 伺服器將讀取新的 caBundle 值，並使用它來驗證與 Webhook 伺服器的 TLS 連線。

注意：在這種情況下，您必須確保您的 Webhook 配置為提供由 Kubernetes 集群 CA 簽署的 TLS 憑證。這種機制的缺點是：您將需要存取 Kubernetes 集群 CA 的私鑰，並且您需要手動輪換 Webhook 憑證。