В Altenar мы часто используем RabbitMQ как точку входа для наших продуктов. В данном случае речь пойдет о системе, которая рассчитывает спортивные данные и предоставляет их как внутренним системам организации, так и внешним пользователям за её пределами. При проектировании системы для компонента RabbitMQ были определены следующие требования:

Endpoint защищён SSL-сертификатом.
RabbitMQ размещён в Kubernetes. Мы используем RabbitMQ cluster operator и RabbitMQ messaging topology operator.
Для этого проекта мы используем Google Cloud. Как и в случае с Let’s Encrypt, вы можете использовать управляемый SSL-сертификат Google Managed SSL Certificate для любого публичного HTTP Load Balancer в Google Cloud. Однако у такого подхода есть несколько ограничений, основные из которых:
- Работает только с HTTP Load Balancer.
- Работает только с публичными Load Balancer.

Согласно документации RabbitMQ, существует два распространённых подхода для подключения клиентов:

Настроить RabbitMQ для обработки TLS-подключений.
Использовать прокси или load balancer (например, HAproxy) для выполнения TLS-терминации клиентских подключений и использовать обычные TCP-подключения к узлам RabbitMQ.

Мы планировали использовать Google Managed Certificate для TCP/SSL Proxy Load Balancer в Google Cloud. Однако из-за вышеупомянутых ограничений управляемые сертификаты не поддерживаются для TCP Load Balancer. С другой стороны, Google позволяет использовать SSL-сертификаты для нескольких типов Load Balancer, что мы решили изучить. В результате итоговый проект выглядел бы следующим образом:

Мы хотели создать стандартный HTTP-сервис заглушку, который был бы доступен на порту 443 и использовался для управления SSL-сертификатом и его автоматического обновления.

При этом мы планировали иметь отдельный endpoint, который бы использовал тот же IP-адрес и тот же SSL-сертификат.

Рассмотрим каждую часть решения подробнее.

GKE Кластер

В качестве основной хостинг-платформы мы используем GKE (Google Kubernetes Engine). Мы используем Google Terraform module для настройки приватного GKE-кластера, конфигурируем Workload Identity и устанавливаем AutoNEG controller в кластер.

Мы не будем углубляться в детали работы Workload Identity с AutoNEG в этой статье, так как они используются в соответствии с официальной документацией.

После выполнения всех подготовительных шагов мы разворачиваем сервис-заглушку “Hello World” в кластере и подключаем его к Google Load Balancer с помощью AutoNEG. Ниже представлен YAML-конфигурация для этого:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gcp-tls-certificate-issuer
  labels:
    app: gcp-tls-certificate-issuer
  annotations:
    deployment.kubernetes.io/revision: '1'
spec:
  replicas: 2
  selector:
    matchLabels:
      app: gcp-tls-certificate-issuer
  template:
    metadata:
      labels:
        app: gcp-tls-certificate-issuer
    spec:
      containers:
        - name: ok
          image: assemblyline/ok:latest
          ports:
            - containerPort: 8888
              protocol: TCP
          imagePullPolicy: Always
          securityContext:
            capabilities:
              drop:
                - ALL
            runAsUser: 1000
            runAsGroup: 3000
            runAsNonRoot: true
            readOnlyRootFilesystem: true
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  revisionHistoryLimit: 10
  progressDeadlineSeconds: 600
---
apiVersion: v1
kind: Service
metadata:
  name: gcp-tls-certificate-issuer
  labels:
    app: gcp-tls-certificate-issuer
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"8888":{"name": "gcp-tls-certificate-issuer"}}}'
    controller.autoneg.dev/neg: '{"backend_services":{"8888":[{"name":"envcode-rabbit-https-backend-service","max_connections_per_endpoint":10000}]}}'
spec:
  ports:
    - name: http
      protocol: TCP
      port: 8888
      targetPort: 8888
  selector:
    app: gcp-tls-certificate-issuer
  clusterIP: 10.10.12.130
  clusterIPs:
    - 10.10.12.130
  type: ClusterIP

Обратите внимание на аннотацию в конфигурации Service. Именно через неё AutoNEG добавляет этот сервис в Google Load Balancer как backend.

Google Load Balancer

Следующая часть настраивается вне GKE и создаётся отдельно. Google Load Balancer — это не единый объект, а набор различных объектов, объединённых вместе. Ниже представлен код Terraform с комментариями:

