Особенности работы с TLS в кластерах OKD/OpenShift

DUMP-2022 / РТК ИТ

О компании

• Ростелеком Информационные технологии (ООО "РТК ИТ") – дочерняя компания ПАО «Ростелеком». Создана в 2014 году
• Одна из ключевых “дочек” ИТ-кластера РТК
• in-house-интегратор по разработке и внедрению информационных систем – как коммерческих продуктов для клиентов РТК, так и сервисов для автоматизации внутренних процессов корпорации
• РТК ИТ стремится к использованию современных подходов в разработке: Agile, Lean, DevOps, OpenSource и так далее
• https://rtkit.ru

Обо мне

Руслан Тагиров

Ростелеком Информационные Технологии�Региональный центр разработки ИС (Екатеринбург) / Руководитель проектов

• В IT с 2001 года, в Телекоме с 2003 (МТС, Комстар, ДартИТ, РТК ИТ), также работал в УБРиР, был ИТ-директором интернет-магазина электроники и независимым ИТ-консультантом
• Кредо: “Превращаю ХЗ в ТЗ”
• Люблю Kanban и DevOps, контейнеризацию и автоматизацию
• Помогаю командам РТК ИТ развивать архитектуру решений и внедрять DevOps-инструменты и практики
• Развиваю инфраструктуру разработки уральских подразделений РТК ИТ

email: tagirov-rur@ural.rt.ru / telegram: @ruslantagirov

Предметная область или “о чём рассказ”?

• Активно рефакторим и мигрируем Legacy-решения в k8s по всему ландшафту РТК
• Новые системы — сразу стараемся Cloud Native
• Некоторые особенности надо заранее учитывать при миграции и разработке, например, прикладной TLS-трафик, в особенности mTLS
• В k8s с TLS всё не так просто (как в OKD, так и вообще)
• На примере реального проекта: чего ожидать, как спланировать работы, как обойти часто встречающиеся проблемы
• Не будем говорить про TLS-механизмы control plane k8s и OKD / OCP

Постановка задачи

• ЕИССД — миграция Legacy в кластер OKD4
• Архитектура
• веб-интерфейс (Java монолит + [микро]сервисы)
• api-сервер МПЗ (Java монолит + [микро]сервисы)
• БД (Oracle)
• Назначение
• дилерский портал
• API-интеграция с ИС дилеров
• API- + DB- интеграции с продажами и �складами и другими ИС РТК
• Особенности
• веб-интерфейс - https
• API - mTLS с x.509 сертификатами
• Сделать, чтобы все работало после миграции, в особенности m2m-интеграции

Напомним о TLS

• SSL (Secure Sockets Layer): проприетарный от Netscape (1995)
• TLS (Transport Layer Security): открытый RFC (1999)
• Составляющие TLS (протоколы)
• TLS Handshake
• TLS Change Cipher Spec
• TLS Alert
• TLS Record Layer / Application data
• Назначение
• Шифрование
• Аутентификация
• Проверка подлинности
• Применения
• HTTPS
• STARTTLS (SMTPS, IMAPS, POP3, FTPS, LDAPS и др)
• VoiP (SIP)
• AMQP
• VPN (OpenVPN и т.п.)
• прочее

Стандартный путь любого запроса в кластер OKD

Основные точки контроля входящего трафика

• CLB - L4/TCP (HaProxy)
• Ingress Controller / OKD Router (HaProxy)
• Service (Load Balancer)
• Pod

На более низком уровне

• Container Networking Interface (CNI)
• CNI Plugins (ovn-kubernetes, calico, etc.)
• OpenShift SDN (OVS)
• kube-proxy / IPTABLES

Версии SSL и TLS - что актуально?

Основные проблемы с публикацией TLS-приложений в OKD

• Default TLS Security Profile = Intermediate (minimum TLS v1.2)
• Ingress Controller (router) для корректной работы требует запросы с TLS SNI extension

Значит, не все клиенты смогут установить TLS сессию (не поддерживается TLS v1.2 или SNI)

• Особая балансировка сессий для TLS Pass-thru routes

И ещё:

