Как мы работаем с популярным service mesh Istio?

Мы в True Engineering уделяем большое внимания вопросам безопасности приложений: соблюдаем меры информационной безопасности на каждом этапе жизненного цикла продукта, регулярно обновляем софт и следуем best practices. Поэтому, конечно, мы знали об Istio – популярном service mesh с открытым кодом. Мы даже изучали его как решение для безопасной авторизации пользователей. Но попробовать эту технологию на реальном продукте нам удалось в прошлом году.

У одного крупного заказчика из промышленной отрасли, для которого мы разрабатываем продукт, есть определенные требования к безопасности. Приложение, над которым мы работаем расположено в публичном облаке, поэтому, согласно требованиям, все сетевое взаимодействие между микросервисами должно быть зашифровано, чтобы никто не мог перехватить трафик. Под наши запросы прекрасно подходил Istio.

Для начала коротко уточним, что такое service mesh. Наше приложение представляет собой набор микросервисов, которые выполняют определенные функции. Технология service mesh подразумевает прикрепление к каждому микросервису дополнительный контейнер – sidecar-прокси, который перехватывает весь входящий и исходящий трафик и контролирует коммуникацию между микросервисами.

Какие возможности дает такая технология? Объясним на примере функционала Istio. Всего там реализовано 3 группы функций:

• Безопасность.

То, что интересовало нас в первую очередь. Istio оборачивает весь обмен между сервисами в TLS-туннели, проще говоря шифрует. На их взаимодействие это не накладывает никакого отпечатка, для сервисов весь процесс по-прежнему прозрачен, но за счет использования Istio в действительности трафик зашифрован, и никто извне не сможет его прочитать. Также в Istio есть такое понятие, как mutualTLS. Это TLS-соединение, в котором авторизацию по сертификатам проходит не только серверная сторона, но и клиентская. В процессе установления соединения стороны обмениваются сертификатами и публичными ключами, которые в них находятся. Далее каждая сторона может проверить сертификат на валидность. Ну и ко всему прочему в Istio предусмотрено хранение, передача и автоматическое обновление сертификатов безопасности. Нам не нужно постоянно обновлять их самостоятельно.

• Управление трафиком.

Эта группа функций отвечает за балансировку нагрузки и маршрутизацию запросов. Например, это нужно для распределения трафика между сервисами или проведения канареечного развертывания, когда только часть клиентского трафика отправляется на новую версию приложения, чтобы оценить его работу и избежать ошибок. Кроме того, Istio помогает следить и контролировать как входящий в service mash, так и исходящий из нее трафик. Для этого используются специальные объекты – Ingress Gateway и Egress Gateway.

• Наблюдаемость.

У Istio довольно широкий набор метрик, что позволяет наблюдать за трафиком и выявлять аномалии. Например, можно увидеть, как отвечает тот или иной сервис, получить статистику по кодам/статусам в ответах и выявить отклонения в них. Эти данные можно легко отобразить в Grafana и даже настроить по ним алертинг.

Помимо нужных нам функций были и другие преимущества Istio, которые ощутимо влияют на удобство работы с ним:

1. Во-первых, Istio позволяет разгрузить ресурсы программистов. Управление всем набором прокси осуществляется на уровне одного контроллера Istiod (так называемый Control Plane).
2. Во-вторых, простая интеграция. Istio – это open source продукт с большой хорошей документацией, который заточен под работу c Kubernetes.

Весь процесс установки требовал всего 2–3 команд:

• В консоль управления кластером Kubernetes добавляются 2 команды:

helm install istio-base istio/base -n istio-system --set defaultRevision=default 

helm install istiod istio/istiod -n istio-system –wait

Первая добавляет в кластер CRD (специальный ресурс в Kubernetes, который позволяет вносить любые данные) объекты для Istio и некоторые настройки (ConfigMaps, Secrets и тд).

Вторая устанавливает непосредственно Istiod - контроллер который отвечает за настройку service mash.

• Далее нужно настроить инъекцию sidecar-прокси непосредственно в поды микросервисов.

 Мы сделали это на уровне неймспейса: добавить в нэймспейс специальную метку istio-injection=enabled

kubectl label namespace default istio-injection=enabled --overwrite

И все. Поды этого неймспейса после перезагрузки содержат на один контейнер больше - Istio-proxy.

 На данный момент Istio уже работает на продовом окружении заказчика. Пока мы применили его только для шифрования, но круг функций довольно большой и, возможно, в будущем будем применять технологию еще шире.