Безпека

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

• Для захисту від атак «людина посередині» потрібне шифрування трафіку.
• Для забезпечення гнучкого контролю доступу до сервісів потрібен взаємний TLS та детальні політики доступу.
• Для визначення, хто і що зробив у який час, потрібні інструменти аудиту.

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

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

• Безпека є стандартом: без змін в коді застосунку та інфраструктури
• Захист у глибині: інтеграція з наявними системами безпеки для забезпечення кількох рівнів захисту
• Мережа з нульовим довірою: створення рішень безпеки в мережах без довіри

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

Високорівнева архітектура

Безпека в Istio включає кілька компонентів:

• Центр сертифікації (CA) для управління ключами та сертифікатами.

• Сервер конфігураційного API, який розподіляє проксі:

  • політики автентифікації
  • політики авторизації
  • інформацію про безпечні імена

• Проксі на рівні sidecar і периметру працюють як точки забезпечення політики (PEP) для захисту комунікації між клієнтами та серверами.

• Набір розширень проксі Envoy для управління телеметрією та аудитом.

Панель управління обробляє конфігурації від сервера API та налаштовує PEP у панелі даних. PEP реалізовані за допомогою Envoy. Наступна діаграма показує архітектуру.

У наступних розділах ми детально розглянемо функції безпеки Istio.

Ідентичність в Istio

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

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

Ось приклади сервісів ідентичностей, які ви можете використовувати на різних платформах:

• Kubernetes: Службовий обліковий запис Kubernetes
• GCE: Службовий обліковий запис GCP
• Локально (не Kubernetes): обліковий запис користувача, власний службовий обліковий запис, імʼя сервісу, службовий обліковий запис Istio або службовий обліковий запис GCP. Власний службовий обліковий запис відноситься до існуючого службового облікового запису, як ідентичності, якиою управляє Identity Directory.

Управління ідентичністю та сертифікатами

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

Istio забезпечує ключі та сертифікати через наступний процес:

1. istiod пропонує gRPC-сервіс для обробки запитів на підписання сертифікатів (CSR).
2. Під час запуску агент Istio створює приватний ключ та CSR, а потім надсилає CSR з його обліковими даними до istiod для підписання.
3. CA в istiod перевіряє облікові дані, що містяться в CSR. Після успішної перевірки він підписує CSR для генерації сертифіката.
4. Коли завдання запускається, Envoy запитує сертифікат і ключ в агента Istio в тому ж контейнері через API секретів Envoy SDS.
5. Агент Istio надсилає сертифікати, отримані від istiod, і приватний ключ до Envoy через API SDS Envoy.
6. Агент Istio контролює термін придатності сертифіката робочого навантаження. Вищезазначений процес повторюється періодично для ротації сертифікатів і ключів.

Автентифікація

Istio надає два типи автентифікації:

• Автентифікація на рівні зʼєднання (Peer authentication): використовується для автентифікації між сервісами для перевірки клієнта, який встановлює зʼєднання. Istio пропонує взаємний TLS як повноцінне рішення для автентифікації транспорту, яке можна увімкнути без зміни коду сервісів. Це рішення:

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

• Автентифікація запитів (Request authentication): використовується для автентифікації кінцевих користувачів для перевірки облікових даних, прикріплених до запиту. Istio дозволяє автентифікацію на рівні запиту з перевіркою JSON Web Token (JWT) і спрощеним досвідом розробки за допомогою власних провайдерів автентифікації або будь-яких OpenID Connect провайдерів, таких як:

  • ORY Hydra
  • Keycloak
  • Auth0
  • Firebase Auth
  • Google Auth

У всіх випадках Istio зберігає політики автентифікації в Istio config store через власний Kubernetes API. Istiod тримає їх актуальними для кожного проксі разом із ключами, де це необхідно. Крім того, Istio підтримує автентифікацію в дозвільному режимі (permissive mode), щоб допомогти вам зрозуміти, як зміна політики може вплинути на вашу безпеку до її застосування.

Взаємна TLS-автентифікація

