Створення TLS для вихідного трафіку
Завдання Доступ до зовнішніх сервісів6 демонструє, як HTTP та HTTPS сервіси, що знаходяться поза межами сервісної мережі (service mesh), можуть бути доступні з застосунків всередині mesh. Як описано в цьому завданні, ServiceEntry
7 використовується для налаштування доступу до зовнішніх сервісів у контрольований спосіб через Istio. У цьому прикладі показано, як налаштувати Istio для виконання створення TLS для трафіку до зовнішнього сервісу. Istio відкриє HTTPS-зʼєднання із зовнішнім сервісом, тоді як оригінальний трафік буде HTTP.
Використання
Розглянемо приклад старого застосунку, який здійснює HTTP-запити до зовнішніх сайтів. Припустимо, організація, що керує застосунком, отримує нову вимогу, яка передбачає шифрування всього зовнішнього трафіку. З Istio цю вимогу можна реалізувати лише за допомогою конфігурації, без необхідності змінювати код застосунку. Застосунок може надсилати незашифровані HTTP-запити, а Istio зашифрує їх для нього.
Ще однією перевагою надсилання незашифрованих HTTP-запитів від джерела та дозволу Istio виконувати оновлення до TLS є те, що Istio може створювати кращу телеметрію та надавати більше контролю за маршрутизацією для запитів, які не зашифровані.
Перш ніж почати
Налаштуйте Istio, дотримуючись інструкцій з Посібника з встановлення8.
Запустіть демонстраційний застосунок curl9, який буде використовуватися як тестове джерело для зовнішніх викликів.
Якщо у вас увімкнено автоматичну інʼєкцію sidecar, виконайте наступну команду, розгорніть застосунок
curl
:В іншому випадку вам потрібно вручну виконати інʼєкцію sidecar перед розгортанням застосунку
curl
:Зверніть увагу, що будь-який pod, з якого ви можете виконати
exec
таcurl
, підійде для подальших процедур.Створіть змінну shell для збереження імені podʼа джерела для надсилання запитів до зовнішніх сервісів. Якщо ви використовували curl9, виконайте:
Налаштування доступу до зовнішнього сервісу
Спочатку налаштуйте доступ до зовнішнього сервісу, edition.cnn.com
, використовуючи ту саму техніку, що й у завданні Доступ до зовнішніх сервісів6. Цього разу, однак, використовуйте один ServiceEntry
для увімкнення як HTTP, так і HTTPS доступу до сервісу.
Створіть
ServiceEntry
, щоб увімкнути доступ доedition.cnn.com
:Зробіть запит до зовнішнього HTTP-сервісу:
Вихідні дані мають бути схожими на наведені вище (деякі деталі замінено на багатокрапки).
Зверніть увагу на прапорець -L
у curl, який вказує curl слідувати за перенаправленнями. У цьому випадку сервер повернув відповідь про перенаправлення (301 Moved Permanently11) на HTTP запит до http://edition.cnn.com/politics
. Відповідь про перенаправлення вказує клієнту надіслати додатковий запит, цього разу з використанням HTTPS, до https://edition.cnn.com/politics
. Для другого запиту сервер повернув запитуваний контент і статус-код 200 OK.
Хоча команда curl обробила перенаправлення прозоро, є дві проблеми. Перша проблема — це надмірний запит, який подвоює затримку при отриманні контенту з http://edition.cnn.com/politics
. Друга проблема полягає в тому, що шлях URL, politics у цьому випадку, надсилається у відкритому тексті. Якщо є зловмисник, який перехоплює комунікацію між вашим застосунком та edition.cnn.com
, зловмисник знатиме, які конкретні теми з edition.cnn.com
застосунок отримав. З міркувань конфіденційності ви можете захотіти запобігти такому розголошенню.
Обидві ці проблеми можна вирішити, налаштувавши Istio для виконання створення TLS (TLS origination).
Створення TLS для вихідного трафіку
Перевизначте ваш
ServiceEntry
з попереднього розділу, щоб перенаправляти HTTP-запити на порт 443 і додайтеDestinationRule
для виконання створення TLS:Вищевказане
DestinationRule
виконає створення TLS для HTTP-запитів на порту 80, аServiceEntry
буде перенаправляти запити на порт 80 на цільовий порт 443.Надішліть HTTP-запит на
http://edition.cnn.com/politics
, як у попередньому розділі:Цього разу ви отримали відповідь 200 OK як першу і єдину відповідь. Istio виконав TLS origination для curl, тому оригінальний HTTP запит був перенаправлений до
edition.cnn.com
як HTTPS. Сервер повернув контент без потреби в перенаправленні. Ви усунули подвійний обмін між клієнтом і сервером, а запит залишив мережу у зашифрованому вигляді, не розголошуючи, що ваш застосунок отримав розділ politics зedition.cnn.com
.Зверніть увагу, що ви використали ту ж команду, що і в попередньому розділі. Для застосунків, які отримують доступ до зовнішніх служб програмно, код змінювати не потрібно. Ви отримуєте переваги TLS origination, налаштувавши Istio, без потреби змінювати жодного рядка коду.
Зверніть увагу, що застосунки, які використовували HTTPS для доступу до зовнішнього сервісу, продовжують працювати як і раніше:
Додаткові міркування з безпеки
Оскільки трафік між застосунком та sidecar проксі на локальному хості все ще не зашифрований, зловмисник, який зможе проникнути на вузол вашого застосунку, зможе побачити нешифрований звʼязок в локальній мережі вузла. У деяких середовищах суворі вимоги до безпеки можуть вимагати, щоб весь трафік був зашифрований, навіть в локальній мережі вузлів. З такими суворими вимогами застосунки повинні використовувати лише HTTPS (TLS). TLS origination, описаний у цьому прикладі, не буде достатнім.
Також слід зазначити, що навіть з HTTPS, ініційованим застосунком, зловмисник може дізнатися, що запити до edition.cnn.com
надсилаються, перевіряючи Server Name Indication (SNI)12. Поле SNI надсилається нешифрованим під час рукостискання TLS. Використання HTTPS запобігає зловмисникам знати конкретні теми та статті, але не заважає зловмисникам дізнатися, що був виконаний доступ до edition.cnn.com
.
Видалення конфігурації TLS origination
Видаліть створені вами елементи конфігурації Istio:
Взаємний TLS для вихідного трафіку
У цьому розділі описується, як налаштувати sidecar для виконання TLS-автентифікації для зовнішнього сервісу, цього разу використовуючи сервіс, що потребує взаємної автентифікації TLS. Цей приклад значно складніший, оскільки він вимагає наступної конфігурації:
- Створення сертифікатів клієнта та сервера
- Розгортання зовнішнього сервісу, який підтримує протокол взаємної автентифікації TLS
- Налаштування клієнта (curl pod) на використання облікових даних, створених на Кроці 1
Коли ця конфігурація буде завершена, ви зможете налаштувати зовнішній трафік так, щоб він проходив через sidecar, який виконає TLS-автентифікацію.
Створення сертифікатів і ключів клієнта та сервера
Для цього завдання ви можете використовувати будь-який зручний для вас інструмент для створення сертифікатів і ключів. Команди нижче використовують openssl13.
Створіть кореневий сертифікат та приватний ключ для підписання сертифіката для ваших сервісів:
Створіть сертифікат і приватний ключ для
my-nginx.mesh-external.svc.cluster.local
:За бажанням ви можете додати
SubjectAltNames
до сертифіката, якщо хочете увімкнути перевірку SAN для місця призначення. Наприклад:Згенеруйте клієнтський сертифікат і приватний ключ:
Розгортання сервера з взаємною автентифікацією TLS
Щоб симулювати справжній зовнішній сервіс, який підтримує протокол взаємної автентифікації TLS, розгорніть сервер NGINX14 у вашому кластері Kubernetes, але запустіть його поза мережею сервісів Istio, тобто в просторі імен без увімкненого інжектора sidecar проксі Istio.
Створіть простір імен для представлення сервісів поза мережею Istio, а саме
mesh-external
. Зверніть увагу, що sidecar проксі не буде автоматично додаватися в podʼах цього простору імен, оскільки автоматична інʼєкція sidecar не була увімкнена для цього простору.Створіть Kubernetes [Secrets] (https://kubernetes.io/docs/concepts/configuration/secret/15) для зберігання сертифікатів сервера та центру сертифікації.
Створіть конфігураційний файл для сервера NGINX:
Створіть Kubernetes ConfigMap16 для зберігання конфігурації сервера NGINX:
Розгорніть сервер NGINX:
Налаштуйте клієнта (curl pod)
Створіть Kubernetes [Secrets] (https://kubernetes.io/docs/concepts/configuration/secret/15) для зберігання сертифікатів клієнта:
Секрет має бути створений у тому ж просторі імен, у якому розгорнуто клієнтський pod, у даному випадку
default
.Створіть необхідний
RBAC
, щоб переконатися, що секрет, створений на попередньому кроці, доступний клієнтському pod, який ’ у цьому випадку —curl
.
Налаштування взаємного TLS для вихідного трафіку на sidecar
Додайте
ServiceEntry
для перенаправлення HTTP-запитів на порт 443 і додайтеDestinationRule
для виконання взаємного TLS origination:Вищевказане правило
DestinationRule
виконає створення mTLS для HTTP-запитів на порт 80, аServiceEntry
буде перенаправляти запити на порт 80 на цільовий порт 443.Переконайтеся, що обліковий запис підʼєднано до sidecar та активовано.
Надішліть HTTP-запит до
http://my-nginx.mesh-external.svc.cluster.local
:Перевірте лог podʼа
curl
на наявність радка, що відповідає вашому запиту.Ви повинні побачити рядок, схожий на наступний:
Видалення конфігурації взаємного TLS origination
Видаліть створені ресурси Kubernetes:
Видаліть сертифікати та приватні ключі:
Видаліть згенеровані конфігураційні файли, використані у цьому прикладі:
Очищення загальної конфігурації
Видалити сервіс curl
та розгортання: