Безпека Kubernetes з використанням пост-квантової криптографії

Криптографічний ландшафт швидко змінюється в міру наближення квантових обчислень до практичної реалізації. Хоча великомасштабні квантові машини, стійкі до помилок, ще не з’являться протягом найближчих років, їх теоретична здатність зламувати RSA та ECC — основи TLS — спонукає до ранньої міграції на Постквантову Криптографію (PQC). У цій статті ми розглянемо основи PQC, відстежимо її впровадження в TLS та Kubernetes, проаналізуємо ключові інженерні виклики та надамо експертні рекомендації для захисту сучасних кластерів від завтрашніх квантових загроз.

Що таке Постквантова Криптографія

Постквантова Криптографія — це алгоритми, розроблені для протистояння атакам як класичних, так і квантових супротивників. Квантові комп’ютери, що використовують алгоритм Шора, здатні факторизувати великі цілі числа та обчислювати дискретні логарифми за поліноміальний час, що становить загрозу для RSA та еліптичних кривих (наприклад, P-256, X25519). Схеми PQC, натомість, базуються на складних математичних задачах, таких як зменшення решіток (наприклад, Module-LWE), багатовимірні квадратичні рівняння або побудови на основі хеш-функцій.

• На основі решіток: ML-KEM (Kyber → FIPS-203), підписи Dilithium (FIPS-204).
• На основі хеш-функцій: SPHINCS+, XMSS (торгівля між безстанними та станом).
• На основі кодів, багатовимірні: Класичний McEliece, Rainbow (дослідження триває).

Процес стандартизації PQC від NIST розпочався у 2016 році і завершився у 2022 році вибором CRYSTALS-Kyber для KEM та CRYSTALS-Dilithium для підписів. У звіті NIST про перехід на 2024 рік рекомендується відмовитися від класичної криптографії після 2030 року та заборонити її використання до 2035 року. Цей багаторічний період вимагає термінового планування для гібридного TLS, оновлення сертифікатів та тестування інфраструктури.

Обмін ключами та цифрові підписи: пріоритети та терміни

TLS використовує два основні примітиви:

1. Обмін ключами (KEM/KEX): Встановлює спільний секрет для симетричного шифрування. Сьогодні пасивні атаки можуть бути розшифровані, коли з’являться квантові комп’ютери, тому гібридні KEM є пріоритетом.
2. Цифрові підписи: Аутентифікують сертифікати під час установки з’єднання. Підписи потребують більшого часу через великі відкриті ключі (наприклад, 1.5 КБ для Dilithium2 проти 32 байт для Ed25519) та вплив на продуктивність ЦП.

Перехід кореневих ЦП є особливо складним: довіра, закладена в ОС та HSM, має термін дії 10 років. Узгоджене оновлення на всіх пристроях, браузерах та хмарних провайдерах є критично важливим, перш ніж чисті PQ сертифікати можуть стати основними.

Стан механізмів обміну ключами PQC сьогодні

Гібридні схеми поєднують класичний KEX (наприклад, ECDHE на P-256 або X25519) з PQC KEM, щоб забезпечити безпеку, якщо хоча б один з компонентів витримає атаку. Найбільш поширеним є X25519 + ML-KEM-768, який узгоджується як X25519MLKEM768 у TLS1.3.

Підтримка мов і бібліотек

• Go (crypto/tls): З версії Go 1.24 (лютий 2025) X25519MLKEM768 увімкнено за замовчуванням, коли Config.CurvePreferences є nil. Бенчмарки показують приблизно 1.8× витрат на ЦП під час установки з’єднання в порівнянні з чистим X25519, але незначний вплив на пропускну спроможність після відновлення сесій.
• OpenSSL: Версія 3.5.0 (квітень 2025) додає підтримку гібридних KEM. Тепер стандартні збірки рекламують X25519MLKEM768 у ClientHello та ServerHello. Захоплення пакетів показує, що вектори відкритих ключів становлять приблизно 1.2 КБ кожен, що наближає ранні TLS повідомлення до меж MTU.
• Браузери: Chrome 131, Firefox 135, Safari 16.4+ підтримують гібридні PQC KEM, з розгортанням корпоративних прапорців на macOS/iOS 26 та оновленнях Windows 11. Телеметрія від великих CDN вказує на понад 10 мільйонів щоденних установок з’єднання з використанням PQC KEM у червні 2025 року.
• Хмарні провайдери: AWS ALB, Azure Front Door та Google Cloud Load Balancers тепер пропонують експериментальні PQC кінцеві точки. Сертифікації, такі як FIPS-203, забезпечують відповідність.

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