resource "google_compute_managed_ssl_certificate" "rabbitmq" {
  project = var.project
  name    = "${var.environment_name}-google-managed-certificate-rabbitmq"

  managed {
    domains = ["rabitmq.example.com."]  # Replace with your domain
  }
}

# reserved IP address
resource "google_compute_global_address" "default" {
  project = var.project
  name    = "tcp-proxy-xlb-ip"
}

output "rabbitmq-ip" {
  value = google_compute_global_address.default.address
}

# forwarding rule for TCP Loadbalanser
resource "google_compute_global_forwarding_rule" "default" {
  project               = var.project
  name                  = "${var.environment_name}-tcp-global-loadbalancer"
  provider              = google
  ip_protocol           = "TCP"
  load_balancing_scheme = "EXTERNAL"
  port_range            = "5671"
  target                = google_compute_target_ssl_proxy.default.id
  ip_address            = google_compute_global_address.default.id
}
# https://cloud.google.com/load-balancing/docs/ssl
# When you use Google-managed SSL certificates with SSL Proxy Load Balancing, the frontend port for traffic must be 443 to enable the Google-managed SSL certificates to be provisioned and renewed.

# forwarding rule for HTTPS Loadbalanser
resource "google_compute_global_forwarding_rule" "https" {
  project               = var.project
  name                  = "${var.environment_name}-https-global-loadbalancer"
  provider              = google
  ip_protocol           = "TCP"
  load_balancing_scheme = "EXTERNAL"
  port_range            = "443"
  target                = google_compute_target_ssl_proxy.https.id
  ip_address            = google_compute_global_address.default.id
}

resource "google_compute_target_ssl_proxy" "default" {
  project          = var.project
  name             = "${var.environment_name}-global-loadbalancer-tcp-proxy"
  backend_service  = google_compute_backend_service.default.id
  ssl_certificates = [google_compute_managed_ssl_certificate.rabbitmq.id]
}

resource "google_compute_target_ssl_proxy" "https" {
  project          = var.project
  name             = "${var.environment_name}-global-loadbalancer-https-proxy"
  backend_service  = google_compute_backend_service.https.id
  ssl_certificates = [google_compute_managed_ssl_certificate.rabbitmq.id]
}

# backend service For RabbitMQ Autoneg
resource "google_compute_backend_service" "default" {
  project = var.project
  name    = "${var.environment_name}-tcp-backend-service"
  protocol              = "TCP"
  port_name             = "tcp"
  load_balancing_scheme = "EXTERNAL"
  timeout_sec           = 10
  health_checks         = [google_compute_health_check.default.id]
  session_affinity      = "CLIENT_IP"

  # We don't want TF to remove whatever was configured by AutoNEG
  lifecycle {
    ignore_changes = [backend]
  }
}

# backend service For HTTPS Autoneg
resource "google_compute_backend_service" "https" {
  project               = var.project

                          #that's what you use in the service annotations
  name                  = "${var.environment_name}-https-backend-service"  
  protocol              = "TCP"
  port_name             = "tcp"
  load_balancing_scheme = "EXTERNAL"
  timeout_sec           = 10
  health_checks         = [google_compute_health_check.https.id]

  # We don't want TF to remove whatever was configured by AutoNEG
  lifecycle {
    ignore_changes = [backend]
  }
}

resource "google_compute_health_check" "default" {
  project            = var.project
  name               = "tcp-proxy-health-check"
  description        = "Backend service for AutoNEG"
  timeout_sec        = 1
  check_interval_sec = 1

  tcp_health_check {
    port = "5672" #use container port
  }
}

resource "google_compute_health_check" "https" {
  project            = var.project
  name               = "https-proxy-health-check"
  description        = "Backend service for AutoNEG"
  timeout_sec        = 1
  check_interval_sec = 1

  tcp_health_check {
    port = "8888" #use container port
  }
}

Как вы можете видеть, мы создали один IP-адрес и один SSL-сертификат, а затем использовали их в двух правилах перенаправления (forwarding rules). Это позволило нам использовать управляемый SSL-сертификат для TCP Load Balancer.

Не забудьте настроить DNS и указать IP-адрес на правильное имя хоста, чтобы всё заработало.

Совет: В GKE есть deployment l7-default-backend. Возможно, было бы достаточно создать сервис с аннотациями AutoNEG и направить его на pod-ы этого deployment. Попробуйте это и сообщите в комментариях, если это работает.

Управляемый SSL сертификат для TCP лоадбалансера в Kubernetes