Поради з безпеки

Особливості безпеки Istio забезпечують надійну ідентифікацію, потужну політику, прозоре шифрування TLS і інструменти автентифікації, авторизації та аудиту (AAA) для захисту ваших сервісів та даних. Однак, щоб повною мірою використовувати ці функції безпечно, слід дотримуватися найкращих практик. Рекомендується переглянути розділ Огляд безпеки перед тим, як продовжити.

Взаємне TLS шифрування

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

Хоча це необхідно для поступового впровадження або дозволу трафіку від клієнтів без sidecar Istio, це також послаблює рівень безпеки. Рекомендується мігрувати до суворого режиму за можливості, щоб забезпечити використання взаємного TLS шифрування.

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

Для повного захисту трафіку рекомендується налаштувати політики авторизації. Це дозволяє створювати політики з детальними умовами, які дозволяють або забороняють трафік. Наприклад, ви можете дозволити лише запити з простору імен app для доступу до сервісу hello-world.

Політики авторизації

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

Моделі безпечної політики авторизації

Використовуйте піхід “стандартно заборонено”

Рекомендується визначати політики авторизації Istio, використовуючи підхід “стандартно заборонено” для підвищення рівня безпеки вашого кластера. Підхід “стандартно заборонено” означає, що система стандартно забороняє всі запити, а ви визначаєте умови, за яких запити дозволені. Якщо ви пропустите деякі умови, трафік буде несподівано заборонений, замість того, щоб бути несподівано дозволеним. Останнє, як правило, є інцидентом безпеки, в той час як перше може призвести до погіршення взаємодії з користувачем, перебоїв у наданні послуг або не відповідатиме вашому SLO/SLA.

Наприклад, у завданні авторизації для HTTP-трафіку, політика авторизації з назвою allow-nothing гарантує, що весь трафік стандартно заборонено. Від цього моменту ви можете налаштовувати інші політики авторизації, які дозволяють трафік на основі конкретних умов.

Використовуйте підхід ALLOW-with-positive-matching і DENY-with-negative-match

Використовуйте підходи ALLOW-with-positive-matching або DENY-with-negative-match за можливості. Ці політики авторизації є безпечнішими, оскільки найгірший результат у разі помилки політики — це несподіване відмова від обслуговування (помилка 403), а не обхід політики авторизації.

Шаблон ALLOW-with-positive-matching передбачає використання дії ALLOW лише з позитивними полями збігу (наприклад, paths, values) і уникнення використання будь-яких негативних полів збігу (наприклад, notPaths, notValues).

Шаблон DENY-with-negative-match передбачає використання дії DENY лише з негативними полями збігу (наприклад, notPaths, notValues) і уникнення використання будь-яких позитивних полів збігу (наприклад, paths, values).

Наприклад, наведена нижче політика авторизації використовує шаблон ALLOW-with-positive-matching, щоб дозволити запити до шляху /public:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: foo
spec:
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/public"]

Ця політика явно вказує дозволений шлях (/public). Це означає, що шлях запиту має бути точно таким, як /public, щоб запит був дозволений. Будь-які інші запити будуть стандартно відхилені, що усуває ризик невідомої поведінки нормалізації, яка може призвести до обходу політики.

Нижче наведено приклад використання шаблону DENY-with-negative-match для досягнення такого ж результату:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: foo
spec:
  action: DENY
  rules:
  - to:
    - operation:
        notPaths: ["/public"]

Нормалізація шляху в політиці авторизації

Точка примусового застосування політик авторизації — це проксі Envoy, а не звичайна точка доступу до ресурсів у бекенд-застосунку. Відповідність політики порушується, коли проксі Envoy і бекенд-застосунок інтерпретують запит по-різному.

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

Наприклад, розгляньте політику авторизації для відхилення запитів із шляхом /data/secret. Запит із шляхом /data//secret не буде відхилений, оскільки він не відповідає шляху, визначеному в політиці авторизації, через зайву косу риску / в шляху.

Запит пройде, і згодом бекенд-застосунок поверне таку ж відповідь, яку він повертає для шляху /data/secret, оскільки бекенд-застосунок нормалізує шлях /data//secret до /data/secret, вважаючи подвійну косу риску // еквівалентною одній косій рисці /.

