Модель безпеки

7 хвилин(и)

Цей документ має на меті описати стан безпеки різних компонентів Istio і те, як можливі атаки можуть вплинути на систему.

Компоненти

Istio постачається з різноманітними додатковими компонентами, які будуть розглянуті тут. Для загального огляду перегляньте розділ Архітектура Istio. Зазначимо, що розгортання Istio є надзвичайно гнучким; нижче ми здебільшого розглядатимемо найгірші сценарії.

Istiod

Istiod служить основним компонентом панелі управління Istio, часто виконуючи роль компонента XDS та виступаючи як Центр Сертифікації mТLS.

Istiod вважається високопривілейованим компонентом, схожим на сервер API Kubernetes.

Він має високі привілеї Kubernetes RBAC, зазвичай включаючи доступ для читання Secret та запис через webhook.
Виконуючи роль CA, він може надавати різні сертифікати.
Виконуючи роль панелі управління XDS, він може налаштовувати проксі для виконання довільних дій.

Таким чином, безпека кластера тісно повʼязана з безпекою Istiod. Дотримання найкращих практик безпеки Kubernetes щодо доступу до Istiod є вкрай важливим.

Втулок Istio CNI

Istio може бути розгорнуто з втулком Istio CNI як DaemonSet. Цей DaemonSet відповідає за налаштування мережевих правил в Istio, забезпечуючи прозоре перенаправлення трафіку за потреби. Це альтернатива контейнеру istio-init, про який нижче.

Оскільки CNI DaemonSet змінює мережеві правила на вузлі, він потребує підвищеного securityContext. Однак, на відміну від Istiod, це локальний привілей вузла. Наслідки цього дивись нижче.

Оскільки це обʼєднує підвищені привілеї, необхідні для налаштування мережі, в одному podʼі, а не в всіх podʼах, цей параметр зазвичай є рекомендованим.

Проксі sidecar

Istio може опціонально розгортати проксі sidecar поруч із застосунком.

Проксі sidecar потребує налаштування мережі для направлення всього трафіку через проксі. Це можна зробити за допомогою втулка Istio CNI або розгортання initContainer (istio-init) у podʼі (це відбувається автоматично, якщо втулок CNI не розгорнуто). Контейнер istio-init потребує прав NET_ADMIN та NET_RAW. Однак ці права діють лише під час ініціалізації — основний контейнер sidecar є повністю непривілейованим.

Додатково, проксі sidecar не потребує жодних привілеїв Kubernetes RBAC.

Кожен проксі sidecar має право запитувати сертифікат для повʼязаного Службового облікового запису Podʼа.

Gateways та Waypoints

Шлюзи та Waypoints функціонують як автономні розгортання проксі. На відміну від sidecar, вони не потребують жодних змін у мережі та, відповідно, не потребують привілеїв.

Ці компоненти працюють з власними службовими обліковими записами, відмінними від ідентифікації застосунків.

Ztunnel

Ztunnel виступає як проксі на рівні вузла. Віг вимагає прав NET_ADMIN, SYS_ADMIN та NET_RAW. Як і втулок Istio CNI, він є локальними привілеями для вузла. Ztunnel не має жодних повʼязаних привілеїв Kubernetes RBAC.

Ztunnel має право запитувати сертифікати для будь-яких Службових облікових записів podʼів, що працюють на тому ж вузлі. Аналогічно до kubelet, він явно не дозволяє запитувати довільні сертифікати. Це, знову ж таки, забезпечує, що ці привілеї є локальними для вузла.

Властивості перехоплення трафіку

Коли pod стає частиною мережі, весь вхідний TCP трафік буде перенаправлено до проксі. Це включає як mTLS/HBONE, так і незашифрований трафік. Будь-які придатні політики для робочого навантаження будуть застосовані перед перенаправленням трафіку до робочого навантаження.

Однак, Istio наразі не гарантує, що вихідний трафік буде перенаправлено до проксі. Дивіться обмеження перехоплення трафіку. Таким чином, необхідно дотримуватись кроків з забезпечення безпеки вихідного трафіку, якщо потрібні політики для вихідного трафіку.

Властивості mTLS Properties

mTLS забезпечує основу для більшості безпекових позицій Istio. Нижче пояснено різні властивості, які забезпечує mTLS для безпеки Istio.

Центр Сертифікації

Istio має вбудований Центр Сертифікації.

Стандартно, CA дозволяє автентифікувати клієнтів на основі одного з наступних варіантів:

Токен JWT Kubernetes з аудиторією istio-ca, який перевіряється за допомогою TokenReview Kubernetes. Це стандартний метод в podʼах Kubernetes.
Наявний сертифікат mTLS.
JWT-токени користувачів, перевірені з використанням OIDC (вимагає налаштування).

CA видаватиме лише ті сертифікати, які запитуються для ідентифікаторів, для яких клієнт пройшов автентифікацію.

Istio також може інтегруватися з різними сторонніми CA; будь ласка, зверніться до документації з безпеки відповідних CA для детальнішої інформації.

Клієнт мTLS

У режимі sidecar клієнтський sidecar буде автоматично використовувати TLS під час підключення до сервісу, який підтримує mTLS. Це також можна явно налаштувати. Зверніть увагу, що це автоматичне виявлення залежить від того, як Istio асоціює трафік з Service. Непідтримувані типи трафіку або обмеження конфігурації можуть завадити цьому.

