Welcome to the Linux Foundation Forum!

Lab 6.5 step 3 claims connection should be dropped but in reality it does not.

m.ramah
m.ramah Posts: 10
edited February 26 in LFD259 Class Forum

In lab 6.5 you test the deny-default networkpolicy. I can confirm that networkpolicy

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-default spec: podSelector: {} policyTypes: - Ingress - Egress

indeed does drop the connection when you try to curl http://:32000 from outside the cluster. But when i lookup the ip address of the pod and then curl it from inside the host, with port 80 at the end, i simply get back the nginx welcome page.

So did i do something wrong in the previous steps or is the information of step 3 wrong? I did not add any additional networkpolicy with allow rules for ingress or egress.

EDIT:

Doing curl http://:80 from the worker node to the cp node (provided that the pod is on the cp node) will result in a dropped connection as well when this networkpolicy is active. So it seems the pod containers are still reachable as long as they are reached from the host, but not from another node or from outside the cluster.

Is this correct?

Answers

  • chrispokorni
    chrispokorni Posts: 2,606

    Hi @m.ramah,

    Without the proper code block mark up it is difficult to tell how your manifest is structured.

    Step 3 specifically tests connectivity from either node executing curl to the service ClusterIP port 80. What was the behavior when you executed curl from cp? Did you try executing curl from the worker node; what behavior did you observe?

    Network policy implementation is highly dependent on the CNI plugin of the cluster. And, unfortunately network policy implementations are not consistent between these CNI plugins. For that reason the expected behavior may not be observed for certain rules of the policy. For instance, the Cilium CNI may not honor rules based on the cluster's Pod CIDR ipBlock, but may work very well with label based rules, such as podSelector and namespaceSelector. This is why Step 3 may not produce the expected behavior to block access to the secondapp service endpoint(s).

    Regards,
    -Chris

  • m.ramah
    m.ramah Posts: 10
    edited February 26

    Hello @chrispokorni ,

    Thank you for your response. The network policy i used was the exact same from the course. Just a simple deny-all networkpolicy for both ingress and egress. I observed the following behavior with this networkpolicy:

    1. Ingress from outside the cluster was dropped.
    2. Ingress from inside the cluster between nodes was dropped. (Pod curl from worker node to cp node where the pod was running did not work)
    3. Ingress from the host to the pod running on that host was not dropped.

    I am using the Cilium CNI plugin.

    When i removed the networkpolicy i was able to curl the pod from both outside and inside the cluster again.

  • chrispokorni
    chrispokorni Posts: 2,606

    Hi @m.ramah,

    Ingress from the host to the pod running on that host was not dropped.

    Traffic between a host and its pods is allowed for pod management purposes.

    Regards,
    -Chris

  • m.ramah
    m.ramah Posts: 10
    edited February 26

    @chrispokorni said:
    Hi @m.ramah,

    Ingress from the host to the pod running on that host was not dropped.

    Traffic between a host and its pods is allowed for pod management purposes.

    Regards,
    -Chris

    So page 1 of lab 6.5 needs to be changed then. Because the text of step 3 falsely claims that the connection should drop when you try to curl the nginx instance inside the pod from the host.

Categories

Upcoming Training