У цьому прикладі точка примусового застосування політики (проксі Envoy) мала інше розуміння шляху, ніж точка доступу до ресурсу (бекенд-застосунок). Ця різниця в розумінні спричинила невідповідність і, зрештою, обхід політики авторизації.

Ця проблема ускладнюється через такі фактори:

• Відсутність чіткого стандарту для нормалізації.
• Бекенди та фреймворки на різних рівнях мають свою специфічну нормалізацію.
• Застосунки можуть мати навіть довільну нормалізацію для власних випадків використання.

Політика авторизації Istio має вбудовану підтримку різних базових варіантів нормалізації, щоб допомогти вам краще вирішити цю проблему:

• Зверніться до Рекомендацій з налаштування опції нормалізації шляху, щоб зрозуміти, які опції нормалізації ви можете використовувати.

• Зверніться до Налаштування вашої системи щодо нормалізації шляху, щоб зрозуміти деталі кожної опції нормалізації.

• Зверніться до Помʼякшення наслідків непідтримуваної нормалізації для альтернативних рішень у випадку, якщо вам потрібні непідтримувані варіанти нормалізації.

Рекомендації щодо налаштування опції нормалізації шляху

Випадок 1: Вам не потрібна нормалізація взагалі

Перед тим, як налаштовувати нормалізацію, переконайтеся, що вона взагалі потрібна.

Вам не потрібна нормалізація, якщо ви не використовуєте політики авторизації або якщо ваші політики авторизації не використовують поля path.

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

Випадок 2: Вам потрібна нормалізація, але ви не знаєте, яку опцію вибрати

Якщо вам потрібна нормалізація, але ви не впевнені, яку опцію вибрати, найбезпечніший варіант — це найсуворіша опція нормалізації, яка забезпечує максимальний рівень нормалізації в політиці авторизації.

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

Ви можете використовувати менш сувору опцію нормалізації, якщо вона вже задовольняє ваші вимоги, і ви впевнені в її наслідках.

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

Зверніться до Налаштування системи щодо нормалізації шляху для детальнішої інформації про налаштування опцій нормалізації.

Випадок 3: Вам потрібна непідтримувана опція нормалізації

Якщо вам потрібна певна опція нормалізації, яка ще не підтримується Istio, зверніться до Помʼякшення наслідків непідтримуваної нормалізації для налаштування підтримки або створіть запит на додавання функції до спільноти Istio.

Налаштування системи щодо нормалізації шляху

Політики авторизації Istio можуть базуватися на URL-шляху в HTTP-запитах. Нормалізація шляху (або URI-нормалізація) модифікує та стандартизує шляхи вхідних запитів, щоб обробляти їх у стандартний спосіб. Синтаксично різні шляхи можуть бути еквівалентні після нормалізації.

Istio підтримує такі схеми нормалізації шляхів перед перевіркою запиту щодо політик авторизації та маршрутизацією запиту:

Алгоритми нормалізації виконуються в такому порядку:

1. Декодування символів %2F, %2f, %5C та %5c.
2. Нормалізація за RFC 3986 та іншими нормалізаціями, реалізованими через опцію normalize_path на Envoy.
3. Зʼєднання косих рисок

Для повного списку підтримуваних нормалізацій зверніться до нормалізації політик авторизації.

Приклади конфігурації

Забезпечення того, що Envoy нормалізує шляхи запитів відповідно до очікувань ваших бекенд-сервісів, є критичним для безпеки вашої системи. Наступні приклади можна використовувати як довідник для налаштування вашої системи. Нормалізовані URL-шляхи або оригінальні URL-шляхи (якщо вибрано NONE) будуть:

1. Використовуватися для перевірки політик авторизації
2. Пересилатися до бекенд-застосунку

Як налаштувати

Ви можете використовувати istioctl для оновлення конфігурації mesh:

$ istioctl upgrade --set meshConfig.pathNormalization.normalization=DECODE_AND_MERGE_SLASHES

або шляхом зміни файлу перевизначень оператора:

$ cat <<EOF > iop.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    pathNormalization:
      normalization: DECODE_AND_MERGE_SLASHES
