Ось готовий урок, створений спеціально для тебе у стилі CS50. Вмикай уяву, ми починаємо!

🎓 УРОК: Безпека RabbitMQ. Users, Vhosts, Permissions

Привіт, друзі! Радий бачити вас знову.

Сьогодні ми не просто пишемо код. Сьогодні ми стаємо архітекторами безпеки. Ми поговоримо про те, як захистити наш RabbitMQ від хаосу, випадкових помилок і, звісно, від "поганих хлопців".

Тема звучить серйозно — Users, Virtual Hosts та Permissions. Але, повірте, до кінця цього уроку ви будете керувати доступом так само легко, як відкриваєте двері власним ключем.

Поїхали! 🚀

1. 🔥 Вступ: Проблема «Гуртожитку»

Уявіть собі ситуацію. Ви працюєте над крутим стартапом. У вас є сервіс "Платежі" (дуже важливий!) і сервіс "Логи" (менш критичний).

Ви запускаєте RabbitMQ. За замовчуванням там є один користувач — guest з паролем guest. І ось ваші розробники, поспішаючи, використовують цей логін усюди.

А тепер уявіть, що стажер, який пише систему "Логи", випадково відправляє команду: "Видалити всі черги". Питання: Що станеться з чергами системи "Платежі", якщо вони всі сидять в одній кімнаті під одним акаунтом?

Правильно. Вони зникнуть. Платежі зупиняться. Бізнес втрачає гроші. Паніка.

Чому так сталося? Тому що наш RabbitMQ зараз схожий на студентський гуртожиток, де всі живуть в одній кімнаті, сплять на одному ліжку і користуються однією зубною щіткою. Це негігієнічно і небезпечно!

Нам потрібно перетворити цей "гуртожиток" на елітний готель, де кожен клієнт має свій номер, свій ключ і доступ лише до свого міні-бару.

Ось навіщо нам потрібні Users (Користувачі), Vhosts (Віртуальні хости) та Permissions (Права доступу). Без цього в продакшн йти не можна. Крапка.

2. 🧠 Теоретична база: Розділяй і володарюй

Давайте розберемо це на атоми. У RabbitMQ безпека будується на трьох китах.

🐳 Кит №1: Users (Користувачі)

Це найпростіше. Це відповідь на питання: "Хто ти?". Користувач має ім'я та пароль. * Інтуїтивно: Це як ваш паспорт на прохідній бізнес-центру. Охоронець дивиться і каже: "Ок, я знаю, хто ти, проходь". * Важливо: Сам по собі користувач ще нічого не може робити. Він просто існує.

🐳 Кит №2: Virtual Hosts (vhosts)

Це найважливіша концепція, яку часто ігнорують новачки. Vhost — це логічне розділення всередині одного RabbitMQ сервера.

Уявіть, що RabbitMQ — це фізична будівля (сервер). А vhosts — це окремі офіси різних компаній у цій будівлі. * Компанія А (vhost A) має свої черги та обмінники. * Компанія Б (vhost B) має свої. * Вони не бачать одне одного. Навіть якщо черги мають однакові назви, вони існують у паралельних всесвітах.

Під капотом: Це називається multi-tenancy (мульти-тенантність). Це дозволяє на одному "залізі" тримати тестове середовище (/dev), стейджинг (/staging) і продакшн (/prod) повністю ізольовано.

🐳 Кит №3: Permissions (Права доступу)

Ок, ви зайшли в будівлю (User), знайшли свій офіс (Vhost). А що ви можете там робити? Права у RabbitMQ визначаються трьома операціями: 1. Configure: Створювати/видаляти черги та обмінники. 2. Write: Публікувати повідомлення. 3. Read: Читати повідомлення з черг.

Фішка: Права задаються не просто "так/ні", а за допомогою Регулярних виразів (Regex). Ви можете дозволити писати тільки в черги, що починаються на logs.*, і заборонити чіпати orders.*.

3. 🧪 Приклади: Від `guest` до Admin

Ми будемо використовувати CLI (командний рядок), тому що справжні джедаї вміють працювати без графічного інтерфейсу. Але все це можна зробити і в RabbitMQ Management UI.

Приклад 1: Створення користувача

Зараз у нас є тільки guest. Давайте створимо окремого адміна.

# Створюємо юзера 'admin' з паролем 's3cr3t'
rabbitmqctl add_user admin s3cr3t

# Робимо його адміністратором (даємо тег)
rabbitmqctl set_user_tags admin administrator

Питання до вас: Як ви думаєте, чи зможе зараз цей admin щось прочитати з черги? Подумайте секунду...

Відповідь: Ні! Ми створили користувача, дали йому бейджик "Адміністратор", але ми не дали йому дозволу на доступ до жодного vhost. Він як директор, який стоїть у коридорі й не має ключів від кабінетів.

Приклад 2: Створення Віртуального Хоста (vhost)

Давайте створимо окремий простір для нашого додатку.

# Створюємо vhost з назвою 'my_app_prod'
rabbitmqctl add_vhost my_app_prod

Тепер у нас є чистий аркуш my_app_prod. Там порожньо. Жодних черг, жодних зв'язків. І, що важливо, ніхто (крім глобального адміна) туди не має доступу.

Приклад 3: Магія Permissions (Найскладніше)

Тепер поєднаємо юзера і vhost. Синтаксис команди такий: set_permissions [-p vhost] {user} {conf} {write} {read}

Де {conf}, {write}, {read} — це регулярні вирази.

Задача: Дати користувачу admin повний доступ до всього у my_app_prod.

rabbitmqctl set_permissions -p my_app_prod admin ".*" ".*" ".*"

Розбір: * ".*" — це регулярний вираз, що означає "будь-який рядок". * Ми дозволили конфігурувати все, писати у все, читати з усього.

А тепер складніше. Уявіть, що у нас є сервіс-аналітик reporter. Він має тільки читати дані і нічого не ламати.

# 1. Створюємо юзера
rabbitmqctl add_user reporter weakpass

# 2. Даємо права у my_app_prod
# Conf: "" (нічого не може створювати)
# Write: "" (нічого не може писати)
# Read: ".*" (може читати будь-яку чергу)
rabbitmqctl set_permissions -p my_app_prod reporter "" "" ".*"

Якщо reporter спробує створити чергу — він отримає помилку ACCESS_REFUSED. Безпека працює! 🎉

4. 🛠 Практична частина

Час забруднити руки. Відкривайте термінал (або уявіть, що відкрили). Ось ваші завдання:

Завдання 1: Kill the Guest За замовчуванням guest має повний доступ до всього, але тільки з localhost. Це діра в безпеці. * Створіть свого адміна. * Видаліть користувача guest командою rabbitmqctl delete_user guest. * Спробуйте залогінитися в UI під guest (має не вийти).

Завдання 2: Ізоляція середовищ Створіть два vhost: project_dev та project_prod. Створіть користувача dev_user. * Дайте йому повний доступ (".*" ".*" ".*") до project_dev. * Дайте йому доступ тільки на читання ("" "" ".*") до project_prod. * Перевірка: Спробуйте під цим юзером створити чергу в проді. Має бути відмова.

Завдання 3: Хірургічна точність (Regex) Створіть користувача logger. Дайте йому право писати (Write) тільки в черги, які починаються зі слова log. (наприклад, log.error, log.info). * Підказка: Регулярний вираз буде ^log\..*.

Завдання 4: Міні-кейс Ви — девопс. До вас прийшов розробник і каже: "Мені треба підключити мій мікросервіс, щоб він слухав чергу billing_tasks, але я боюся, що мій код випадково видалить цю чергу". * Які права (conf, write, read) ви йому дасте? Напишіть команду.

5. 💡 Мислення як у розробника

Як думає новачок?

"Ой, ці права такі складні. Я просто створю адміна, дам йому .* всюди і пропишу його в конфіги всіх мікросервісів. Працює ж!"

Це шлях до катастрофи. Якщо зламають один сервіс — отримають доступ до всієї системи.

Як думає досвідчений інженер (Senior)?

"Принцип найменших привілеїв (Least Privilege). Кожен сервіс має свого окремого користувача. Кожен користувач має доступ тільки до свого vhost. Якщо сервіс тільки читає — я забороню йому писати."

Поради з "полів": 1. Ніколи не використовуйте guest на віддалених серверах. RabbitMQ сам забороняє це, але не намагайтеся це обійти. 2. Називайте юзерів за іменем сервісів, а не людей. Не vasya, а payment_service. Вася звільниться, а сервіс залишиться. 3. Vhost в URL: Коли підключаєтесь в коді, vhost вказується після слешу. Увага! Якщо vhost називається / (дефолтний), то в URL це виглядає як %2f (url encoded). Це класична помилка новачків при підключенні.

6. 🧩 Підсумок

Отже, що ми сьогодні поклали у свою скарбничку знань:

Users — це ідентифікація (паспорт).
Vhosts — це ізоляція (окремі квартири). Це must-have для будь-якого проєкту.
Permissions — це регулювання дій (regex).

Тепер ви не просто "піднімаєте реббіт", ви будуєте захищену інфраструктуру. Ви можете сміливо запускати на одному сервері і розробку, і продакшн, не боячись, що вони перетнуться.

А що далі? Тепер, коли ми захищені, час подумати про надійність. Що станеться, якщо наш сервер RabbitMQ просто згорить? Фізично. Як зробити так, щоб повідомлення не зникли, а переїхали на інший сервер? На наступному уроці ми поговоримо про Кластеризацію та High Availability.

А поки — практикуйтесь, створюйте юзерів і не забувайте паролі! Це був CS50. Побачимось! 👋