Istio тунелює комунікацію між сервісами через PEP на клієнтській та серверній стороні, які реалізовані як Envoy проксі. Коли робоче навантаження надсилає запит іншому робочому навантаженню, використовуючи взаємну TLS-автентифікацію, запит обробляється наступним чином:

1. Istio перенаправляє вихідний трафік від клієнта до локального sidecar Envoy клієнта.
2. Envoy клієнта розпочинає взаємне TLS-рукостискання з Envoy сервером. Під час рукостискання клієнтський Envoy також виконує перевірку безпечного іменування, щоб перевірити, чи авторизовано службовий обліковий запис, представлений у сертифікаті сервера, для запуску цільового сервісу.
3. Envoy клієнта і Envoy сервера встановлюють взаємне TLS-зʼєднання, і Istio перенаправляє трафік від Envoy клієнта до Envoy сервера.
4. Envoy сервера авторизує запит. Якщо запит авторизовано, він передає трафік до бекенд-сервісу через локальні TCP-зʼєднання.

Istio конфігурує TLSv1_2 як мінімальну версію TLS як для клієнта, так і для сервера, із наступними наборами шифрів:

• ECDHE-ECDSA-AES256-GCM-SHA384

• ECDHE-RSA-AES256-GCM-SHA384

• ECDHE-ECDSA-AES128-GCM-SHA256

• ECDHE-RSA-AES128-GCM-SHA256

• AES256-GCM-SHA384

• AES128-GCM-SHA256

Дозвільний режим

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

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

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

Захищене іменування

Ідентичність серверів кодується в сертифікатах, але імена сервісів отримуються через службу виявлення або DNS. Інформація про захищене іменування зіставляє ідентичності серверів з іменами сервісів. Зіставлення ідентичності A з імʼям сервісу B означає, що “A уповноважений виконувати сервіс B”. Панель управління спостерігає за apiserver, генерує зіставлення захищеного іменування і безпечно розподіляє їх до PEP.

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

Припустимо, що легітимні сервери, які виконують сервіс datastore, використовують лише ідентичність infra-team. Шкідник має сертифікат і ключ для ідентичності test-team. Шкідник має намір видавати себе за сервіс, щоб перевірити дані, що надходять від клієнтів. Шкідник розгортає підроблений сервер з сертифікатом і ключем для ідентичності test-team. Припустимо, що шкідник успішно перехопив (через підробку DNS, підміна BGP/маршрутизації, підміна ARP тощо) трафік, що надходить до datastore, і перенаправив його до підробленого сервера.

Коли клієнт викликає сервіс datastore, він витягує ідентичність test-team з сертифіката сервера і перевіряє, чи дозволено test-team виконувати сервіс datastore за допомогою інформації про захищене іменування. Клієнт виявляє, що test-team не уповноважено виконувати сервіс datastore, і автентифікація зазнає невдачі.

Зверніть увагу, що для не HTTP/HTTPS трафіку захищене іменування не захищає від підробки DNS, в якій зловмисник змінює IP-адреси призначення для сервісу. Оскільки TCP-трафік не містить інформації про Host, і Envoy може покладатися лише на IP-адресу призначення для маршрутизації, Envoy може направити трафік до сервісів на підроблених IP-адресах. Ця підробка DNS може відбутися навіть до того, як клієнтський Envoy отримає трафік.

Архітектура автентифікації

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

При будь-яких змінах політики нова політика перетворюється у відповідну конфігурацію, яка вказує PEP, як виконувати необхідні механізми автентифікації. Панель управління може отримувати публічний ключ і додавати його до конфігурації для перевірки JWT. Альтернативно, Istiod надає шлях до ключів і сертифікатів, якими управляє система Istio, і встановлює їх у Pod застосунку для mutual TLS. Більше інформації можна знайти в розділі Управління ідентичністю та сертифікатами.

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