EOF
$ istioctl install -f iop.yaml

Альтернативно, якщо ви хочете безпосередньо редагувати конфігурацію mesh, ви можете додати pathNormalization до конфігурації mesh, яка є config map istio-<REVISION_ID> у просторі імен istio-system. Наприклад, якщо ви виберете опцію DECODE_AND_MERGE_SLASHES, ви зміните конфігурацію mesh таким чином:

apiVersion: v1
  data:
    mesh: |-
      ...
      pathNormalization:
        normalization: DECODE_AND_MERGE_SLASHES
      ...

Помʼякшення наслідків непідтримуваної нормалізації

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

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

Логіка користувацької нормалізації

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

Приклад користувацької нормалізації (нормалізація регістру)

В деяких середовищах може бути корисно порівнювати шляхи в політиках авторизації без урахування регістру. Наприклад, трактуючи https://myurl/get і https://myurl/GeT як еквівалентні.

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

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ingress-case-insensitive
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: INSERT_FIRST
      value:
        name: envoy.lua
        typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
            inlineCode: |
              function envoy_on_request(request_handle)
                local path = request_handle:headers():get(":path")
                request_handle:headers():replace(":path", string.lower(path))
              end

Написання політик відповідності хостів

Istio генерує імена хостів як для самого хосту, так і для всіх відповідних портів. Наприклад, віртуальний сервіс або Gateway для хосту example.com генерує конфігурацію, що відповідає example.com і example.com:*. Проте, політики авторизації точного відповідності збігаються тільки з точною строкою, наданою для полів hosts або notHosts.

Правила політики авторизації, що збігаються з хостами, слід писати з використанням префіксного збігу, а не точного співпадіння. Наприклад, для AuthorizationPolicy, що відповідає конфігурації Envoy, згенерованій для імені хоста example.com, слід використовувати hosts: ["example.com", "example.com:*"], як показано у нижченаведеній AuthorizationPolicy.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ingress-host
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["example.com", "example.com:*"]

Крім того, поля hosts та notHosts зазвичай повинні використовуватися тільки на gateway для зовнішнього трафіку, що входить в mesh, а не на sidecars для трафіку всередині mesh. Це тому, що sidecar на стороні сервера (де застосовується політика авторизації) не використовує заголовок Host при переспрямуванні запиту до застосунку. Це робить поля host і notHost безглуздими в sidecar, оскільки клієнт може звертатися до застосунку, використовуючи явну IP-адресу і довільний заголовок Host, замість імені сервісу.

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

Спеціалізований брандмауер вебзастосунків (WAF)

Багато спеціалізованих продуктів Web Application Firewall (WAF) пропонують додаткові параметри нормалізації. Вони можуть бути розгорнуті перед вхідним шлюзом Istio для нормалізації запитів, що входять в mesh. Політика авторизації буде потім застосовуватися до нормалізованих запитів. Будь ласка, зверніться до конкретного продукту WAF для налаштування параметрів нормалізації.

Запит нової функції для Istio

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

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

Якщо робоча група з безпеки продукту Istio оцінить запит функції як такий, що не є уразливістю, питання буде відкрито публічно для подальшого обговорення запиту функції.

Відомі обмеження

У цьому розділі наведені відомі обмеження політики авторизації.

TCP протоколи server-first не підтримуються

Протоколи TCP server-first означають, що серверний застосунок надішле перші байти відразу після прийняття TCP-зʼєднання до отримання будь-яких даних від клієнта.

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

Вона також не підтримує протоколи TCP server-first, оскільки перші байти надсилаються серверним застосунком навіть до того, як він отримає будь-які дані від клієнта. У такому випадку початкові перші байти, надіслані сервером, повертаються клієнту без проходження перевірки контролю доступу політики авторизації.

Вам не слід використовувати політику авторизації, якщо перші байти, надіслані протоколами TCP server-first, містять будь-які конфіденційні дані, які потрібно захистити за допомогою належної авторизації.

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

Розуміння обмежень захоплення трафіку

Sidecar Istio працює, захоплюючи як вхідний, так і вихідний трафік і перенаправляючи його через проксі sidecar.

Однак не весь трафік захоплюється:

• Перенаправлення працює тільки з TCP-трафіком. Будь-які UDP або ICMP пакети не будуть захоплюватися чи модифікуватися.
• Захоплення вхідного трафіку вимкнене для багатьох портів, які використовує sidecar, а також для порту 22. Цей список може бути розширений за допомогою таких опцій, як traffic.sidecar.istio.io/excludeInboundPorts.
• Захоплення вихідного трафіку може бути зменшено через налаштування, такі як traffic.sidecar.istio.io/excludeOutboundPorts або інші засоби.

Загалом, між застосунком і його sidecar проксі існує мінімальна межа безпеки. Налаштування sidecar дозволене на основі кожного podʼа, і обидва працюють в одному мережевому/процесному просторі імен. Таким чином, застосунок може мати можливість видалити правила перенаправлення і видалити, змінити, завершити або замінити проксі sidecar. Це дозволяє podʼу навмисно обійти свій sidecar для вихідного трафіку або навмисно дозволити вхідному трафіку обійти свій sidecar.

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

Наприклад, якщо я запускаю застосунок reviews на порту 9080, я можу припустити, що весь трафік від застосунку productpage буде захоплений sidecar проксі, де можуть застосовуватися політики автентифікації та авторизації Istio.

Багаторівневий захист за допомогою NetworkPolicy

Для подальшого захисту трафіку, політики Istio можуть бути поєднані з Kubernetes Network Policies. Це забезпечує потужну стратегію багаторівневого захисту, яка може бути використана для посилення безпеки вашої mesh-мережі.

Наприклад, ви можете дозволити трафік тільки на порт 9080 для нашого застосунку reviews. У разі компрометації podʼа або вразливості безпеки у кластері, це може обмежити або зупинити просування нападника.

Залежно від фактичної реалізації, зміни до мережевої політики можуть не вплинути на існуючі зʼєднання в проксі Istio. Можливо, вам доведеться перезапустити проксі Istio після застосування політики, щоб закрити існуючі зʼєднання та підпорядкувати нові зʼєднання новій політиці.

Захист вихідного трафіку

Поширеною помилкою є думка, що такі опції, як outboundTrafficPolicy: REGISTRY_ONLY, діють як політика безпеки, що запобігає доступу до незадекларованих сервісів. Однак, як зазначалося вище, це не є потужним бар’єром безпеки і повинно вважатися лише намаганнями.

Хоча це корисно для запобігання випадковим залежностям, якщо ви хочете захистити вихідний трафік і забезпечити проходження всього вихідного трафіку через проксі, вам слід покладатися на Egress Gateway. У поєднанні з Network Policy ви можете забезпечити проходження всього трафіку, або його підмножини, через egress gateway. Це гарантує, що навіть якщо клієнт випадково або зловмисно обходить свій sidecar, запит буде заблоковано.

Налаштування перевірки TLS у Destination Rule при використанні TLS origination

Istio надає можливість ініціювати TLS через проксі sidecar або gateway. Це дозволяє застосункам, що надсилають трафік HTTP у відкритому вигляді, прозоро “оновлюватися” до HTTPS.

Слід бути обережними при налаштуванні параметра tls у DestinationRule, щоб вказати поля caCertificates, subjectAltNames і sni. Змінну середовища VERIFY_CERTIFICATE_AT_CLIENT=true на Istiod можна ввімкнути, щоб автоматично встановити caCertificate із сертифікатів системного сховища. Якщо автоматично використовується сертифікат CA операційної системи і він потрібен лише для певних хостів, встановіть змінну середовища VERIFY_CERTIFICATE_AT_CLIENT=false на Istiod, і можна вказати значення system у полі caCertificates в необхідних DestinationRule. Вказання caCertificates у DestinationRule матиме пріоритет, і сертифікат CA ОС не використовуватиметься. Стандартно вихідний трафік не надсилає SNI під час TLS handshake. SNI необхідно вказати у DestinationRule, щоб переконатися, що хост коректно обробить запит.

Наприклад:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: google-tls
spec:
  host: google.com
  trafficPolicy:
    tls:
      mode: SIMPLE
      caCertificates: /etc/ssl/certs/ca-certificates.crt
      subjectAltNames:
      - "google.com"
      sni: "google.com"

