Lab 6.3 / Exercise 6.5 is missing an important testing note

I've been following Lab 6.3, testing the deny-default NetworkPolicy. I was confused because although the egress was (not) working as expected, the ingress rules didn't appear to be respected. Looking at the K8S documentation I think I found the answer: connections to a pod from the node that it is running on, are not limited.

From the documentation: When a pod is isolated for ingress, the only allowed connections into the pod are those from the pod's node and those allowed by the ingress list of some NetworkPolicy that applies to the pod for ingress

Here's the policy:

cameron_kerr_nz@a-cp:~/app2$ k describe networkpolicy deny-default
Name:         deny-default
Namespace:    default
Created on:   2023-06-24 10:26:02 +0000 UTC
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    <none> (Selected pods are isolated for ingress connectivity)
  Allowing egress traffic:
    <none> (Selected pods are isolated for egress connectivity)
  Policy Types: Ingress, Egress

From my control-node (where secondapp pod is running, I can still connect just fine:

cameron_kerr_nz@a-cp:~/app2$ k get pods -o wide -l example=secondapp
NAME        READY   STATUS    RESTARTS   AGE   IP               NODE   NOMINATED NODE   READINESS GATES
secondapp   2/2     Running   0          37m   192.168.51.132   a-cp   <none>           <none>
cameron_kerr_nz@a-cp:~/app2$ curl -s 192.168.51.132 | grep '<title>'
<title>Welcome to nginx!</title>

I can also connect to the service:

cameron_kerr_nz@a-cp:~/app2$ k get svc secondapp -o wide
NAME        TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE    SELECTOR
secondapp   NodePort   10.98.24.37   <none>        80:32000/TCP   7d6h   example=secondapp
cameron_kerr_nz@a-cp:~/app2$ curl -s 10.98.24.37 | grep '<title>'
<title>Welcome to nginx!</title>

Let's try from another node, which is not the node running the pod, I get denied when trying to access the pod or the service:

cameron_kerr_nz@a-worker-1:~$ curl -s 192.168.51.132 | grep '<title>'
^C (ie. traffic was being dropped, timing out)

cameron_kerr_nz@a-worker-1:~$ curl -s '10.98.24.37' | grep '<title>'
^C (ie. traffic was being dropped, timing out)

Please update Exercise 6.5, as it makes no mention of this aspect of where the limit is actually being implemented. Not being aware of this behaviour will impact on some people's testing.

My versioning at the time of writing:

cameron_kerr_nz@a-worker-1:~$ k get nodes
NAME         STATUS   ROLES           AGE   VERSION
a-cp         Ready    control-plane   27d   v1.26.1
a-worker-1   Ready    <none>          26d   v1.26.1

Thanks,
Cameron