Це буде дуже коротка стаття про мережі мостів Docker.
Коли ви виконуєте цю команду:
docker network ls
ви побачите, що є попередньо визначена мережа за замовчуванням "bridge", і ви не зможете її видалити, навіть якщо захочете.
NETWORK ID NAME DRIVER SCOPE
b721b3ac9775 bridge bridge local
9286085e1ff0 host host local
f2a02f9b2c01 none null local
Отже, припустимо, що ми хочемо створити два контейнери. Ні... насправді три контейнери: один — це frontend, інший — backend, а ще один — для сервісу оплати.
docker run -d — name frontend nginx:latest
Бум!! Ми створили перший контейнер, який працює в відокремленому режимі, і він містить сервер nginx. Тепер давайте створимо ще два:
docker run -d — name backend nginx:latest
docker run -d — name payment-service nginx:latest
Отже, всі три контейнери тепер працюють.
Тепер давайте подивимось на IP-адресу нашого контейнера frontend. Як це зробити? Не хвилюйтесь, я вас допоможу.
Використовуйте:
docker inspect frontend
Десь внизу вашої відповіді у форматі JSON ви побачите IP-адресу, щось на кшталт 172.a.b.c (вважайте це прикладом). Інший спосіб побачити IP — це виконати ці команди одну за одною:
docker exec -it frontend /bin/bash
apt update
apt install net-tools
ifconfig
Тепер тим же способом подивіться IP-адресу контейнера backend, яка може бути чимось на кшталт 172.a.b.c1 (наприклад).
Тепер спробуйте пінгувати контейнер backend зсередини контейнера frontend, і ви побачите, що вони можуть взаємодіяти.
Зачекайте!! Як це працює? Я маю на увазі, коли ви спочатку створили ці контейнери без вказівки будь-яких інших мереж, Docker додав їх у свою стандартну мережу bridge, яка також називається bridge.
Тепер, якщо ви створите кілька контейнерів таким чином, вони зможуть взаємодіяти між собою, і це саме поведінка та мета мережі bridge.
Але зачекайте! У вашій системі є контейнер під назвою payment-service. Ой!! Серйозний контейнер, який містить конфіденційну інформацію, і ви не хочете з цим жартувати. Ну, якщо цей контейнер також знаходиться в тій самій стандартній мережі bridge, це означає, що інші контейнери також можуть до нього дістатись, правильно? Так, вони можуть. Але у вас є побоювання щодо безпеки. Ви не хочете, щоб зловмисник отримав доступ до вашого контейнера для оплат, навіть якщо йому вдасться отримати доступ до інших ваших контейнерів.
Так, для цього є рішення.
Це буде дуже коротка стаття про мережі мостів Docker.
Коли ви виконуєте цю команду:
docker network ls
ви можете побачити, що вже існує попередньо визначена мережа за замовчуванням "bridge", і ви не зможете її видалити, навіть якщо захочете.
NETWORK ID NAME DRIVER SCOPE
b721b3ac9775 bridge bridge local
9286085e1ff0 host host local
f2a02f9b2c01 none null local
Отже, припустимо, що ми хочемо створити два контейнери. Ні… насправді три контейнери: один — це frontend, інший — backend, а ще один — для сервісу оплати.
docker run -d — name frontend nginx:latest
Бум!! Ми створили перший контейнер, який працює в відокремленому режимі, і він містить сервер nginx. Тепер давайте створимо ще два:
docker run -d — name backend nginx:latest
docker run -d — name payment-service nginx:latest
Отже, всі три контейнери тепер працюють.
Тепер давайте подивимось на IP-адресу нашого контейнера frontend. Як це зробити? Не хвилюйтесь, я вас допоможу.
Використовуйте:
docker inspect frontend
Десь внизу вашої відповіді у форматі JSON ви побачите IP-адресу, щось на кшталт 172.a.b.c (вважайте це прикладом). Інший спосіб побачити IP — це виконати ці команди одну за одною:
docker exec -it frontend /bin/bash
apt update
apt install net-tools
ifconfig
Тепер тим же способом подивіться IP-адресу контейнера backend, яка може бути чимось на кшталт 172.a.b.c1 (наприклад).
Тепер спробуйте пінгувати контейнер backend зсередини контейнера frontend, і ви побачите, що вони можуть взаємодіяти.
Зачекайте!! Як це працює? Я маю на увазі, коли ви спочатку створили ці контейнери без вказівки будь-яких інших мереж, Docker додав їх у свою стандартну мережу bridge, яка також називається bridge.
Тепер, якщо ви створите кілька контейнерів таким чином, вони зможуть взаємодіяти між собою, і це саме поведінка та мета мережі bridge.
Але зачекайте! У вашій системі є контейнер під назвою payment-service. Ой!! Серйозний контейнер, який містить конфіденційну інформацію, і ви не хочете з цим жартувати. Ну, якщо цей контейнер також знаходиться в тій самій стандартній мережі bridge, це означає, що інші контейнери також можуть до нього дістатись, правильно? Так, вони можуть. Але у вас є побоювання щодо безпеки. Ви не хочете, щоб зловмисник отримав доступ до вашого контейнера для оплат, навіть якщо йому вдасться отримати доступ до інших ваших контейнерів.
Так, для цього є рішення.
Ви можете ізолювати цей контейнер, використовуючи свою власну мережу моста.
Давайте це зробимо, створимо власну мережу моста за допомогою цієї команди:
docker network create custom-bridge
docker network ls
Тепер ви побачите вашу мережу custom-bridge в списку.
❯ docker network create custom-bridge
94a0fdbeb3c2ddf6053ad1fbdbf93cbfd025bf3f5903e0ef385e28a5faa25524
❯ docker network ls
NETWORK ID NAME DRIVER SCOPE
5f41e5e64fb8 bridge bridge local
94a0fdbeb3c2 custom-bridge bridge local
9286085e1ff0 host host local
f2a02f9b2c01 none null local
Тепер давайте відключимо контейнер payment-service від стандартної мережі моста:
docker network disconnect bridge payment-service
Чому б не перевірити, що він дійсно відключений від мережі?
docker inspect payment-service
Внизу ви побачите, що IP-адреса не призначена.
Тепер призначимо його до вашої мережі custom-bridge:
> docker network connect custom-bridge payment-service
> docker inspect payment-service
json
“Networks”: {
“custom-bridge”: {
“IPAMConfig”: {},
“Links”: null,
“Aliases”: [
“af2aa6559bb3”
],
“NetworkID”: “94a0fdbeb3c2ddf6053ad1fbdbf93cbfd025bf3f5903e0ef385e28a5faa25524”,
“EndpointID”: “f7427aa8b73bdaa8c43459f9c95ea90024e98773e244da07b439281e3b2d44b3”,
“Gateway”: “172.18.0.1”,
“IPAddress”: “172.18.0.2”,
“IPPrefixLen”: 16,
“IPv6Gateway”: “”,
“GlobalIPv6Address”: “”,
“GlobalIPv6PrefixLen”: 0,
“MacAddress”: “02:42:ac:12:00:02”,
“DriverOpts”: {}
}
}
Тепер контейнер знаходиться в мережі custom-bridge.
Тепер спробуйте пінгувати цю IP-адресу з одного з ваших контейнерів, що знаходяться в стандартній мережі моста, і ви більше не зможете підключитися до нього.
Ви можете ізолювати цей контейнер за допомогою вашої власної мережі моста.
Давайте зробимо це, створимо власну мережу моста за допомогою цієї команди:
docker network create custom-bridge
docker network ls
Тепер ви можете побачити вашу мережу custom-bridge прямо там.
❯ docker network create custom-bridge
94a0fdbeb3c2ddf6053ad1fbdbf93cbfd025bf3f5903e0ef385e28a5faa25524
❯ docker network ls
NETWORK ID NAME DRIVER SCOPE
5f41e5e64fb8 bridge bridge local
94a0fdbeb3c2 custom-bridge bridge local
9286085e1ff0 host host local
f2a02f9b2c01 none null local
Тепер давайте відключимо контейнер payment-service від мережі за замовчуванням:
docker network disconnect bridge payment-service
Ну, давайте перевіримо, чи справді він відключений від мережі:
docker inspect payment-service
Внизу ви побачите, що IP не призначено.
Тепер приєднаємо його до вашої мережі custom-bridge:
> docker network connect custom-bridge payment-service
> docker inspect payment-service
json
“Networks”: {
“custom-bridge”: {
“IPAMConfig”: {},
“Links”: null,
“Aliases”: [
“af2aa6559bb3”
],
“NetworkID”: “94a0fdbeb3c2ddf6053ad1fbdbf93cbfd025bf3f5903e0ef385e28a5faa25524”,
“EndpointID”: “f7427aa8b73bdaa8c43459f9c95ea90024e98773e244da07b439281e3b2d44b3”,
“Gateway”: “172.18.0.1”,
“IPAddress”: “172.18.0.2”,
“IPPrefixLen”: 16,
“IPv6Gateway”: “”,
“GlobalIPv6Address”: “”,
“GlobalIPv6PrefixLen”: 0,
“MacAddress”: “02:42:ac:12:00:02”,
“DriverOpts”: {}
}
}
Тепер він знаходиться в мережі custom-bridge.
Тепер спробуйте здійснити пінг за допомогою цього IP з одного з ваших контейнерів, що знаходиться в мережі за замовчуванням, і ви побачите, що підключитися до нього більше не вдасться.
Перекладено з: Isolating Sensitive Services with Docker Custom Bridge Networks