Решил попробовать nginx ingress controller на HostNetwork (baremetal). Встал вопрос,

как теперь ему разрешить трафик, а трафик между namespaces запретить?
Если для ограничения подов в рамках одного namespace используется данные правила:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-from-other-namespaces
spec:
podSelector:
matchLabels:
ingress:
- from:
- podSelector: {}

То блочится, так же и трафик с ingress controller'a.

Попробовал этими разрешить, но тоже мимо.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-ingresscontroller
spec:
podSelector:
matchLabels:
app.kubernetes.io/name: ingress-nginx
ingress:
- from:
- ipBlock:
cidr: 0.0.0.0/0
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: ingress-to-backends
spec:
podSelector:
matchLabels:
ingress:
- from:
- podSelector:
matchLabels:
app.kubernetes.io/name: ingress-nginx

у тебя же нетворк полиси namespace-scoped

Первое правило - вообще какая-то хрень. ты разрешаешь доступ К ингресс-контроллеру со всех адресов. второе не работает, потому что у контроллера у тебя адрес УЗЛА, а куб через под-селектор может только адреса подов выбирать. т.е. во второе правило тебе надо написать - from: - ipblock: cidr: <ip_address_node>/32

Чтобы разрешить трафик из namespace где ingress controller на другой namespace, я делаю такое правило: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: project-allow-from-ingress namespace: project-namespace spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: name: project-namespace - namespaceSelector: matchLabels: name: ingress При условии что у namespace "project-namespace" есть метка name: project-namespace, а namespace "ingress" есть метка name: ingress. Тут разрешается трафик внутри самого себя + из namespace: ingress У меня тоже hostNetwork: true, на ingress controller. В таком варианте всё работает как надо. Конкретно с podSelector толком не замарачивался, правила нужные мне писал давно. Но работают до сих пор на cni kube-router и cilium. В cilium есть нюанс, создаю еще такое правило https://pastebin.com/jpKmrNNt, для каждого namspace, иначе ничего не работает.

а почему не CiliumNetworkPolicy все не закрыть?

мне хватает NP. Не хочу отдельные CRD юзать, NP работают в любой CNI (которая поддерживает их). Но в cilium пришлось добавлять почему-то дополнительное правило на его CRD

NP плохо работают

мне норм, проблем не было. Хватает NP

увы, возможно дело в calico. сделал так же - не сработало.

дебаж, на уровне правил firewall'а