共用方式為

使用手動憑證管理設定 TLS，以保護 Azure IoT MQ 預覽版中的 MQTT 通訊

  • 發行項

重要

Azure IoT Operations Preview – 由 Azure Arc 啟用目前處於預覽狀態。 您不應該在生產環境中使用此預覽軟體。

請參閱 Microsoft Azure 預覽版增補使用規定，以了解適用於 Azure 功能 (搶鮮版 (Beta)、預覽版，或尚未正式發行的版本) 的法律條款。

您可以使用 BrokerListener 資源，設定 TLS 來保護 MQTT 訊息代理程式與客戶端之間的 MQTT 通訊。 您可以使用手動或自動憑證管理來設定 TLS。

若要手動設定 Azure IoT MQ 預覽版以使用特定的 TLS 憑證，請在 BrokerListener 資源中指定它，並參考 Kubernetes 秘密。 然後使用 kubectl 部署它。 本文說明使用自我簽署憑證設定 TLS 以進行測試的範例。

使用步驟 CLI 建立證書頒發機構單位

步驟 是憑證管理員，可讓您在建立和管理您自己的私人 CA 時快速啟動並執行。

  1. 安裝步驟 CLI 並建立跟證書授權單位 （CA） 憑證和密鑰。

    step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.key

  2. 建立根 CA 簽署的中繼 CA 憑證和金鑰。

    step certificate create --profile intermediate-ca "Example Intermediate CA" intermediate_ca.crt intermediate_ca.key \
--ca root_ca.crt --ca-key root_ca.key

建立伺服器證書

使用步驟 CLI 從中繼 CA 簽署的 建立伺服器證書。

step certificate create mqtts-endpoint mqtts-endpoint.crt mqtts-endpoint.key \
--profile leaf \
--not-after 8760h \
--san mqtts-endpoint \
--san localhost \
--ca intermediate_ca.crt --ca-key intermediate_ca.key \
--no-password --insecure

mqtts-endpointlocalhost以下是 Azure IoT MQ 在 Kubernetes 和本機用戶端中代理程式前端的主體替代名稱（SAN）。 若要透過因特網連線，請使用外部IP新增 --san 。 --no-password --insecure旗標用於測試以略過密碼提示，並停用私鑰的密碼保護，因為它儲存在 Kubernetes 秘密中。 針對生產環境，請使用密碼，並將私鑰儲存在安全的位置，例如 Azure 金鑰保存庫。

憑證金鑰演演算法需求

支援 EC 和 RSA 金鑰，但鏈結中的所有憑證都必須使用相同的密鑰演演算法。 如果您匯入自己的 CA 憑證，請確定伺服器證書使用與 CA 相同的密鑰演演算法。

將伺服器證書鏈結匯入為 Kubernetes 秘密

  1. 建立完整的伺服器證書鏈結，其中憑證的順序很重要：伺服器證書是檔案中的第一個憑證，中繼是第二個。

    cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.pem

  2. 使用 kubectl 建立具有伺服器證書鏈結和伺服器密鑰的 Kubernetes 秘密。

    kubectl create secret tls server-cert-secret -n azure-iot-operations \
--cert server_chain.crt \
--key mqtts-endpoint.key

為接聽程式啟用 TLS

tls修改 BrokerListener 資源中的設定，以指定參考 Kubernetes 秘密的手動 TLS 組態。 請注意用於 TLS 伺服器證書的秘密名稱（server-cert-secret 先前的範例中）。

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: manual-tls-listener
  namespace: azure-iot-operations
spec:
  brokerRef: broker
  authenticationEnabled: false # If true, BrokerAuthentication must be configured
  authorizationEnabled: false
  serviceType: loadBalancer # Optional, defaults to clusterIP
  serviceName: mqtts-endpoint # Match the SAN in the server certificate
  port: 8885 # Avoid port conflict with default listener at 8883
  tls:
    manual:
      secretName: server-cert-secret

建立 BrokerListener 資源之後，操作員會自動建立 Kubernetes 服務並部署接聽程式。 您可以執行 kubectl get svc來檢查服務的狀態。

使用 TLS 向訊息代理程式 連線

若要測試與 mosquitto 用戶端的 TLS 連線，請發布訊息，並在 參數 --cafile中傳遞根 CA 憑證。

$ mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile root_ca.crt
Client my-client sending CONNECT
Client my-client received CONNACK (0)
Client my-client sending PUBLISH (d0, q0, r0, m1, 'test-topic', ... (5 bytes))
Client my-client sending DISCONNECT

提示

若要使用localhost，必須在主電腦上使用埠。 例如： kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations 。 透過 K3d 等一些 Kubernetes 散發套件，您可以使用 來新增轉送的埠 k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer。

注意

若要連線到訊息代理程式，您必須將信任根發佈至用戶端，也稱為信任套件組合。 在此情況下，信任的根目錄是自我簽署根 CA 建立的步驟 CLI。 用戶端需要散發信任根目錄，才能驗證伺服器證書鏈結。 如果您的 MQTT 用戶端是 Kubernetes 叢集上的工作負載，您也需要使用根 CA 建立 ConfigMap，並將其掛接在您的 Pod 中。

請記得在啟用 MQ 驗證時指定使用者名稱、密碼等。

針對伺服器證書使用外部IP

若要透過因特網與 TLS 連線，Azure IoT MQ 的伺服器證書必須將其外部主機名設為 SAN。 在生產環境中，這通常是 DNS 名稱或已知的 IP 位址。 不過，在開發/測試期間，您可能不知道在部署之前指派了哪些主機名或外部IP。 若要解決此問題，請先部署不含伺服器證書的接聽程式，然後使用外部IP建立伺服器證書和秘密，最後將秘密匯入接聽程式。

如果您嘗試部署範例 TLS 接聽程式 manual-tls-listener ，但參考的 Kubernetes 秘密 server-cert-secret 不存在，則會建立相關聯的服務，但 Pod 不會啟動。 因為操作員需要保留接聽程式的外部IP，因此會建立服務。

$ kubectl get svc mqtts-endpoint -n azure-iot-operations
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.43.93.6      172.18.0.2    8885:30674/TCP      1m15s

不過，這是預期的行為，而且我們可以在匯入伺服器證書時保留它。 健康情況管理員記錄提到 Azure IoT MQ 正在等候伺服器證書。

$ kubectl logs -l app=health-manager -n azure-iot-operations
...
<6>2023-11-06T21:36:13.634Z [INFO] [1] - Server certificate server-cert-secret not found. Awaiting creation of secret.

注意

一般而言，在分散式系統中，Pod 記錄並不具決定性，而且應該謹慎使用。 這類信息呈現的正確方式是透過 Kubernetes 事件和自定義資源狀態，也就是待辦專案。 請將上一個步驟視為暫時的因應措施。

即使前端 Pod 未啟動，但外部 IP 已可供使用。

$ kubectl get svc mqtts-endpoint -n azure-iot-operations
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.43.93.6      172.18.0.2    8885:30674/TCP      1m15s

從這裡，遵循與先前相同的步驟，在 中建立具有此外部IP --san 的伺服器證書，並以相同的方式建立 Kubernetes 秘密。 一旦建立秘密，它就會自動匯入至接聽程式。

相關內容