Всем привет! Если у вас приложение развёрнуто в RedHat OpenShift и ему требуется доступ к системам и СУБД вне кластера, то вы наверняка задумывались о том, как выпустить нужный тип трафика наружу, причём так, чтобы не открывать доступ со всех узлов кластера.
Чтобы решить эту задачу, можно использовать несколько способов. По сути каждый из них сводится к тому, чтобы выделить приложению конкретный адрес сети хоста, который затем указать на корпоративных СЗИ типа NGFW, proxy и пр. Тем не менее, каждый способ имеет свои особенности.
🍡Способ 1. Назначить egress IP (адрес из подсети узлов кластера) на ноды, затем присвоить этот адрес конкретному проекту (namespace). Это делается в 2 команды на уровне oc. Затем OpenShift сам поднимает дополнительный интерфейс и перекидывает egress IP в случае падения ноды.
После настройки трафик из подов проекта к внешним системам будет идти не с "обычного" IP хоста, а с выделенного egress IP. Этот адрес затем можно использовать на "типовых" средствах защиты в качестве source-адреса. Кроме этого можно на уровне самой платформы настроить EgressNetworkPolicy, которая позволит ограничить то, куда приложение может ходить. Но у неё, увы, есть ряд серьёзных ограничений. Для версии 4.5 это актуальный способ и по факту является заменой egress router (об этом ниже). Более подробная информация тут.
🍡Способ 2. Поднять в поде дополнительный интерфейс (отдельная сеть). Этот относительно новый подход, который может использоваться не только для контроля внешнего трафика (скорее, так просто можно делать), но и для разделения потоков трафика приложения. Реализуется эта возможность с помощью "мета" CNI-плагина, который называется multus. Multus - это open source проект, который умеет 'дёргать' другие плагины. Он и обеспечивает 'attach' дополнительного интерфейса в под. У RedHat OpenShift есть следующие плагины, которые можно дёргать multus-ом: bridge, host-device, macvlan, ipvlan, SR-IOV. Более подробно можно почитать тут и тут.
🍡Способ 3. В более старых версиях RedHat OpenShift, например, 3.11, можно еще развернуть egress router (под+сервис). Egress router разворачивается на конкретной ноде, ему тоже требуется выделенный IP. Egress router может работать в 3-х режимах (DNS proxy, HTTP/S proxy, redirect), выбор которого зависит от типа передаваемого приложением трафика. В конфигах настраивается source, destination, gateway. В этом случае надо сделать так, чтобы приложение подключалась к сервису egress router для доступа к внешним ресурсам. Этот вариант исчез из документации в 4.5. Для 3.11 описан тут.
Чтобы решить эту задачу, можно использовать несколько способов. По сути каждый из них сводится к тому, чтобы выделить приложению конкретный адрес сети хоста, который затем указать на корпоративных СЗИ типа NGFW, proxy и пр. Тем не менее, каждый способ имеет свои особенности.
🍡Способ 1. Назначить egress IP (адрес из подсети узлов кластера) на ноды, затем присвоить этот адрес конкретному проекту (namespace). Это делается в 2 команды на уровне oc. Затем OpenShift сам поднимает дополнительный интерфейс и перекидывает egress IP в случае падения ноды.
После настройки трафик из подов проекта к внешним системам будет идти не с "обычного" IP хоста, а с выделенного egress IP. Этот адрес затем можно использовать на "типовых" средствах защиты в качестве source-адреса. Кроме этого можно на уровне самой платформы настроить EgressNetworkPolicy, которая позволит ограничить то, куда приложение может ходить. Но у неё, увы, есть ряд серьёзных ограничений. Для версии 4.5 это актуальный способ и по факту является заменой egress router (об этом ниже). Более подробная информация тут.
🍡Способ 2. Поднять в поде дополнительный интерфейс (отдельная сеть). Этот относительно новый подход, который может использоваться не только для контроля внешнего трафика (скорее, так просто можно делать), но и для разделения потоков трафика приложения. Реализуется эта возможность с помощью "мета" CNI-плагина, который называется multus. Multus - это open source проект, который умеет 'дёргать' другие плагины. Он и обеспечивает 'attach' дополнительного интерфейса в под. У RedHat OpenShift есть следующие плагины, которые можно дёргать multus-ом: bridge, host-device, macvlan, ipvlan, SR-IOV. Более подробно можно почитать тут и тут.
🍡Способ 3. В более старых версиях RedHat OpenShift, например, 3.11, можно еще развернуть egress router (под+сервис). Egress router разворачивается на конкретной ноде, ему тоже требуется выделенный IP. Egress router может работать в 3-х режимах (DNS proxy, HTTP/S proxy, redirect), выбор которого зависит от типа передаваемого приложением трафика. В конфигах настраивается source, destination, gateway. В этом случае надо сделать так, чтобы приложение подключалась к сервису egress router для доступа к внешним ресурсам. Этот вариант исчез из документации в 4.5. Для 3.11 описан тут.