Під час підключення до бекенду набір дозволених ідентифікацій обчислюється на рівні Service, базуючись на обʼєднанні всіх ідентифікацій бекенду.

Сервер mTLS

Стандартно Istio приймає mTLS та не mTLS трафік (що часто називають «дозвільним режимом»). Користувачі можуть вибрати суворий режим, написавши правила PeerAuthentication або AuthorizationPolicy, що вимагають mTLS.

При встановленні зʼєднання mTLS перевіряється сертифікат учасника. Крім того, перевіряється належність ідентифікаторів до одного домену довіри. Щоб дозволити перевірку лише певних ідентифікаторів, можна використовувати AuthorizationPolicy.

Досліджені типи компрометації

На основі наведеного вище огляду ми розглянемо вплив на кластер, якщо різні частини системи будуть скомпрометовані. У реальному світі існує безліч різних змінних навколо будь-якої атаки на безпеку:

Наскільки легко її виконати
Які попередні привілеї потрібні
Як часто вона може бути використана
Які наслідки (повне віддалене виконання, відмова в обслуговуванні і т.д.).

У цьому документі ми розглянемо найгірший сценарій: скомпрометований компонент означає, що зловмисник має повну можливість віддаленого виконання коду.

Компрометація робочого навантаження

У цьому випадку відбувається компрометація робочого навантаження застосунку (pod).

Pod може мати доступ до токена службового облікового запису. Якщо це так, компрометація навантаження може поширитися від одного pod, компрометуючи весь службовий обліковий запис.

У моделі sidecar проксі розташований поруч із pod і працює в межах тієї ж зони довіри. Скомпрометований застосунок може втручатися у роботу проксі через адмін-API або інші інтерфейси, зокрема для вилучення матеріалу приватного ключа, дозволяючи іншому агенту видавати себе за робоче навантаження. Припускається, що компрометація робочого навантаження включає також компрометацію проксі sidecar.

Таким чином, скомпрометоване навантаження може:

Надсилати довільний трафік, з mTLS або без нього. Воно може обійти будь-яку конфігурацію проксі або навіть сам проксі. Зазначимо, що Istio не пропонує політики авторизації для вихідного трафіку, тому обхід політики авторизації вихідного трафіку не відбувається.
Приймати трафік, який вже був призначений для застосунку. Воно може обійти політики, налаштовані в проксі sidecar.

Основний висновок тут полягає в тому, що, хоча скомпрометоване навантаження може поводитися шкідливо, це не дає йому змоги обійти політики в інших навантаженнях.

Istio пропонує різноманітні функції, які можуть обмежити наслідки такої компрометації:

Функції спостережуваності можуть бути використані для ідентифікації атаки.
Політики можуть обмежити типи трафіку, які навантаження може надсилати або отримувати.

Компрометація проксі - Sidecars

У цьому випадку проксі sidecar є скомпрометованим. Оскільки sidecar і застосунок знаходяться в одній зоні довіри, це функціонально еквівалентно до компрометації робочого навантаження.

Компрометація проксі - Waypoint

У цьому випадку скомпрометовано проксі waypoint. Хоча у waypoint немає жодних привілеїв для використання зловмисником, він обслуговує (потенційно) багато різних сервісів та робочих навантажень. Скомпрометований waypoint може отримувати, переглядати, змінювати або відхиляти весь трафік для цих навантажень.

Istio пропонує можливість налаштування гранулярності розгортання waypoint. Користувачі можуть розглянути можливість розгортання більш ізольованих waypoint для посилення ізоляції.

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

Компрометація проксі - Ztunnel

У цьому випадку компрометовано проксі ztunnel.

Скомпрометований ztunnel надає зловмиснику контроль над мережею вузла.

Ztunnel має доступ до матеріалу приватних ключів для кожного застосунку, який працює на його вузлі. Компрометація ztunnel може призвести до їхнього отримання та використання в інших місцях. Однак латеральний рух до ідентичностей за межами розміщених робочих навантажень неможливий; кожен ztunnel має авторизацію доступу лише до сертифікатів для навантажень, що працюють на його вузлі, обмежуючи радіус ураження скомпрометованого ztunnel.

Компрометація вузла

У цьому випадку скомпрометовано вузол Kubernetes. І Kubernetes, і Istio спроєктовані для обмеження масштабу шкоди від компрометації одного вузла, так, щоб компрометація одного вузла не призводила до компрометації всього кластера.

Проте атака має повний контроль над будь-якими робочими навантаженнями, що виконуються на цьому вузлі. Наприклад, вона може скомпрометувати будь-які спільно розміщені waypoint, локальний ztunnel, будь-які sidecar, будь-які спільно розміщені екземпляри Istiod тощо.

Компрометація кластера (API Server)

Компрометація API-сервера Kubernetes фактично означає, що весь кластер і mesh скомпрометовані. На відміну від більшості інших векторів атаки, Istio мало що може зробити для обмеження масштабу такої атаки. Скомпрометований API-сервер надає зловмиснику повний контроль над кластером, включно з можливістю виконувати kubectl exec на довільних podʼах, видаляти будь-які AuthorizationPolicies Istio або навіть повністю видаляти Istio.

Компрометація Istiod

Компрометація Istiod зазвичай призводить до такого ж результату, як і компрометація API-сервера. Istiod є дуже привілейованим компонентом, який слід ретельно захищати. Дотримання кращих практик безпеки є важливим для підтримки захисту кластера.