跳至內容

設定 Knative cert-manager 整合

Knative Serving 依賴一個橋接元件來使用 cert-manager 進行自動憑證佈建。如果您打算使用該功能，您需要啟用 Knative cert-manager 整合。

先決條件

您的 Knative 叢集上必須安裝下列項目

警告

請確保您已安裝 cert-manager。否則，Serving 控制器將無法正確啟動。

簽發者設定

Knative cert-manager 整合定義了對 cert-manager 簽發者的三個參考，以針對 三個 Knative Serving 加密功能設定不同的 CA

  • issuerRef：用於外部網域憑證的簽發者，用於輸入。
  • clusterLocalIssuerRef：用於叢集本地網域憑證的簽發者，用於輸入。
  • systemInternalIssuerRef：用於 Knative 內部元件使用的系統內部 TLS 憑證的簽發者。

以下範例使用自我簽署的 ClusterIssuer，而 Knative cert-manager 整合會針對所有三個設定參考該 ClusterIssuer。由於這不應在生產環境中使用（並且不支援在不停機的情況下輪換 CA），您應該考慮每個用例應使用哪個 CA，以及信任將如何分發給呼叫加密服務的用戶端。對於 Knative 系統元件，Knative 提供了一種指定應信任的 CA 套件的方式（稍後會詳細說明）。

關於如何組織這個沒有一般的答案，以下是一個可能的範例

功能 憑證授權單位 透過以下方式信任
external-domain-tls Let's Encrypt 瀏覽器用戶端已具有 Let's Encrypt 鏈，所有根 CA 都將由 DevOps 團隊添加到公司範圍的 Docker 基礎映像中。
cluster-local-domain-tls 叢集營運商提供的 CA CA 由 DevOps 團隊管理，並將添加到公司範圍的 Docker 基礎映像中。
system-internal-tls 自我簽署的 Cert-Manager ClusterIssuer CA 將由 cert-manager 填入。DevOps 團隊將使用 trust-manager 將 CA 分發到 Knative 系統元件。

簽發者選擇

一般而言，您可以參考 cert-manager 文件。有適用於以下項目的範例

重要

請注意，並非所有簽發者類型都適用於每個 Knative 功能。

cluster-local-domain-tls 需要能夠為叢集本機網域簽署憑證，例如 myapp.<命名空間>、myapp.<命名空間>.svc 和 myapp.<命名空間>.svc.cluster.local。CA 通常位於叢集外部，因此無法透過 ACME 協定 (DNS01/HTTP01) 進行驗證。您可以使用允許建立這些憑證的簽發者（例如，CA 簽發者）。

