Управление пользователями и разрешениями RabbitMQ: руководство по командной строке

Разрешения RabbitMQ легко настроить почти правильно. Пользователь может существовать и все равно не иметь возможности публиковать сообщения. Пользователь может иметь тег management и все равно не иметь доступа к виртуальному хосту приложения. Широкое регулярное выражение может случайно позволить сервису создавать очереди, которые он должен только потреблять. Большинство проблем с разрешениями возникает из-за путаницы трех отдельных понятий: пользователей, тегов и разрешений виртуальных хостов.

Это руководство использует rabbitmqctl для типичного рабочего процесса администрирования пользователей: создание пользователей, назначение тегов, установка разрешений виртуальных хостов, проверка доступа, ротация паролей и чистое удаление доступа.

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

Перед началом убедитесь, что у вас есть следующее:

Установленный сервер RabbitMQ: Брокер должен быть запущен.
Доступ к rabbitmqctl: Вам нужен административный доступ к узлу или кластеру. Команды обычно выполняются на узле RabbitMQ, хотя удаленное использование CLI возможно, если среда настроена для этого.
Правильное имя виртуального хоста: Разрешения действуют в рамках каждого виртуального хоста. /, /prod и prod не взаимозаменяемы.

Управление пользователями с помощью `rabbitmqctl`

Инструмент rabbitmqctl использует семейство команд user_* для всех операций, связанных с пользователями. Важно понимать, что пользователи RabbitMQ отличаются от пользователей операционной системы.

1. Список существующих пользователей

Чтобы увидеть, кто в настоящее время имеет доступ к брокеру, используйте команду list_users:

rabbitmqctl list_users

Пример вывода:

Listing users ...
user: guest   tags: [administrator]
user: app_prod tags: [policymaker]

2. Создание нового пользователя

При настройке новой учетной записи службы или администратора необходимо создать пользователя и назначить начальный пароль.

Чтобы создать пользователя с именем api_user и начальным паролем:

rabbitmqctl add_user api_user 'replace-with-a-long-random-password'

Избегайте помещения реальных производственных паролей в историю оболочки. В автоматизированных системах предпочитайте использовать менеджер секретов и механизм подготовки, который уже используется вашей платформой.

3. Изменение тегов пользователя (ролей)

Теги пользователей определяют предопределенные роли, которые предоставляют определенные административные возможности. Наиболее распространенными тегами являются administrator, policymaker и management.

administrator: может управлять пользователями, разрешениями, виртуальными хостами, политиками и настройками всего кластера.
policymaker: может управлять политиками и параметрами для виртуальных хостов, к которым у пользователя есть доступ.
management: может войти в интерфейс управления/API, но разрешения виртуальных хостов по-прежнему контролируют, какие ресурсы может использовать пользователь.
monitoring: может просматривать информацию управления, полезно для учетных записей наблюдения.

Просмотр текущих тегов

Используйте list_user_tags, чтобы увидеть текущие роли:

rabbitmqctl list_user_tags api_user

Установка тегов

Чтобы назначить тег management пользователю api_user:

rabbitmqctl set_user_tags api_user management

set_user_tags заменяет список тегов пользователя именно теми тегами, которые вы предоставляете. Чтобы дать оба тега administrator и policymaker, включите оба в одну команду:

rabbitmqctl set_user_tags api_user administrator policymaker

Удаление тегов

Чтобы удалить все теги у пользователя:

rabbitmqctl set_user_tags api_user

Некоторые версии RabbitMQ также предоставляют clear_user_tags. Проверьте rabbitmqctl help clear_user_tags в вашей установленной версии, прежде чем использовать его в скриптах.

4. Изменение пароля пользователя

Если требуется ротация учетных данных, используйте команду change_password:

rabbitmqctl change_password api_user newsecurepass123

5. Удаление пользователя

Чтобы полностью удалить пользователя и отозвать весь связанный доступ:

rabbitmqctl delete_user api_user

Предупреждение: Удаление пользователя guest обычно рекомендуется в производственных средах по соображениям безопасности, хотя для этого сначала необходимо создать нового административного пользователя.

Управление разрешениями виртуальных хостов

Разрешения в RabbitMQ определяются для каждого виртуального хоста (vhost). Виртуальный хост действует как пространство имен для очередей, обменов и привязок. По умолчанию RabbitMQ имеет корневой виртуальный хост с именем /.

1. Список виртуальных хостов

