В настоящее время я защищаю свой кластер EKS с помощью NetworkPolicies и Calico, поэтому я провожу некоторые тесты, чтобы увидеть, как они работают, я развернул структуру для Po C следующим образом:
Internet -> NLB -> Nginx Pod
Модуль Nginx был развернут с использованием deploy.yaml только с 1 репликой. Я также развернул службу NodePort Kubernetes, NLB указывает на эту службу. Я добавил простую NetworkPolicy, которая блокирует весь трафик c, за исключением того, что поступил от моего cidr (Inte rnet). Это работает как задумано.
Однако, проверяя nginx logs, IP показал, что это не "реальный IP", это IP узла (что является ожидаемым поведением как kube-proxy перенаправляет с одного узла на правильный) и, проверяя заголовки, нет никаких признаков X-Forwarded-For или аналогичных.
Я развернул echo-server с той же структурой, чтобы увидеть полный запрос и заголовки. К моему удивлению, NetworkPolicy больше не работал, я не смог использовать свои настоящие IP на NetworkPolicy, только локальные IP-адреса. Мне пришлось разрешить узлам cidr, чтобы он работал.
С официальной страницы Kubernetes ( NetworkPolicies: Поведение для селекторов * и 1029 *)
Механизмы входа и выхода кластера часто требуют перезаписи исходного или целевого IP-пакетов. В тех случаях, когда это происходит, не определено, происходит ли это до или после обработки NetworkPolicy, и поведение может отличаться для разных комбинаций сетевого плагина, поставщика облака, реализации Сервиса и т. Д. c.
Однако я не уверен, что это является причиной такого поведения, и если да:
- Что заставляет
NetworkPolicies иметь возможность получить реальный IP или нет? Разве он не должен действовать до достижения службы? - Как я смог использовать реальный источник IP в качестве фильтра, когда служба была
Nginx, но не с другими службами> (я также пытался добавить NetworkPolicies прямо к Kibana стручку, и он не работает)