• Стандартный порт для TLS трафика в Ingress Controller (router) - 443 (можно поменять/добавить, но не быстро)
• Нельзя (штатно) опубликовать разные сервисы на одном hostname с разными портами
• https://service.rt.ru:443 & https://service.rt.ru:4443 - не будет работать�При создании route ошибка: Error "Invalid value: "service.rt.ru:443": host must conform to DNS 952 subdomain conventions" for field "spec.host"
• Нельзя публиковать сервисы c IP-адресом в hostname
• “https://121.123.123.125” — ну как бы формально это FQDN, но на практике лучше не надо
• см пункт 1 - максимум получится опубликовать только одно приложение
• В TLS Pass-Thru режиме нельзя опубликовать разные сервисы через path-based routes
• https://service.rt.ru/web -> web-app-service
• https://service.rt.ru/api -> api-app-service�не будет работать, потому что path — в HTTP-запросе внутри шифрованной TLS-сессии

Терминация TLS - варианты (стандартные)

Перед кластером

(1) TLS Offload proxy

В кластере

(2) Edge

(3) Re-Encrypt

(4) Pass-thru

Схема публикации приложения (как сделали сначала)

• WEB-портал: TLS Offload Proxy
• https://web-service.rt.ru
• терминация сертификатом *.rt.ru до кластера
• после терминации: http в кластер на поды веб-портала
• m2m API (mTLS): TLS Pass-Thru
• https://api-service.rt.ru
• TLS-трафик напрямую в поды API-сервера
• клиентские запросы с x.509 сертификатом
• API-сервер терминирует TLS-трафик со своим сертификатом
• API-сервер аутентифицирует и авторизует доступ к клиента к API

Маршрутизация HTTP в OKD

Приложение + OS клиента

• Вызывает http://mysystem.rt.ru/somepath
• GET /somepath HTTP/1.1
• Host: mysystem.rt.ru
• DNS: mysystem.rt.ru -> 123.124.125.126
• TCP: 123.124.125.126:80 и прочая сетевая “магия”

OKD

• CLB: 123.124.125.126:80 -> OKD Ingress Controller / Router
• OKD route: “mysystem.rt.ru” -> OKD service: “myservice”, port 8080
• OKD Service: “myservice” -> POD: “myservice-kjsd02:8080”

Вспомним SNI

• SNI=Server Name Indication (RFC 6066) — расширение TLS
• Только FQDN-строка
• Выбор требуемого TLS-сервиса из нескольких на одном IP-адресе
• Передается на стадии TLS Handshake как часть Client Hello–сообщения
• TLS 1.0—1.3 открытым текстом
• TLS 1.3 может быть зашифровано (ESNI)
• SNI должно поддерживаться и клиентом, и сервером

Маршрутизация HTTPS/TLS в OKD (зачем нужен SNI)

Приложение + OS клиента

• запрашивает https://myapi.rt.ru/somepath
• GET /somepath HTTP/1.1
• Host: myapi.rt.ru
• DNS: myapi.rt.ru -> 123.124.125.126
• TCP: 123.124.125.126:443 и прочая сетевая “магия”
• TLS Handshake: Client Hello with server_name=“myapi.rt.ru” (SNI)

OKD

• CLB: 123.124.125.126:443 -> OKD Ingress Controller / Router
• OKD route (использует SNI): “myapi.rt.ru” (здесь может быть TLS Edge termination) -> OKD service: “myapi-service”
• OKD Service: “myapi-service” -> POD: “myapi-pod-jsncurkc02:8080” (здесь может быть TLS Pass-thru termination)
• Устанавливается TLS-сессия
• Запрос-ответ HTTP передается внутри TLS-сессии

Как подключить “старое” приложение

На стороне клиента

(1) Client-Side TLS Proxy

В кластере

(2) NodePort

(3) ExternalIP

Почему нельзя просто обновить клиентское ПО?