Клієнтські сервіси, які надсилають запити, відповідають за дотримання необхідного механізму автентифікації. Для автентифікації запитів програма відповідає за отримання і прикріплення JWT-ліцензії до запиту. Для peer автентифікації Istio автоматично оновлює весь трафік між двома PEP до mutual TLS. Якщо політики автентифікації вимикають режим mutual TLS, Istio продовжує використовувати відкритий текст між PEP. Щоб явно відключити цей режим, використовуйте правила призначення. Детальніше про те, як працює mutual TLS, можна дізнатися в розділі Автентифікація Mutual TLS.

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

Політики автентифікації

Цей розділ надає більше деталей про те, як працюють політики автентифікації Istio. Як ви памʼятаєте з розділу Архітектура, політики автентифікації застосовуються до запитів, які отримує сервіс. Щоб вказати правила автентифікації клієнта в двосторонньому TLS, вам потрібно вказати TLSSettings у DestinationRule. Додаткову інформацію можна знайти в наших документах посилання на TLS налаштування.

Як і інші конфігурації Istio, ви можете вказати політики автентифікації в .yaml файлах. Ви розгортаєте ці політики за допомогою kubectl. Наступний приклад політики автентифікації вказує, що транспортна автентифікація для навантажень з міткою app:reviews повинна використовувати двосторонній TLS:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-peer-policy"
  namespace: "foo"
spec:
  selector:
    matchLabels:
      app: reviews
  mtls:
    mode: STRICT

Зберігання політик

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

Політики автентифікації peer і request зберігаються окремо за типами: PeerAuthentication і RequestAuthentication відповідно.

Поле selector

Політики автентифікації peer і request використовують поля selector для вказання мітки навантажень, до яких застосовується політика. Наступний приклад показує поле selector політики, що застосовується до навантажень з міткою app:product-page:

selector:
  matchLabels:
    app: product-page

Якщо ви не надаєте значення для поля selector, Istio співвідносить політику з усіма навантаженнями в межах зберігання політики. Таким чином, поля selector допомагають вам визначити область застосування політик:

• Політика для всієї мережі: політика, вказана для кореневого простору імен без або з порожнім полем selector.
• Політика для простору імен: політика, вказана для не кореневого простору імен без або з порожнім полем selector.
• Політика для конкретного навантаження: політика, визначена в звичайному просторі імен, з непорожнім полем selector.

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

Може бути лише одна політика автентифікації peer для всієї мережі і лише одна політика автентифікації peer для кожного простору імен. Коли ви конфігуруєте декілька політик автентифікації peer для всієї мережі або простору імен, Istio ігнорує новіші політики. Коли більше ніж одна політика автентифікації peer для конкретного навантаження відповідає умовам, Istio обирає найстарішу.

Istio застосовує найвужчу відповідну політику для кожного навантаження за наступним порядком:

1. специфічна для навантаження
2. для простору імен
3. для всієї мережі

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

Автентифікація peer

Політики автентифікації peer визначають режим двостороннього TLS, який Istio застосовує до цільових навантажень. Підтримуються наступні режими:

• PERMISSIVE: Навантаження приймають як двосторонній TLS, так і звичайний текстовий трафік. Цей режим є найбільш корисним під час міграцій, коли навантаження без sidecar не можуть використовувати двосторонній TLS. Після міграції навантажень з інʼєкцією sidecar, ви повинні переключити режим на STRICT.
• STRICT: Навантаження приймають лише трафік двостороннього TLS.
• DISABLE: Двосторонній TLS вимкнено. З точки зору безпеки, не слід використовувати цей режим, якщо ви не забезпечите власне рішення з безпеки.

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

Наступна політика автентифікації peer вимагає від усіх навантажень у просторі імен foo використовувати двосторонній TLS:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-policy"
  namespace: "foo"
spec:
  mtls:
    mode: STRICT

З політиками автентифікації peer, специфічними для навантаження, ви можете вказати різні режими двостороннього TLS для різних портів. Можна використовувати тільки порти, які навантаження заявили для конфігурації двостороннього TLS на порту. Наступний приклад вимикає двосторонній TLS на порту 80 для навантаження app:example-app, і використовує налаштування двостороннього TLS політики автентифікації peer для простору імен для всіх інших портів:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "example-workload-policy"
  namespace: "foo"
spec:
  selector:
     matchLabels:
       app: example-app
  portLevelMtls:
    80:
      mode: DISABLE

Політика автентифікації peer вище працює лише тому, що конфігурація сервісу нижче привʼязала запити з навантаження example-app до порту 80 сервісу example-service:

apiVersion: v1
kind: Service
metadata:
  name: example-service
  namespace: foo
spec:
  ports:
- name: http
    port: 8000
    protocol: TCP
    targetPort: 80
  selector:
    app: example-app

Автентифікація request

Політики автентифікації запитів визначають значення, необхідні для перевірки JSON Web Token (JWT). Ці значення включають, серед іншого, наступне:

• Місцезнаходження токена в запиті
• Видавець запиту
• Публічний набір JSON Web Key (JWKS)

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

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

Принципали

Коли ви використовуєте політики автентифікації peer і двосторонній TLS, Istio витягує ідентифікатор з автентифікації peer у source.principal. Подібним чином, коли ви використовуєте політики автентифікації запитів, Istio призначає ідентифікатор з JWT до request.auth.principal. Використовуйте ці принципали для налаштування політик авторизації та як вихідні дані телеметрії.

Оновлення політик автентифікації

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

• Використовуйте проміжні політики автентифікації peer з режимом PERMISSIVE, коли змінюєте режим з DISABLE на STRICT і навпаки. Коли всі навантаження успішно перейдуть на бажаний режим, ви можете застосувати політику з остаточним режимом. Ви можете використовувати телеметрію Istio для перевірки успішної міграції навантажень.
• При міграції політик автентифікації запитів з одного JWT на інший, додайте правило для нового JWT до політики, не видаляючи старе правило. Тоді навантаження прийматимуть обидва типи JWT, і ви можете видалити старе правило, коли весь трафік перейде на новий JWT. Однак кожен JWT повинен використовувати різне місцезнаходження.

Авторизація

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

• Авторизація між навантаженнями і між кінцевими користувачами та навантаженнями.
• Простий API: він включає єдиний AuthorizationPolicy CRD, який легко використовувати та підтримувати.
• Гнучка семантика: оператори можуть визначати власні умови для атрибутів Istio і використовувати дії CUSTOM, DENY і ALLOW.
• Висока продуктивність: авторизація Istio (ALLOW і DENY) реалізується безпосередньо в Envoy.
• Висока сумісність: підтримує gRPC, HTTP, HTTPS і HTTP/2, а також будь-які прості TCP протоколи.

Архітектура авторизації

Політика авторизації забезпечує контроль доступу до вхідного трафіку на серверному проксі Envoy. Кожен проксі Envoy має механізм авторизації, який авторизує запити під час виконання. Коли запит надходить до проксі, механізм авторизації оцінює контекст запиту згідно з поточними політиками авторизації і повертає результат авторизації: ALLOW або DENY. Оператори вказують політики авторизації Istio, використовуючи файли .yaml.

Неявне увімкнення

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

Для навантажень, до яких не застосовані політики авторизації, Istio дозволяє всі запити.

Політики авторизації підтримують дії ALLOW, DENY і CUSTOM. Ви можете застосовувати кілька політик, кожну з різною дією, за потреби для забезпечення доступу до ваших навантажень.

Istio перевіряє політики на відповідність у шарах, у наступному порядку: CUSTOM, DENY, а потім ALLOW. Для кожного типу дії Istio спочатку перевіряє, чи є політика з застосованою дією, а потім перевіряє, чи запит відповідає специфікації політики. Якщо запит не відповідає політиці в одному з шарів, перевірка переходить до наступного шару.

Наступний графік детально показує пріоритет політик:

Коли ви застосовуєте кілька політик авторизації до одного навантаження, Istio застосовує їх додатково.

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

Щоб налаштувати політику авторизації, створіть власний ресурс AuthorizationPolicy. Політика авторизації включає селектор, дію та список правил:

• Поле selector визначає ціль політики.
• Поле action визначає, чи дозволити або відхилити запит.
• Поля rules визначають, коли виконувати дію:
  • Поле from у rules визначає джерела запиту.
  • Поле to у rules визначає операції запиту.
  • Поле when визначає умови, необхідні для застосування правила.

