Анонс Istio 1.28.6

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

Зміни

• Додано підтримку Helm v4 (server-side apply). Виправлено конфлікт власності поля failurePolicy у вебхуку, що призводив до невдачі helm upgrade з SSA. (Тікет #58302) (Тікет #59367)

• Додано змогу вказати авторизовані простори імен для точок доступу для налагодження, коли ENABLE_DEBUG_ENDPOINT_AUTH=true. Увімкніть цю функцію, встановивши для DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES список авторизованих просторів імен, розділених комами. Системний простір імен (зазвичай istio-system) завжди авторизований.

• Додано підтримку блоків CIDRs у JWKS URIs при отриманні публічних ключів для перевірки JWT. Якщо будь-який розвʼязаний IP з JWKS URI відповідає блоку CIDR, Istio пропустить отримання публічного ключа та використає фейковий JWKS для відвернення запитів з JWT токенами.

• Виправлено конфлікт менеджеру полів у ValidatingWebhookConfiguration під час виконання helm upgrade із застосуванням на стороні сервера в інструментах, що враховують .Release.IsUpgrade (Helm 4, Flux). Тепер поле failurePolicy опускається з шаблону веб-хука під час оновлення, зберігаючи значення, встановлене під час виконання контролером веб-хука. Для інструментів, що використовують helm template із SSA, встановіть base.validationFailurePolicy: Fail, щоб уникнути конфлікту.

• Виправлено блокування CIDR-адрес JWKS за допомогою спеціальної функції контролю в налаштованому DialContext. Ця функція фільтрує з’єднання після розпізнавання DNS, але до виклику, що дозволяє блокуванню слідувати за перенаправленнями та шляхом виявлення емітента. Це також зберігає функції стандартного DialContext, такі як «happy eyeballs» та dialSerial (послідовне тестування кожної розпізнаної IP-адреси).

• Виправлено регулярний вираз для порівняння serviceAccount у AuthorizationPolicy, щоб ім’я службового облікового запису правильно бралося в лапки, що забезпечує коректне зіставлення службових облікових записів, у назвах яких містяться спеціальні символи. (Тікет #59700)

• Виправлено проблему, через яку команда iptables не чекала на отримання блокування файлу /run/xtables.lock, що призводило до появи в журналах помилок, які вводили в оману. (Тікет #58507)

• Виправлено обробку походження CORS у Gateway API у випадках, коли для ігнорування невідповідних попередніх запитів використовується символ-замінник.

• Виправлено розбір заголовка Origin у Gateway API для більш строгого контролю.

• Виправлено: збій istiod, що виникав, коли PILOT_ENABLE_AMBIENT=true, але AMBIENT_ENABLE_MULTI_NETWORK не було встановлено, а ресурс WorkloadEntry існував у мережі, відмінній від локального кластера.

• Виправлено помилки istiod під час запуску, коли версія CRD перевищує максимально підтримувану на кластері. TLSRoute версії v1.4 та нижче підтримуються; v1.5 та вище будуть проігноровані. (Тікет #59443)

• Виправлено застосування кількох ресурсів VirtualResource для одного hostname до waypoints. (Тікет #59483)

• Виправлено проблему, при якій всі Gateways були перезавантажені після перезавантаження istiod. (Тікет #59709)

• Виправлено проблему, при якій встановлення обмежень ресурсів (resource limits) або запитів (requests) до null призводило до помилок валідації (cpu request must be less than or equal to cpu limit of 0). Це впливало на інʼєкцію проксі, генерацію шлюзів та розгортання чартів Helm. (Тікет #58805)

• Виправлено: імена хостів TLSRoute не обмежувалися перетином з іменем хосту прослуховувача Gateway. Раніше TLSRoute із широким іменем хосту (наприклад, *.com), прив’язаний до прослуховувача з більш вузьким іменем хосту (наприклад, *.example.com), неправильно зіставлявся з повним іменем хосту маршруту, а не лише з перетином (*.example.com), як того вимагає специфікація API Gateway. (Тікет #59229)

• Виправлено помилку, через яку стандартне значення параметра percent для retryBudget у DestinationRule було неправильно встановлено на 0,2% замість передбачених 20%. (Тікет #59504)

• Виправлено відсутність обмеження розміру для розпакованих за допомогою gzip бінарних файлів WASM, отриманих через HTTP; це відповідає обмеженням, які вже застосовуються до інших шляхів завантаження.

• Виправлено відсутність ReadHeaderTimeout та IdleTimeout на istiod webhook HTTPS server (port 15017); це узгоджено з поточними таймаутами на HTTP server (port 8080).

• Виправлено гонитву, що призводила до періодичних помилок у журналах типу “proxy::h2 ping error: broken pipe”. (Тікет #59192) (Тікет #1346)