将 TLS 与消息拓扑 Kubernetes Operator 结合使用

如果消息拓扑 Operator 管理的 RabbitmqClusters 被配置为通过 HTTPS 提供 HTTP API 和管理 UI，那么拓扑 Operator 就有 信任签名了 RabbitmqClusters 使用的 TLS 证书的证书颁发机构 (CA) 的必要。

一个或多个受信任的证书必须挂载为卷，到位于 /etc/ssl/certs/ 的拓扑 Operator Pod 的信任存储中。

先决条件

本指南假设您拥有以下内容

1. RabbitMQ Cluster Operator 和 Messaging Topology Operator 已安装在 Kubernetes 集群中
2. 一个已签名的 TLS 证书和私钥，供 RabbitmqCluster 用于提供流量
3. 一个 CA 的 TLS 证书，该 CA 签名了服务器证书和密钥，其路径导出为 $CA_PATH

步骤

1. 通过遵循 Cluster Operator 示例中记录的示例，创建一个通过 TLS 提供流量的 RabbitmqCluster。
2. 创建一个 Kubernetes Secret，其中包含签名了 RabbitMQ 服务器证书的 CA 的证书。

例如：

kubectl -n rabbitmq-system create secret generic rabbitmq-ca --from-file=ca.crt=$CA_PATH

3. 将此 Secret 挂载到消息拓扑 Operator Pod 的信任存储中。可以通过编辑 Deployment manifest 或通过 kubectl 应用补丁来完成此操作。

kubectl -n rabbitmq-system patch deployment messaging-topology-operator --patch "spec:
  template:
    spec:
      containers:
      - name: manager
        volumeMounts:
        - mountPath: /etc/ssl/certs/rabbitmq-ca.crt
          name: rabbitmq-ca
          subPath: ca.crt
      volumes:
      - name: rabbitmq-ca
        secret:
          defaultMode: 420
          secretName: rabbitmq-ca"

拓扑 Operator Pod 将被重新创建，并将信任新挂载的 CA 签名的证书。Pod 与 RabbitmqCluster 的任何通信都将通过 HTTPS 进行。

限制

• 消息拓扑 Operator 将无法管理未按上述方式挂载其 CA 的 RabbitmqClusters：这些节点将无法通过 HTTPS 接受客户端连接。
• 已禁用 TLS 的 RabbitmqClusters（即 .spec.tls 下未配置任何内容）将始终通过 HTTP 进行管理。