Наступний приклад показує політику авторизації, яка дозволяє двом джерелам, службовому обліковому запису cluster.local/ns/default/sa/curl та простору імен dev, доступ до навантажень з мітками app: httpbin та version: v1 у просторі імен foo, коли запити містять дійсний JWT токен:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
- from:
  - source:
       principals: ["cluster.local/ns/default/sa/curl"]
  - source:
       namespaces: ["dev"]
   to:
  - operation:
       methods: ["GET"]
   when:
  - key: request.auth.claims[iss]
     values: ["https://accounts.google.com"]

Наступний приклад показує політику авторизації, яка відхиляє запити, якщо джерело не є простором імен foo:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin-deny
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: DENY
 rules:
- from:
  - source:
       notNamespaces: ["foo"]

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

Ціль політики

Ви можете вказати область застосування або ціль політики за допомогою поля metadata/namespace та необовʼязкового поля selector. Політика застосовується до простору імен, зазначеного в полі metadata/namespace. Якщо значення цього поля встановлено на кореневий простір імен, політика застосовується до всіх просторів імен у мережі. Значення кореневого простору імен можна налаштувати, і стандартно це istio-system. Якщо встановлено на будь-який інший простір імен, політика застосовується лише до зазначеного простору імен.

Ви можете використовувати поле selector, щоб ще більше обмежити політики для застосування до конкретних навантажень. Selector використовує мітки для вибору цільового навантаження. Selector містить список пар {key: value}, де key — це назва мітки. Якщо не встановлено, політика авторизації застосовується до всіх навантажень в тому ж просторі імен, що і політика авторизації.

Наприклад, політика allow-read дозволяє доступ "GET" і "HEAD" до навантаження з міткою app: products у просторі імен default.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-read
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
- to:
  - operation:
       methods: ["GET", "HEAD"]

Зіставлення значень

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

• Точне зіставлення: точний збіг рядка.
• Зіставлення за префіксом: рядок з кінцевим символом "*". Наприклад, "test.abc.*" збігається з "test.abc.com", "test.abc.com.cn", "test.abc.org" тощо.
• Зіставлення за суфіксом: рядок з початковим символом "*". Наприклад, "*.abc.com" збігається з "eng.abc.com", "test.eng.abc.com" тощо.
• Зіставлення за наявністю: * використовується для вказання чого завгодно, крім порожнього значення. Щоб вказати, що поле повинно бути присутнім, використовуйте формат fieldname: ["*"]. Це відрізняється від залишення поля без вказання, що означає відповідність будь-якому значенню, включаючи порожнє.

Є кілька винятків. Наприклад, наступні поля підтримують лише точне зіставлення:

• Поле key у розділі when
• Поле ipBlocks у розділі source
• Поле ports у розділі to

Наступний приклад політики дозволяє доступ до шляхів з префіксом /test/* або суфіксом */info.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: tester
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
- to:
  - operation:
        paths: ["/test/*", "*/info"]

Зіставлення з виключенням

Щоб відповідати негативним умовам, таким як notValues у полі when, notIpBlocks у полі source, notPorts у полі to, Istio підтримує зіставлення з виключенням. Наступний приклад вимагає дійсного принципалу запиту, який є похідним від JWT автентифікації, якщо шлях запиту не /healthz. Таким чином, політика виключає запити до шляху /healthz з авторизації JWT:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: disable-jwt-for-healthz
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
- to:
  - operation:
        notPaths: ["/healthz"]
    from:
  - source:
        requestPrincipals: ["*"]

Наступний приклад забороняє запити до шляху /admin для запитів без принципалів запиту:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: enable-jwt-for-admin
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: DENY
  rules:
- to:
  - operation:
        paths: ["/admin"]
    from:
  - source:
        notRequestPrincipals: ["*"]

Політика allow-nothing, deny-all і allow-all

