Безпека, ЧаПи

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

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

Якщо ви встановили Istio з values.global.proxy.privileged=true, ви можете використовувати tcpdump, щоб визначити статус шифрування. Також, з Kubernetes 1.23 і пізніших версій, як альтернатива встановленню Istio як привілейованого сервісу, ви можете використовувати kubectl debug для запуску tcpdump в тимчасовому контейнері. Дивіться міграцію на взаємний TLS в Istio для інструкцій.

Коли включено STRICT режим взаємного TLS, не-Istio робочі навантаження не можуть взаємодіяти з Istio сервісами, оскільки у них не буде відповідного сертифікату клієнта Istio.

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

Дивіться Правила автентифікації для отримання додаткової інформації.

Якщо взаємний TLS увімкнено, перевірки працездатності HTTP та TCP від kubelet не працюватимуть без змін, оскільки kubelet не має сертифікатів, виданих Istio.

Є кілька варіантів:

1. Використання перезапису перевірок для перенаправлення запитів liveness і readiness безпосередньо до сервісу. Дивіться більше інформації в розділі Перезапис перевірок. Ця опція стандартно увімкнена і рекомендована.

2. Використання окремого порту для перевірок працездатності та ввімкнення взаємного TLS лише на звичайному сервісному порті. Докладніше читайте в розділі Перевірка працездатності сервісів Istio.

3. Використання режиму PERMISSIVE для сервісу, щоб він міг приймати як відкритий, так і взаємний TLS трафік. Зверніть увагу, що взаємний TLS не буде примусовим при використанні цієї опції.

Для робочих навантажень, що виконуються в Kubernetes, термін дії їх сертифікатів Istio стандартно становить 24 години.

Цю конфігурацію можна змінити, налаштувавши поле proxyMetadata у конфігурації проксі. Наприклад:

proxyMetadata:
  SECRET_TTL: 48h

Ні. Коли на серверних робочих навантаженнях використовується traffic.sidecar.istio.io/excludeInboundPorts, Istio все одно налаштовує клієнтський Envoy для стандартного надсилання взаємного TLS. Щоб змінити це, потрібно налаштувати правило Destination Rule з режимом взаємного TLS, встановленим на DISABLE, щоб клієнти надсилали звичайний текст на ці порти.

Ви можете зіткнутися з тим, що MySQL не може підключитися після встановлення Istio. Це відбувається через те, що MySQL використовує протокол server first, який може заважати виявленню протоколу Istio. Зокрема, використання режиму PERMISSIVE для mTLS може спричиняти проблеми. Ви можете побачити повідомлення про помилки, такі як ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0.

Цю проблему можна вирішити, увімкнувши режим STRICT або DISABLE, або ж налаштувавши всіх клієнтів на надсилання mTLS. Дивіться більше інформації в розділі server first protocols.

Так. Istio надає можливості авторизації як для HTTP, так і для простих TCP сервісів у mesh. Дізнатися більше.

Дотримуючися інструкцій в завданні Захищений трафік Ingress, можна забезпечити безпеку Istio Ingress так, щоб він приймав лише TLS трафік.

Так, можна. Це працює як з увімкненим, так і з вимкненим взаємним TLS.