• Enterprise + Legacy (дальше можно не читать ☺)
• Нельзя просто в один момент всех заставить перейти на TLS 1.2 и поддержку SNI и отрубить всех, кто не поддерживает — бизнес не поймёт
• Скорость реализации изменений у контрагентов — �за пределами вашего контроля
• Масштабы изменений влияют на скорость (например больше сотни внешних точек со старой .NET Framework 4.5: SSLv3 and TLSv1 only) — нужно дать время на обновление
• Иногда Legacy-решение в Enterprise-среде вообще нельзя обновить штатно (какой-нибудь снятый с поддержки SAP со старым Java Cryptographic Toolkit или приложение на Oracle 10 со старым пакетом UTL_HTTP)

Итоговая схема

• WEB-портал: TLS Offload Proxy
• https://web-service.rt.ru
• терминация сертификатом до кластера
• после терминации: http до подов веб-приложения
• m2m API (mTLS): TLS Pass-Thru
• https://api-service.rt.ru
• TLS напрямую в поды API-сервера
• клиент подписывает запросы x.509 сертификатом
• API-сервер терминирует трафик своим сертификатом
• API-сервер аутентифицирует и авторизует доступ к клиента к API по сертификату
• m2m API (mTLS): Временные схемы

(на выбор) с дедлайном по отключению

• Nginx на стороне клиента
• NodePort на отдельном порту, трафик приходит на дополнительный сервлет в поде, с версией TLS 1.0

Проблемы с балансировкой TLS Pass-Thru

• TLS Pass-Thru сессии могут балансироваться неравномерно из-за Load Balancing Strategy defaults:
• ROUTER_LOAD_BALANCE_ALGORITHM=leastconn
• ROUTER_TCP_BALANCE_SCHEME=source�эта опция — default для TLS pass-through routes, �т.к. TLS — это не модифицированный TCP-трафик
• Как узнать defaults на своем кластере

​

$ oc get deployment -n openshift-ingress router-default -o yaml | \

grep -A 1 -E "ROUTER_LOAD_BALANCE_ALGORITHM|ROUTER_TCP_BALANCE_SCHEME"

- name: ROUTER_LOAD_BALANCE_ALGORITHM

value: leastconn

--

- name: ROUTER_TCP_BALANCE_SCHEME

value: source

• Как чинить — указывать стратегию балансировки в маршруте
• oc annotate routes myroute haproxy.router.openshift.io/balance=roundrobin
• oc annotate routes myroute haproxy.router.openshift.io/balance=leastconn

Загрузка подов при балансировке по source

Загрузка подов при балансировке leastconn

Средства диагностики TLS трафика

• openssl

openssl s_client -connect myservice.rt.ru:443

openssl s_client -showcerts -servername myservice.rt.ru -tlsextdebug -state -debug -connect 10.10.10.1:443

openssl s_client -showcerts -servername myservice.rt.ru -tlsextdebug -state -debug -tls1_2 -connect 10.10.10.1:443

• curl

curl -v -k --resolve myservice.rt.ru:443:10.10.10.1 https://myservice.rt.ru

curl -v -k --tls-max 1.2 https://myservice.rt.ru

• tcpdump, wireshark

tcpdump -c10 -i eth1 -n -A port 443 | grep "myservice.rt.ru"

• Postman и аналоги, браузеры, скрипты bash, python и т.п.
• Jmeter и аналоги (например, проверить балансировку)
• PLG / ELK Stack и т.п. – логи кластера, графики загрузки и т.п.

Организационные заметки (для Enterpise)

• Никто ничего не понимает ☺
• даже не все инженеры
• надо представлять механизм работы, чтобы объяснить себе и другим
• подготовьте материалы и схемы для команды и контрагентов
• расскажите, как и что будете менять, почему могут потребоваться изменения на их стороне
• Не все контрагенты могут быстро применить изменения. �Терпение — добродетель
• Дайте контрагентам примеры конфигов, типовые решения и примеры команд для диагностики
• При миграции имейте две схемы обработки трафика: “старую” и “новую”, с дедлайном по переезду на новую
• Дружите с админами и инженерами, в особенности с “чужими” — быстрее помогут в диагностике и решении проблем
• Закладывайте в проекте время на тесты и переключения

Спасибо!

https://rtkit.ru