Gateways

При запуску Istio gateway, залучено кілька ресурсів:

• Gateway, що контролюють порти і налаштування TLS для шлюзу.
• VirtualService, які керують логікою маршрутизації. Вони асоціюються зі Gateway через пряме посилання в полі gateways та узгодження полів hosts у Gateway та VirtualService.

Обмеження прав на створення Gateway

Рекомендується обмежити створення ресурсів Gateway лише для довірених адміністраторів кластера. Цього можна досягти за допомогою політик Kubernetes RBAC або таких інструментів, як Open Policy Agent.

Уникайте занадто загальних конфігурацій hosts

Коли можливо, уникайте занадто загальних налаштувань hosts у Gateway.

Наприклад, така конфігурація дозволить будь-якому VirtualService приєднатися до Gateway, що може відкрити неочікувані домени:

servers:
- port:
    number: 80
    name: http
    protocol: HTTP
  hosts:
  - "*"

Це слід обмежити, дозволивши лише певні домени або конкретні простори імен:

servers:
- port:
    number: 80
    name: http
    protocol: HTTP
  hosts:
  - "foo.example.com" # Дозволити лише VirtualServices для foo.example.com
  - "default/bar.example.com" # Дозволити лише VirtualServices у просторі імен default для bar.example.com
  - "route-namespace/*" # Дозволити лише VirtualServices у просторі імен route-namespace для будь-якого хоста

Ізолюйте чутливі сервіси

Можливо, ви захочете забезпечити суворішу фізичну ізоляцію для чутливих сервісів. Наприклад, ви можете запустити виділений екземпляр шлюзу для чутливого payments.example.com, одночасно використовуючи один спільний екземпляр шлюзу для менш чутливих доменів, таких як blog.example.com та store.example.com. Це може забезпечити сильніший глибокий захист і допомогти виконати певні регуляторні вимоги.

Явно вимкніть усі чутливі http-хости при послабленому зіставленні SNI-хостів

Виправдано використовувати кілька Gateway для визначення взаємного TLS і простого TLS на різних хостах. Наприклад, використовувати взаємний TLS для SNI хоста admin.example.com і простий TLS для SNI хоста *.example.com.

kind: Gateway
metadata:
  name: guestgateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "*.example.com"
    tls:
      mode: SIMPLE
---
kind: Gateway
metadata:
  name: admingateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - admin.example.com
    tls:
      mode: MUTUAL

Якщо це необхідно, наполегливо рекомендується явно відключити HTTP хост admin.example.com у VirtualService, який привʼязується до *.example.com. Причина полягає в тому, що на даний момент проксі Envoy не вимагає дотримання заголовків HTTP 1 Host або HTTP 2 псевдо-заголовків :authority, що слідують за обмеженнями SNI. Це означає, що зловмисник може використовувати TLS-зʼєднання з guest-SNI для доступу до адміністрування VirtualService. Код відповіді HTTP 421 призначений для такої невідповідності SNI хостів і може використовуватися для виконання відключення.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: disable-sensitive
spec:
  hosts:
  - "admin.example.com"
  gateways:
  - guestgateway
  http:
  - match:
    - uri:
        prefix: /
    fault:
      abort:
        percentage:
          value: 100
        httpStatus: 421
    route:
    - destination:
        port:
          number: 8000
        host: dest.default.cluster.local

Виявлення протоколу

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

CNI

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

Щоб зменшити привілеї, надані podʼам, Istio пропонує CNI втулок, який знімає цю вимогу.

Використання захищених Docker образів

Стандартні Docker образи Istio, включаючи ті, що запускаються панеллю управління, шлюзами і sidecar-проксі, базуються на ubuntu. Це надає різні інструменти, такі як bash і curl, що додає зручність, але збільшує потенційну поверхню для атак.

Istio також пропонує менш громіздкий образ на основі образів distroless, що зменшує кількість залежностей в образі.

Політика випуску та безпеки

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

Виявлення хибних конфігурацій

Хоча Istio перевіряє ресурси при їх створенні, ці перевірки не можуть виявити всі проблеми, що перешкоджають розповсюдженню конфігурації в мережі. Це може призвести до застосування політики, яку буде проігноровано, викликаючи несподівані результати.

• Запустіть istioctl analyze до або після застосування конфігурації, щоб переконатися у її коректності.
• Моніторте панель управління для виявлення відхилених конфігурацій. Вони показуються через метрику pilot_total_xds_rejects, а також у журналах.
• Тестуйте свою конфігурацію, щоб переконатися, що вона дає очікувані результати. Для політики безпеки корисно проводити позитивні та негативні тести, щоб переконатися, що ви випадково не обмежуєте занадто багато або занадто мало трафіку.

Уникайте альфа та експериментальних функцій

Усі функції та API Istio мають статус, який визначає їхню стабільність, політику видалення та політику безпеки.

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

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

Закриття портів

Istio налаштовує різноманітні порти, які можна закрити для підвищення безпеки.

Панель управління

Istiod стандартно відкриває кілька неавтентифікованих портів відкритим текстом для зручності. Якщо це необхідно, їх можна закрити:

• Порт 8080 відкриває інтерфейс налагодження, який надає доступ для читання до різних деталей стану кластера. Його можна відключити, встановивши змінну середовища ENABLE_DEBUG_ON_HTTP=false для Istiod. Попередження: багато команд istioctl залежать від цього інтерфейсу та не будуть працювати, якщо його вимкнено.
• Порт 15010 відкриває службу XDS у відкритому тексті. Його можна відключити, додавши прапорець --grpcAddr="" до розгортання Istiod. Примітка: дуже чутливі сервіси, такі як сервіси підпису та розповсюдження сертифікатів, ніколи не обслуговуються у відкритому тексті.

Панель даних

Проксі відкриває різні порти. Зовні доступні порти 15090 (телеметрія) та 15021 (перевірка стану). Порти 15020 і 15000 надають точки налагодження. Вони відкриті лише через localhost. Як результат, застосунки, які працюють в тому ж podʼі, що й проксі, мають до них доступ; немає межі довіри між sidecar-проксі та застосунком.

Налаштування токенів сторонніх службових облікових записів

Для автентифікації з панеллю управління Istio проксі Istio використовуватиме токен службового облікового запису. Kubernetes підтримує дві форми цих токенів:

• Токени третіх сторін, які мають обмежену аудиторію та термін дії.
• Токени першої сторони, які не мають терміну придатності та встановлюються в усі podʼи.

Оскільки властивості токена прошої сторони є менш захищеними, стандартно Istio використовуватиме токени сторонніх сервісів. Однак ця функція не ввімкнена на всіх платформах Kubernetes.

Якщо ви використовуєте istioctl для інсталяції, підтримка буде автоматично виявлена. Це також можна зробити вручну, налаштувавши параметр --set values.global.jwtPolicy=third-party-jwt або --set values.global.jwtPolicy=first-party-jwt.

Щоб визначити, чи підтримує ваш кластер токени сторонніх сервісів, перевірте наявність API TokenRequest. Якщо немає відповіді, то ця функція не підтримується:

$ kubectl get --raw /api/v1 | jq '.resources[] | select(.name | index("serviceaccounts/token"))'
{
    "name": "serviceaccounts/token",
    "singularName": "",
    "namespaced": true,
    "group": "authentication.k8s.io",
    "version": "v1",
    "kind": "TokenRequest",
    "verbs": [
        "create"
    ]
}

Більшість хмарних провайдерів вже підтримують цю функцію, однак багато інструментів локальної розробки та власних інсталяцій можуть не підтримувати її до Kubernetes 1.20. Щоб увімкнути цю функцію, зверніться до документації Kubernetes.

Налаштування обмежень на кількість downstream-з’єднань

Стандартно Istio (і Envoy) не обмежує кількість низхідних зʼєднань. Це може бути використано зловмисником (див. бюлетень безпеки 2020-007). Щоб вирішити цю проблему, необхідно налаштувати відповідне обмеження зʼєднань для вашого середовища.

Налаштуйте значення global_downstream_max_connections

Наступну конфігурацію можна вказати під час встановлення:

meshConfig:
  defaultConfig:
    runtimeValues:
      "overload.global_downstream_max_connections": "100000"