#Безопасные клиентские подключения с TLS

Используйте TLS, когда производители, потребители, средства автоматизации или администраторы подключаются к RabbitMQ через недоверенную сеть, через внешний NodePort или LoadBalancer, либо между кластерами. TLS защищает трафик AMQP и HTTP API управления от передачи в открытом виде.

В этом руководстве описан TLS для RabbitMQ listener, предназначенного для клиентского доступа. Оно не заменяет управление пользователями, виртуальными хостами или правами доступа. Для production-нагрузок настраивайте и TLS, и пользователей RabbitMQ с минимально необходимыми привилегиями.

#Предварительные требования

Перед включением TLS убедитесь, что выполнены следующие условия:

1. У вас есть экземпляр RabbitmqCluster.
2. У вас есть серверный сертификат и закрытый ключ для имен доступа RabbitMQ, которые используют клиенты.
3. В Subject Alternative Name сертификата включены DNS-имена сервисов внутри кластера и любые внешние DNS-имена или IP-адреса, используемые клиентами.
4. Если клиентам необходимо проверять private CA, у вас есть CA certificate.
5. Приложения готовы использовать amqps:// и TLS endpoint управления после отключения non-TLS listeners.

#Процедура

#1. Создайте TLS secrets

Создайте TLS secret в том же namespace, что и RabbitmqCluster:

kubectl -n <namespace> create secret tls rabbitmq-server-tls \
  --cert=path/to/tls.crt \
  --key=path/to/tls.key

Если клиенты используют private CA, создайте CA secret:

kubectl -n <namespace> create secret generic rabbitmq-ca \
  --from-file=ca.crt=path/to/ca.crt

#2. Настройте RabbitmqCluster

Обновите RabbitmqCluster, чтобы он ссылался на TLS secret. Укажите caSecretName, когда брокер должен доверять private CA для mutual TLS или для соответствующих плагинов протоколов, таких как web_stomp и web_mqtt. Внешним клиентам AMQP или управления по-прежнему нужен CA certificate в их собственном trust store.

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: <instance-name>
  namespace: <namespace>
spec:
  tls:
    secretName: rabbitmq-server-tls
    caSecretName: rabbitmq-ca
    disableNonTLSListeners: true

Если вы мигрируете существующих клиентов, оставьте disableNonTLSListeners неуказанным или установите его в false на время миграции. После того как все клиенты начнут использовать TLS, измените значение поля на true.

#3. Дождитесь rollout

Дождитесь, пока экземпляр вернется в активную фазу, и все RabbitMQ Pod будут готовы:

kubectl -n <namespace> get rabbitmqcluster <instance-name>

kubectl -n <namespace> get pods \
  -l app.kubernetes.io/name=<instance-name>

#4. Проверьте TLS listeners

Проверьте список listeners из RabbitMQ Pod:

kubectl -n <namespace> exec <instance-name>-server-0 -- \
  rabbitmq-diagnostics listeners

Для конфигурации только с TLS вывод должен включать TLS listeners и больше не должен показывать обычные AMQP или HTTP listeners для отключенных протоколов.

Также проверьте порты Kubernetes Service, которые доступны клиентам:

kubectl -n <namespace> get svc <instance-name>

#5. Подключитесь с использованием TLS

Используйте amqps:// для клиентов AMQP:

amqps://<username>:<password>@<rabbitmq-host>:5671/%2f

%2f — это URL-encoded форма виртуального хоста / по умолчанию. Замените его на URL-encoded virtual host, который использует ваше приложение.

Используйте TLS options при запуске rabbitmqadmin через management API:

rabbitmqadmin \
  --host <rabbitmq-host> \
  --port <tls-management-port> \
  --ssl \
  --ssl-ca-cert-file path/to/ca.crt \
  --username <username> \
  --password <password> \
  list queues name messages consumers

Если путь к client certificate, key или CA указан неверно, rabbitmqadmin завершится с ошибкой до того, как сможет пройти аутентификацию в RabbitMQ.

#Проверка

После включения TLS выполните следующие проверки:

#Устранение неполадок

#Связанная информация

• Способы доступа
• Управление пользователями
• Подключение клиента
• Поддержка TLS в RabbitMQ