Сначала определите доступные виртуальные хосты:

rabbitmqctl list_vhosts

2. Установка разрешений для пользователя на виртуальном хосте

Команда set_permissions является наиболее важной для безопасности приложений. Она предоставляет пользователю права на настройку, чтение или запись ресурсов в рамках определенного виртуального хоста.

Синтаксис: rabbitmqctl set_permissions -p <vhost> <user> <configure> <write> <read>

Значения разрешений — это регулярные выражения. .* означает все имена ресурсов. ^$ означает отсутствие имен ресурсов.

Пример: Предоставление полного доступа к определенному виртуальному хосту

Если мы хотим, чтобы app_prod имел полный CRUD-доступ (настройка, чтение, запись) только к /prod_vhost:

rabbitmqctl set_permissions -p /prod_vhost app_prod "^.*" "^.*" "^.*"

Разрешение	Значение	Типичное использование
Configure	Создание, удаление или изменение очередей, обменов и привязок, соответствующих регулярному выражению.	Развертывающие или приложения, которые объявляют свою собственную топологию.
Write	Публикация в соответствующие обмены.	Производители.
Read	Потребление из соответствующих очередей.	Потребители.

Пример: Ограничение пользователя только публикацией

Распространенный шаблон для производителей firehose — ограничение их только записью:

# Пользователь 'publisher' может писать, но не может настраивать или читать сообщения в /analytics_vhost
rabbitmqctl set_permissions -p /analytics_vhost publisher "^$" "^events\\." "^$"

Этот пример разрешает публикацию в обмены, имена которых начинаются с events.. Он не позволяет пользователю настраивать топологию или потреблять сообщения.

Пример: Ограничение потребителя

# Может читать из очередей, начинающихся с worker., но не может публиковать или настраивать
rabbitmqctl set_permissions -p /jobs worker_consumer "^$" "^$" "^worker\."

Разрешения на основе регулярных выражений мощны, но их легко сделать слишком широкими. Если ваши очереди называются prod.orders.created и staging.orders.created в одном виртуальном хосте, регулярное выражение типа .*orders.* может охватить больше, чем предполагалось. Отдельные виртуальные хосты обычно чище, чем сложные границы регулярных выражений.

3. Очистка разрешений

Чтобы полностью удалить все разрешения, которые есть у пользователя на определенном виртуальном хосте, используйте clear_permissions:

rabbitmqctl clear_permissions -p /prod_vhost app_prod

4. Список разрешений пользователя

Чтобы проверить разрешения, предоставленные на виртуальном хосте:

rabbitmqctl list_permissions -p /prod_vhost

Чтобы увидеть все разрешения, назначенные одному пользователю на всех виртуальных хостах:

rabbitmqctl list_user_permissions app_prod

Лучшие практики администрирования пользователей

Используйте наименьшие привилегии: производителям обычно нужно разрешение на запись, потребителям — на чтение, и только владельцам топологии — на настройку.
Используйте выделенные виртуальные хосты: разделяйте среды и арендаторов с помощью виртуальных хостов вместо попыток решить все с помощью регулярных выражений.
Обращайтесь с guest осознанно: по умолчанию пользователь guest ограничен localhost. Многие производственные команды удаляют его после создания реальной учетной записи администратора.
Скриптуйте желаемое состояние: храните настройку пользователей, виртуальных хостов и разрешений в автоматизации развертывания, чтобы восстановленный брокер не зависел от памяти.
Проверяйте после изменений: выполняйте list_users, list_permissions и list_user_permissions после каждого изменения в производственной среде.

Практическая настройка приложения часто выглядит так:

rabbitmqctl add_vhost /orders
rabbitmqctl add_user orders_publisher 'replace-with-secret'
rabbitmqctl add_user orders_worker 'replace-with-secret'

rabbitmqctl set_permissions -p /orders orders_publisher "^$" "^orders\\." "^$"
rabbitmqctl set_permissions -p /orders orders_worker "^$" "^$" "^orders\\."

rabbitmqctl list_user_permissions orders_publisher
rabbitmqctl list_user_permissions orders_worker

Это позволяет хранить учетные данные для публикации и потребления отдельно. Если пароль рабочего процесса утечет, он не сможет публиковать новые сообщения. Если пароль издателя утечет, он не сможет очищать очереди. Это разделение простое, но это одна из самых полезных привычек безопасности RabbitMQ.