Наступний приклад показує політику ALLOW, яка ні з чим не збігається. Якщо немає інших політик ALLOW, запити завжди будуть відхилені через поведінку “deny by default”.

Зверніть увагу, що поведінка “deny by default” застосовується лише якщо робоче навантаження має принаймні одну політику авторизації з дією ALLOW.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
spec:
  action: ALLOW
  # поле rules не вказано, і політика ніколи не матиме збігів.

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

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
spec:
  action: DENY
  # поле rules має порожнє правило, і політика завжди матиме збіг.
  rules:
- {}

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

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-all
spec:
  action: ALLOW
  # Має збіг для всього.
  rules:
- {}

Власні умови

Ви також можете використовувати секцію when для вказання додаткових умов. Наприклад, наступне визначення AuthorizationPolicy включає умову, що request.headers[version] є або "v1", або "v2". У цьому випадку ключем є request.headers[version], який є записом у атрибуті Istio request.headers, який є map.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
- from:
  - source:
       principals: ["cluster.local/ns/default/sa/curl"]
   to:
  - operation:
       methods: ["GET"]
   when:
  - key: request.headers[version]
     values: ["v1", "v2"]

Список підтримуваних значень key для умови наведено на сторінці умов.

Автентифіковані та неавтентифіковані ідентичності

Якщо ви хочете зробити робоче навантаження публічно доступним, потрібно залишити секцію source порожньою. Це дозволяє джерела від усіх (як автентифікованих, так і неавтентифікованих) користувачів і робочих навантажень, наприклад:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
- to:
  - operation:
       methods: ["GET", "POST"]

Щоб дозволити доступ лише автентифікованим користувачам, замість цього встановіть principals на "*", наприклад:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: ALLOW
 rules:
- from:
  - source:
       principals: ["*"]
   to:
  - operation:
       methods: ["GET", "POST"]

Використання авторизації Istio для простих TCP протоколів

Авторизація Istio підтримує робочі навантаження, що використовують будь-які прості TCP протоколи, такі як MongoDB. У цьому випадку ви налаштовуєте політику авторизації так само, як і для HTTP навантажень. Різниця полягає в тому, що деякі поля та умови застосовуються лише до HTTP навантажень. Ці поля включають:

• Поле request_principals у секції джерела обʼєкта політики авторизації
• Поля hosts, methods і paths у секції операцій обʼєкта політики авторизації

Підтримувані умови перераховані на сторінці умов. Якщо ви використовуєте будь-які поля, що застосовуються лише до HTTP, для TCP навантаження, Istio ігнорує ці поля в політиці авторизації.

Припустимо, у вас є сервіс MongoDB на порту 27017. Наступний приклад налаштовує політику авторизації, яка дозволяє лише сервісу bookinfo-ratings-v2 у mesh Istio доступ до навантаження MongoDB.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: mongodb-policy
  namespace: default
spec:
 selector:
   matchLabels:
     app: mongodb
 action: ALLOW
 rules:
- from:
  - source:
       principals: ["cluster.local/ns/default/sa/bookinfo-ratings-v2"]
   to:
  - operation:
       ports: ["27017"]

Залежність від Mutual TLS

Istio використовує mutual TLS для безпечної передачі деякої інформації від клієнта до сервера. Mutual TLS має бути увімкнено перед використанням будь-яких з наступних полів у політиці авторизації:

• Поля principals і notPrincipals у секції source
• Поля namespaces і notNamespaces у секції source
• Власні умови source.principal
• Власні умови source.namespace

Зверніть увагу, що рекомендується завжди використовувати ці поля з режимом strict mutual TLS у PeerAuthentication, щоб уникнути потенційних несподіваних відхилень запитів або обходу політики, коли використовується plain text трафік з режимом permissive mutual TLS.

Ознайомтесь з попередженням про безпеку для отримання додаткової інформації та альтернатив, якщо ви не можете увімкнути strict mutual TLS режим.

Дізнайтеся більше

Після вивчення базових концепцій є ще кілька ресурсів, які варто переглянути:

• Спробуйте реалізувати політику безпеки, виконуючи завдання автентифікації та авторизації.

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

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