Постквантові KEM у Kubernetes: несподіване впровадження

Компоненти Kubernetes — API-сервер, kubelet тощо — створені на Go і покладаються на crypto/tls. Станом на Kubernetes v1.33 (квітень 2025) мінімальною версією є Go 1.24. Оскільки Config.CurvePreferences не встановлено явно в основному коді, кластери автоматично рекламують X25519MLKEM768.

“Kubernetes v1.33, безумовно, є першою великою платформою, яка за замовчуванням постачає PQC KEM, що робить кожен виклик TLS між компонентами гібридно-квантово-безпечним.”
— Д-р Еріка Чжан, провідний криптограф SecureCloud Labs

Демонстрація Minikube:

$ minikube start --kubernetes-version=v1.33.0
$ openssl s_client -connect 127.0.0.1: -CAfile ca.crt
[...]
Узгоджена група TLS1.3: X25519MLKEM768
Готово

За лаштунками ClientHello тепер містить два записи KeyShare: один для класичного X25519 (32 байти) і один для ML-KEM (≈1.2 КБ). За замовчуванням мережеві та API-проксі Kubernetes (наприклад, kube-proxy) повинні враховувати більші записи TLS.

Пастка несумісності версій Go

Go 1.23 представив експериментальний ідентифікатор KEM X25519Kyber768Draft00. У Go 1.24 ця чернетка була видалена та замінена на фінальний X25519MLKEM768. Невідповідність між клієнтом/сервером на Go 1.23 та 1.24 не дозволяє узгодити PQC KEM, знижуючи до чистого X25519.

• Контрольна панель кластера на v1.32 (Go 1.23) ⇄ kubectl v1.33 (Go 1.24): PQC установка з’єднання не вдається, повертається до класичного.
• Тихі зниження ризиковані: оператори можуть вважати, що PQC використовується, коли це не так.

Найкраща практика: узгоджувати версії Go між контрольними панелями, kubelet та клієнтами. Використовуйте CI/CD для виявлення змін tls.Config і включайте перевірки CurvePreferences у тести готовності kube-apiserver.

Обмеження: Розмір пакета TLS ClientHello

Гібридні PQC KEM відкриті ключі (~1.2 КБ для ML-KEM-768, ~1.8 КБ для ML-KEM-1024) можуть перевищувати типовий MTU (1500 Б), що призводить до фрагментації:

• Фрагментований ClientHello може бути відкинутий проксі-серверами, які очікують, що всі дані TLS установки з’єднання будуть в одному пакеті.
• Спостережено збої в плагінах CNI та сервісних мережах (наприклад, фільтри Istio envoy), коли великі записи TLS обходять евристики брандмауера.

Робочі рішення:

1. Увімкнути обмеження MSS TCP на Linux-нодах (наприклад, sysctl net.ipv4.tcp_mtu_probing=1).
2. Оновити або виправити проксі CNI та сервісних мереж для підтримки багатосегментних ClientHello.
3. Оцінити чернетки ML-KEM-512 (менші ключі) у тестових середовищах, враховуючи нижчі маржі безпеки.

Стан Постквантових Підписів

Хоча KEM мають чіткі шляхи впровадження, PQC підписи стикаються з більшими перешкодами для прийняття:

