Skip to content

egressDeny policy doesn't block ClusterIP service traffic #39730

@gentoo-root

Description

@gentoo-root

Is there an existing issue for this?

  • I have searched the existing issues

Version

equal or higher than v1.17.4 and lower than v1.18.0

What happened?

Bug found when adding more test coverage (#39667). Essentially, the connectivity tests start failing if you just change IPFamilyAny to IPFamilyV4 at this line (which makes the test reach the service by its ClusterIP instead of the hostname). After a discussion with @gandro it doesn't look expected.

How can we reproduce the issue?

  1. Deploy Cilium with --set kubeProxyReplacement=true --set ingressController.enabled=true --set ingressController.loadbalancerMode=dedicated.
  2. Run cilium-cli connectivity test -vv --test 'pod-to-ingress-service-deny-backend-service/pod-to-ingress-service' to create the following services and pods:
$ kubectl -n cilium-test-1 get services -o wide
NAME                       TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE   SELECTOR
cilium-ingress-same-node   NodePort   10.99.170.106   <none>        80:30986/TCP,443:30809/TCP   24m   <none>
echo-same-node             NodePort   10.99.89.37     <none>        8080:30496/TCP               24m   name=echo-same-node
$ kubectl -n cilium-test-1 get pods -o wide
NAME                              READY   STATUS    RESTARTS   AGE   IP             NODE                   NOMINATED NODE   READINESS GATES
client-645b68dcf7-mzcxl           1/1     Running   0          24m   10.217.1.71    c3-small-x86-01-max2   <none>           <none>
client2-66475877c6-zzh2l          1/1     Running   0          24m   10.217.1.153   c3-small-x86-01-max2   <none>           <none>
echo-same-node-6c545975c6-xq75k   2/2     Running   0          24m   10.217.1.206   c3-small-x86-01-max2   <none>           <none>
  1. Go into the client pod: kubectl -n cilium-test-1 exec -it client-645b68dcf7-mzcxl -- /bin/sh -l.
  2. From inside the client pod, make sure that the service is reachable by its hostname: curl -vv cilium-ingress-same-node.cilium-test-1, by ClusterIP: curl -vv 10.99.170.106, by the pod IP: curl -vv 10.217.1.206:8080.
  3. Apply the policy: kubectl -n cilium-test-1 apply -f cilium-cli/connectivity/builder/manifests/deny-ingress-backend.yaml.
  4. From inside the client pod, try to reach the service again.
  5. Observe that it's no longer reachable by the pod IP and by the hostname (curl: (6) Could not resolve host: cilium-ingress-same-node.cilium-test-1 — I'm not sure whether a DNS error is expected here), but it's still reachable by the ClusterIP of the service: curl -vv 10.99.170.106.

Cilium Version

cilium-cli: v1.18.0-pre.2-352-g724043c0f0 compiled with go1.24.2 on linux/amd64
cilium image (default): v1.17.3
cilium image (stable): v1.17.4
cilium image (running): 1.18.0-dev

Kernel Version

Linux c3-small-x86-01-max2 6.15.0-rc4+ #51 SMP PREEMPT_DYNAMIC Tue May 6 15:47:28 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Kubernetes Version

Client Version: v1.32.4
Kustomize Version: v5.5.0
Server Version: v1.32.2

Regression

No response

Sysdump

cilium-sysdump-20250526-173222.zip

Relevant log output

Anything else?

No response

Cilium Users Document

  • Are you a user of Cilium? Please add yourself to the Users doc

Code of Conduct

  • I agree to follow this project's Code of Conduct

Metadata

Metadata

Assignees

Labels

area/agentCilium agent related.area/proxyImpacts proxy components, including DNS, Kafka, Envoy and/or XDS servers.kind/bugThis is a bug in the Cilium logic.kind/community-reportThis was reported by a user in the Cilium community, eg via Slack.needs/triageThis issue requires triaging to establish severity and next steps.sig/policyImpacts whether traffic is allowed or denied based on user-defined policies.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions