Как сервисная сетка может помочь с безопасностью микросервисов

Я вижу, как многие клиенты переходят на микросервисы (независимо от того, должны они или нет — это тема для другого поста ), и при этом они пытаются решить некоторые сложные проблемы масштабирования организации. Однако детали перехода к микросервисной архитектуре часто заменяют некоторые старые проблемы новыми. У большинства заказчиков, с которыми я общаюсь, есть стратегия развертывания их архитектуры как в локальном, так и в публичном облаках. Разбиение приложений на более мелкие сервисы И наличие сайтов / платформ с несколькими развертываниями создает некоторые серьезные проблемы. На мой взгляд, реализации сервисных сеток, такие как Istio, направлены на решение некоторых из этих проблем. Я на самом деле могу многое сказать об Istio и Service Mesh в целом, поэтому, пожалуйста, не стесняйтесь следить за @christianposta, чтобы участвовать и быть в курсе последних новостей .

На этом пути вы столкнетесь с одной проблемой: безопасность.

Знаю, знаю. Как разработчики, вы, вероятно, уже имеете отношения ненависти-ненависти с безопасностью — микросервисы делают это еще хуже. Разбивая приложения на более мелкие сервисы, мы увеличиваем площадь для атак. Хотя здесь есть много аспектов безопасности (уязвимость приложений, уязвимость платформы, защита данных, транспорт / сеть и т. Д.), Я собираюсь сосредоточить этот пост в основном на том, как микросервисы взаимодействуют друг с другом, и на некоторых возникающих проблемах.

Традиционно мы предполагали, что сетевых границ / периметров было достаточно, чтобы спасти нас; т. е. нашим приложениям не приходилось учитывать ЭТО в плане безопасности на транспорте, потому что мы были в «защищенной внутренней сети». Остановись и подумай секунду. Вы защищаете свои внутренние приложения с помощью SSL / TLS? Все коммуникации, которые мы обычно выполняли внутри одного монолита через локальные вызовы, теперь передаются по сети. Первое, что нам нужно сделать, это зашифровать весь наш внутренний трафик. Если вы используете микросервисы без TLS на транспорте, вы настраиваете себя на неприятные проблемы с безопасностью.

Некоторые зрелые клиенты получили возможность шифровать весь трафик своих микросервисов, но не без значительных затрат. Поддержка инфраструктуры открытых ключей, выдача ключей и сертификатов, их установка, ротация и т. Д. — довольно дорогое испытание. Не берите в голову головную боль, возникающую при попытке настроить правильные доверенные хранилища / хранилища ключей (Java), правильные алгоритмы SSL, убедиться, что у вас есть правильные цепочки сертификатов и т. Д., И т. Д. Я лично потратил много дней, пытаясь сделать это «правильным» , И затем, когда вы понимаете это правильно, вы не хотите больше касаться этого.

Я также видел случаи, когда разработчики соглашаются с SSL / TLS, а затем внедряют свой код в IST / UAT и т. Д., Только чтобы обнаружить, что конфигурация безопасности, которую они имели в более низких средах, не работает. И в спешке, чтобы продвинуть вещи к производству, они делают вещи как отключение проверки TLS. Уч.

Сервисная сетка, такая как Istio, несколько упрощает это. С Istio все экземпляры приложения имеют свой собственный контейнер с коляской. Эта коляска действует как сервисный прокси для всего исходящего и входящего сетевого трафика.

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

Например, когда Istio работает в Kubernetes , при каждом развертывании приложения вы должны назначить служебную учетную запись, под которой должно запускаться приложение, после чего istio позаботится обо всем остальном. Istio создаст пару сертификат / ключ для вашей учетной записи службы, подпишет сертификат ключом корневого центра сертификации и выдаст сертификат / ключи в качестве секрета в Kubernetes. Этот секрет будет смонтирован в Pod, где работает ваше приложение и служебный прокси-сервер Istio, а служебный прокси-сервер будет использовать сертификаты / ключи для установки mTLS.

Другая проблема безопасности с микросервисами — это запутанная проблема депутатов . В этом случае конечный пользователь попросил службу сделать что-то от ее имени. В этом случае служба может быть авторизована для выполнения этого действия, но конкретный пользователь может не быть. Каким-то образом мы должны связать идентичность пользователя в уравнении и оценить полномочия на основе этой идентичности. Одним из способов сделать это является использование токенов значения, таких как JWT .

Несколько вещей, чтобы сказать об этом:

Во-первых, если вы передаете открытые токены JWT (без TLS / mTLS), вы напрашиваетесь на серьезные проблемы. Эти токены по умолчанию не зашифрованы (просто подписаны), и их легко можно подключить и воспроизвести в вашем сервисе. Опять же, вот где Istio mTLS может помочь. Но даже при включенном mTLS токен может быть пропущен другим способом (я видел, как это жестко закодировано в коде src !!). Если все ваши сервисы передают JWT через любой другой сервис, вы снова открываете себя к проблеме воспроизведения.

Во-вторых, если вы пытаетесь выполнить проверку JWT на всех ваших микросервисах, вы сталкиваетесь с теми же проблемами, что и с библиотеками отказоустойчивости . Каждый сервис имеет свои библиотеки и собственную реализацию проверки JWT. Несмотря на то, что такие проекты, как JBoss Keycloak, обеспечивают отличную многоязычную поддержку, это становится обузой как для разработчиков библиотек, так и для разработчиков приложений, которые зависят от этих библиотек. Убедиться, что все они реализованы правильно, последовательно и единообразно, — подвиг, чреватый проблемами.

К счастью, Istio может помочь с обеими этими областями.

Во-первых, Istio может автоматизировать для вас проверку JWT независимо от структуры / языка приложения. Вы можете определить EndUserAuthenticationPolicySpec который настраивает провайдера идентификации / провайдеров учетных данных, который будет использоваться для проверки :

Затем вы можете привязать его к конкретным сервисам:

Примечание: этот пример пришел от моего коллеги Камеша Сампата . В этой конфигурации мы настроили Keycloak в качестве менеджера удостоверений и эмитента токенов JWT (после OpenID Connect). Для получения дополнительной информации см. Этот блог . Когда вызов поступает в сервис, он будет отклонен, если у него нет токена JWT Bearer. Эта конфигурация установит фильтр Envoy jwt, который фактически берет на себя ответственность за проверку подписи JWT:

Наконец, как насчет распространения токена JWT?

По умолчанию Istio распространяет только один токен JWT. Он возьмет тело токена JWT и передаст его приложению в отдельном заголовке. Тело JWT будет отправлено в заголовке sec-istio-auth-userinfo . Приложение будет отвечать за повторную отправку нового токена на основе идентификатора конечного пользователя и идентификатора службы. Таким образом, мы можем использовать токены для одноразового использования и не распространять JWT повсеместно. Реализация для этого все еще развивается, и я настоятельно рекомендую следовать здесь и здесь .

Это все на данный момент. По мере того, как история безопасности в Истио усиливается, я обязательно буду следить. Следуйте за мной, следуйте по @christianposta для получения последних новостей о микросервисах , Service Mesh, Istio и других.