system-internal-tls 需要能夠簽署 Knative 驗證的特定 SAN。定義的 SAN 集合為

  • kn-routing
  • kn-user-<命名空間> (是建立/將建立 Knative 服務的每個命名空間）
  • data-plane.knative.dev

由於這也無法透過 ACME 協定 (DNS01/HTTP01) 實現，因此您需要設定允許建立這些憑證的簽發者（例如，CA 簽發者）。

設定簽發者

警告

自我簽署的叢集簽發者不應在生產環境中使用，請參閱上方的 簽發者設定 以取得更多資訊。

  1. 建立並將以下自我簽署的 ClusterIssuer 套用至您的叢集

    # this issuer is used by cert-manager to sign all certificates
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: cluster-selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer # this issuer is specifically for Knative, it will use the CA stored in the secret created by the Certificate below
metadata:
  name: knative-selfsigned-issuer
spec:
  ca:
    secretName: knative-selfsigned-ca
---
apiVersion: cert-manager.io/v1
kind: Certificate # this creates a CA certificate, signed by cluster-selfsigned-issuer and stored in the secret knative-selfsigned-ca
metadata:
  name: knative-selfsigned-ca
  namespace: cert-manager #  If you want to use it as a ClusterIssuer the secret must be in the cert-manager namespace.
spec:
  secretName: knative-selfsigned-ca
  commonName: knative.dev
  usages:
    - server auth
  isCA: true
  issuerRef:
    kind: ClusterIssuer
    name: cluster-selfsigned-issuer

  2. 確保 ClusterIssuer 已就緒

    kubectl get clusterissuer cluster-selfsigned-issuer -o yaml
kubectl get clusterissuer knative-selfsigned-issuer -o yaml
    結果：Status.Conditions 應包含 Ready=True。

  3. 然後在 config-certmanager ConfigMap 中參考 ClusterIssuer

    kubectl edit configmap config-certmanager -n knative-serving

    在 data 區段中新增欄位

    apiVersion: v1
kind: ConfigMap
metadata:
  name: config-certmanager
  namespace: knative-serving
  labels:
    networking.knative.dev/certificate-provider: cert-manager
data:
  issuerRef: |
    kind: ClusterIssuer
    name: knative-selfsigned-issuer
  clusterLocalIssuerRef: |
    kind: ClusterIssuer
    name: knative-selfsigned-issuer
  systemInternalIssuerRef: |
    kind: ClusterIssuer
    name: knative-selfsigned-issuer

    確保檔案已成功更新

    kubectl get configmap config-certmanager -n knative-serving -o yaml

管理信任和輪換而不停機

如上所述，每個使用 HTTPS 呼叫 Knative 服務的用戶端都需要信任 CA 和/或中繼鏈。如果您查看 加密概述，您可以看到有多個地方需要分發信任

  • 叢集外部用戶端（瀏覽器和/或其他應用程式）：這被認為超出 Knative 的範圍。
  • 叢集內部用戶端（例如，Knative 或 Vanilla K8s 工作負載）：請參閱下方。
  • Knative 系統元件（例如，Activator、Queue-Proxy、Ingress-Controller）：請參閱下方。

信任叢集內部用戶端（例如，Knative 或 Vanilla K8s 工作負載）

由於 Knative 不控制所有工作負載，而且設定高度依賴於您的執行時間和/或語言，因此這超出了 Knative 的範圍。但以下是一些需要考慮的要點，因為有幾種方式可以將 CA 提供給您的應用程式

  • 在建置時將 CA 套件新增至容器映像（請注意，這會使 CA 輪換變得複雜，您基本上需要重建每個應用程式）
  • 將 CA 套件掛載到檔案系統（例如，從 Secret 或 ConfigMap）
  • 從環境變數讀取
  • 透過 K8s API 從 Secret/ConfigMap 存取

如果無需停機即可重新載入憑證對您的用戶端很重要，則工作負載必須監看 K8s 資源 (Secret/ConfigMap) 的變更或監看檔案系統。如果工作負載正在監看檔案系統，則請務必注意，使用 ionotify 捕捉變更的 Secret/ConfigMap 在 K8s 上並不是很可靠。測試表明，定期輪詢並檢查檔案系統上的憑證是否有變更更可靠。

以下是一些 golang 的範例

信任 Knative 系統元件

Knative 系統元件可以被設定為信任來自 ConfigMaps 的一個或多個 CA 憑證包。叢集操作員需要確保相應地配置它們，以避免在輪換期間發生任何停機。Knative 元件會在元件運行的命名空間中尋找 ConfigMap，例如：

  • knative-serving
  • istio-system (當使用 net-istio 時)
  • kourier-system (當使用 net-kourier 時)
  • 每個運行 Knative 服務的命名空間

Knative 會尋找帶有標籤 networking.knative.dev/trust-bundle: "true" 的 ConfigMap，並讀取所有 data 鍵（無論名稱為何）。一個鍵可以包含一個或多個 CA/中繼憑證。如果它們有效，它們將被添加到 Knative 元件的信任儲存區。

以下是一個 ConfigMap 可能的範例：

apiVersion: v1
data:
  cacerts.pem: |
    -----BEGIN CERTIFICATE-----
    MIIDDTCCAfWgAwIBAgIQMQuip05h7NLQq2TB+j9ZmTANBgkqhkiG9w0BAQsFADAW
    MRQwEgYDVQQDEwtrbmF0aXZlLmRldjAeFw0yMzExMjIwOTAwNDhaFw0yNDAyMjAw
    OTAwNDhaMBYxFDASBgNVBAMTC2tuYXRpdmUuZGV2MIIBIjANBgkqhkiG9w0BAQEF
    AAOCAQ8AMIIBCgKCAQEA3clC3CV7sy0TpUKNuTku6QmP9z8JUCbLCPCLACCUc1zG
    FEokqOva6TakgvAntXLkB3TEsbdCJlNm6qFbbko6DBfX6rEggqZs40x3/T+KH66u
    4PvMT3fzEtaMJDK/KQOBIvVHrKmPkvccUYK/qWY7rgBjVjjLVSJrCn4dKaEZ2JNr
    Fd0KNnaaW/dP9/FvviLqVJvHnTMHH5qyRRr1kUGTrc8njRKwpHcnUdauiDoWRKxo
    Zlyy+MhQfdbbyapX984WsDjCvrDXzkdGgbRNAf+erl6yUm6pHpQhyFFo/zndx6Uq
    QXA7jYvM2M3qCnXmaFowidoLDsDyhwoxD7WT8zur/QIDAQABo1cwVTAOBgNVHQ8B
    Af8EBAMCAgQwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zAd
    BgNVHQ4EFgQU7p4VuECNOcnrP9ulOjc4J37Q2VUwDQYJKoZIhvcNAQELBQADggEB
    AAv26Vnk+ptQrppouF7yHV8fZbfnehpm07HIZkmnXO2vAP+MZJDNrHjy8JAVzXjt
    +OlzqAL0cRQLsUptB0btoJuw23eq8RXgJo05OLOPQ2iGNbAATQh2kLwBWd/CMg+V
    KJ4EIEpF4dmwOohsNR6xa/JoArIYH0D7gh2CwjrdGZr/tq1eMSL+uZcuX5OiE44A
    2oXF9/jsqerOcH7QUMejSnB8N7X0LmUvH4jAesQgr7jo1JTOBs7GF6wb+U76NzFa
    8ms2iAWhoplQ+EHR52wffWb0k6trXspq4O6v/J+nq9Ky3vC36so+G1ZFkMhCdTVJ
    ZmrBsSMWeT2l07qeei2UFRU=
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  labels:
    networking.knative.dev/trust-bundle: "true"
  name: knative-bundle
  namespace: knative-serving

使用 trust-manager 分發憑證包

由於將 CA 憑證包分發到所有命名空間可能是一項繁瑣的任務，您可以使用 trust-manager 自動分發 CA 憑證包。請參閱其文件以獲取更多關於如何操作的資訊。

輪換期間的信任

在 CA 和/或中繼憑證輪換期間，您的客戶端需要信任舊的和新的 CA/鏈，直到輪換完成。使用上述的 信任方法，您可以進行完整的鏈輪換而不會停機。

  1. 確保您現有的設定已啟動並運行。
  2. 確保所有 Knative 服務都具有相關的憑證且未過期。
  3. 確保您的 CA (和完整的鏈) 未過期。
  4. 將現有的和新的 CA (以及完整的鏈) 添加到信任憑證包 (手動或透過 trust-manager)。
  5. 重新配置您的 cert-manager ClusterIssuers 或 Issuers 以使用新的 CA。
  6. 等待直到所有憑證過期並由 cert-manager 續訂。
  7. 所有憑證現在都由新的 CA 簽署。
  8. 新增一些寬限期，以確保所有元件都已接收到所有變更。
  9. 從信任憑證包中移除舊的 CA。

我們使用分析和 Cookie 來了解網站流量。您使用我們網站的資訊會與 Google 分享用於該目的。了解更多。

× 確定