У меня есть какая-то более-менее сложная микросервисная архитектура, где Apache Ignite используется в качестве базы данных/кэша без сохранения состояния. Воспламенение Стручок
единственный Стручок
в своем Пространство имен
и архитектура должна пройти проверку безопасности, которую она не пройдет, если я не применю самые строгие сетевая политика
возможно для выход
трафик. Он должен ограничивать весь возможный трафик, который не нужен самому Ignite.
Сначала я подумал: Хорошо, Ignite не передает трафик другим Стручок
s (в этом нет других подов Пространство имен
), так что это будет легко сделать, ограничив все выход
трафик в Пространство имен
где Ignite является единственным Стручок
! ...
Ну, это на самом деле не сработало:
Любой выход
Правило, даже если я разрешаю трафик ко всем портам, упомянутым в документации Ignite, приведет к сбою запуска с IgniteSpiException
это говорит Не удалось получить IP-адреса модулей Ignite., Вызвано: java.net.ConnectException: время ожидания операции истекло (время ожидания соединения истекло)
.
Проблема, похоже, в TcpDiscoveryKubernetsIpFinder
, особенно метод получить зарегистрированные адреса (...)
что, очевидно, делает некоторый исходящий трафик внутри Пространство имен
для регистрации IP-адресов узлов Ignite. Порт disovery 47500 конечно разрешен, но ситуацию это не меняет. Функционал Ignite с другим Стручок
с другого Пространство имен
с работает без выход
применяются правила, что означает (для меня), что конфигурация, касающаяся КластерРоле
, Кластерролебиндинг
, а Оказание услуг
в Пространство имен
и конфигурация xml самого Ignite и т. д. кажется правильной. Даже вход
правила, ограничивающие трафик из других пространств имен, работают должным образом, разрешая именно нужный трафик.
Вот политики, которые я применил:
[РАБОТАЕТ, блокируется только нежелательный трафик]:
## Запрещает весь входящий трафик ко всем модулям в пространстве имен
Версия API: networking.k8s.io/v1
вид: NetworkPolicy
метаданные:
имя: запретить все входы в кэш-память
пространство имен: cache-ns
спецификация:
# ничего не выбирая здесь, будет запрещен весь трафик между модулями в пространстве имен
подселектор:
matchLabels: {}
# маршруты трафика, которые необходимо учитывать, здесь: исключительно входящие
policyTypes:
- Вход
## Разрешает необходимый входящий трафик
Версия API: networking.k8s.io/v1
вид: NetworkPolicy
метаданные:
имя: нетпол-кэш-нс
пространство имен: cache-ns
# определяет модули, на которые нацелена эта политика
спецификация:
policyTypes:
- Вход
подселектор:
метки соответствия:
приложение: зажечь
# <----входящий трафик----
вход:
- от:
- селектор пространства имен:
метки соответствия:
зона: где-то еще
подселектор:
matchExpressions:
- ключ: приложение
оператор: В
values: [some-pod, other-pod] # фиктивные имена, эти поды не имеют значения
порты:
- порт: 11211#JDBC
протокол: TCP
- порт: 47100 # SPI-связь
протокол: TCP
- порт: 47500 # Обнаружение SPI (КРИТИЧЕСКОЕ, скорее всего...)
протокол: TCP
- порт: 10800 # SQL
протокол: TCP
# ----исходящий трафик---->
# ВОВСЕ НЕТ
С этими двумя приложениями все работает нормально, но аудит безопасности скажет что-то вроде
Где ограничения на выход
? Что, если этот узел взломан через разрешенные маршруты, потому что один из модулей, использующих эти маршруты, был взломан ранее? Тогда он может вызвать C&C-сервер! Эта конфигурация не будет разрешена, усильте свою архитектуру!
[БЛОКИРОВКА нужного/необходимого трафика]:
Вообще запретить весь трафик...
## Запрещает весь трафик ко всем модулям в пространстве имен
Версия API: networking.k8s.io/v1
вид: NetworkPolicy
метаданные:
имя: запретить весь трафик в кеше-нс
пространство имен: cache-ns
спецификация:
# ничего не выбирая здесь, будет запрещен весь трафик между модулями в пространстве имен
подселектор:
matchLabels: {}
# маршруты трафика, которые необходимо учитывать, здесь: исключительно входящие
policyTypes:
- Вход
- Egress#<------ ЭТО ОТЛИЧИЕ ОТ РАБОЧЕГО ВЫШЕ
... и затем разрешать определенные маршруты
Версия API: networking.k8s.io/v1
вид: NetworkPolicy
метаданные:
имя: нетпол-кэш-нс-выход
пространство имен: cache-ns
# определяет модули, на которые нацелена эта политика
спецификация:
policyTypes:
- Выход
подселектор:
метки соответствия:
приложение: зажечь
----исходящий трафик---->
выход:
# [НЕ ДОСТАТОЧНО]
# разрешить выход в это пространство имен через определенные порты
- к:
- селектор пространства имен:
метки соответствия:
зона: кеш-зона
порты:
- протокол: TCP
порт: 10800
- протокол: TCP
порт: 47100 # Связь SPI
- протокол: TCP
порт: 47500
# [НЕ ДОСТАТОЧНО]
# разрешить разрешение DNS в целом (без ограничений пространства имен или pod)
- порты:
- протокол: TCP
порт: 53
- протокол: UDP
порт: 53
# [НЕ ДОСТАТОЧНО]
# разрешить выход в kube-систему (метка присутствует!)
- к:
- селектор пространства имен:
метки соответствия:
зона: kube-система
# [НЕ ДОСТАТОЧНО]
# разрешить выход в этом пространстве имен и для модуля запуска
- к:
- селектор пространства имен:
метки соответствия:
зона: кеш-зона
подселектор:
метки соответствия:
приложение: зажечь
# [НЕ ДОСТАТОЧНО]
# разрешить трафик на IP-адрес ignite pod
- к:
- IP-блок:
cidr: 172.21.70.49/32 # не будет работать, так как эти адреса динамические
порты:
- порт: 11211#JDBC
протокол: TCP
- порт: 47100 # SPI-связь
протокол: TCP
- порт: 47500 # Обнаружение SPI (КРИТИЧЕСКОЕ, скорее всего...)
протокол: TCP
- порт: 49112#JMX
протокол: TCP
- порт: 10800 # SQL
протокол: TCP
- порт: 8080# ОТДЫХ
протокол: TCP
- порт: 10900 # тонкие клиенты
протокол: TCP
Используемая версия Apache Ignite — 2.10.0.
А теперь вопрос ко всем читателям:
Как я могу ограничить Выход
до абсолютного минимума внутри Пространство имен
чтобы Ignite запускался и работал корректно? Достаточно ли просто отрицать Выход
за пределы кластера?
Если вам нужно больше батат
s для обоснованного предположения или подсказки, пожалуйста, не стесняйтесь запрашивать их в комментарии.
И извините за теги, если это кажется неуместным, я не мог найти тег kubernetes-сетевая политика
так как он присутствует в stackoverflow.
ОБНОВИТЬ:
выполнение nslookup -debug kubernetes.default.svc.cluster.local
изнутри зажигательной капсулы без какой-либо политики, ограничивающей выход
показывает
BusyBox v1.29.3 (24.01.2019, 07:45:07 UTC) двоичный код с несколькими вызовами.
Использование: nslookup HOST [DNS_SERVER]
Запросить DNS о HOST
Как только (любой) сетевая политика
применяется, что ограничивает Выход
к определенным портам, модулям и пространствам имен модуль Ignite отказывается запускаться, и поиск не достигает kubernetes.default.svc.cluster.local
больше.
Выход
к DNS было разрешено (UDP 53 для k8s-app: kube-dns) — поиск IP по-прежнему невозможен