• Розміри ключів та підписів: Публічні ключі Dilithium2 ~1.6 КБ, підписи ~2.5 КБ порівняно з Ed25519, які мають 32 Б/64 Б.
• Продуктивність: Перевірка на пристроях з обмеженими ресурсами (крайові вузли, IoT) може бути в 5–10 разів повільнішою.
• Інтеграція інструментів: Go x/crypto та OpenSSL потребують нативної підтримки; CIRCL від Cloudflare забезпечує проміжне рішення через форк cfgo.

Другий раунд конкурсу підписів NIST (2024–2025) має на меті оптимізувати розміри ключів/підписів, швидкість та стійкість до побічних каналів. Go 1.26 планує додати ML-DS до кінця 2025 року, що дозволить експериментальне видавання PQ сертифікатів CA.

Вплив на Сервісні Мережі та Контролери Входу

Сервісні мережі (Istio, Linkerd, Kuma) завершують TLS на проксі, поширюючи mTLS. Впровадження PQC тут вимагає:

• Створення envoy, nginx-ingress або HAProxy з OpenSSL 3.5+ або BoringSSL PQC гілок.
• Перевірка гібридних установок з’єднання в проксі-серверах під високою навантаженістю — операції з ключами PQC споживають приблизно 1.5× ЦП у 99-му процентилі затримки.
• Переконатися, що робочі процеси SDS (Secret Discovery Service) можуть обробляти великі обсяги сертифікатів та ключів без тайм-аутів API.

“Попередні тести показують, що Istio 1.18 з OpenSSL 3.5 може масштабуватися до 10 000 RPS в гібридному режимі PQC, але використання пам’яті зростає на 20% через буферизацію більших записів TLS.”
— Мігель Фернандес, провідний розробник Istio

Розгляд реалізації в CI/CD та оновленнях кластерів

Інтеграція PQC у безперервні процеси доставки передбачає:

• Автоматизоване тестування на взаємодію: Використовуйте тестові комплекти для моделювання невідповідних ID KEM, варіацій MTU та сценаріїв зниження.
• Шаблони конфігурації: Helm charts та Kustomize overlays повинні явно оголошувати tls.CurvePreferences при націлюванні на чисто класичні або гібридні режими.
• Стратегії оновлення: Поетапне розгортання — контрольна панель → проксі вузлів → вхід → клієнтські інструменти — для раннього виявлення невідповідностей.

Включення готовності PQC у політики GitOps (наприклад, правила Open Policy Agent) забезпечує, щоб кластери не поверталися до лише спадкових кривих та що кастомні збірки kubectl відповідали криптографічним можливостям контрольної панелі.

Експертні думки та рекомендації галузі

Ведучі організації з безпеки закликають до гібридного першого підходу:

• Cloud Security Alliance: Рекомендує увімкнути PQC KEM у всіх нових кластерах Kubernetes до кінця 2025 року.
• ENISA: Підкреслює ризики в ланцюгу постачання від непатчованих плагінів CNI та радить проводити перевірки на вразливість для TLS бібліотек, що підтримують PQC.
• Red Hat: Надає сертифіковані збірки OpenShift з PQC-активованою криптографією для ядер Red Hat Enterprise Linux 9.

“Ставтеся до міграції PQC як до великого оновлення ОС: плануйте, тестуйте та поступово усувайте лише старі кінцеві точки. Не чекайте до 2030 року, щоб почати.”
— Лаура Ченг, головний архітектор безпеки CloudOps Ventures

Висновок

Шлях до квантово-безпечного Kubernetes вже активно триває — і значно далі, ніж більшість усвідомлює. З Kubernetes v1.33 гібридний обмін ключами PQC з’являється з мінімальними змінами коду завдяки стандартам Go 1.24. Проте, оперативна пильність є критично важливою: слідкуйте за невідповідностями версій Go, фрагментацією ClientHello та збоєм у сервісних мережах. Тим часом, PQC підписи та повні ієрархії CA залишаються на горизонті, чекаючи на триваючу стандартизацію NIST та підтримку інструментів. Приймаючи гібридний перший підхід, вбудовуючи перевірки PQC у CI/CD та координуючи оновлення ОС і бібліотек, команди DevOps можуть захистити кластери від загроз сьогодення та квантових супротивників майбутнього.