Cilium: Incorrect conversion of KNP Egress to CNP Ingress

Created on 28 Mar 2018  路  3Comments  路  Source: cilium/cilium

Initial state:

Manalis-MBP:cilium manalibhutiyani$ kubectl get cnp
No resources found.
Manalis-MBP:cilium manalibhutiyani$ 

on cilium:

root@minikube:~# cilium policy get
[]
Revision: 89
root@minikube:~# 

Applying KNP:

Manalis-MBP:cilium manalibhutiyani$ cat ~/Desktop/tests-policy/egress-knp-old.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  egress:
Manalis-MBP:cilium manalibhutiyani$ kubectl apply -f ~/Desktop/tests-policy/egress-knp-old.yaml
networkpolicy "deny-all" created
Manalis-MBP:cilium manalibhutiyani$ 

KNP does not cause any policy change:

Manalis-MBP:cilium manalibhutiyani$ kubectl get cnp
No resources found.
Manalis-MBP:cilium manalibhutiyani$ 

However, cilium seems to be converting this egress-only no-policy to the following ingress-only policy:

root@minikube:~# cilium policy get
[
  {
    "endpointSelector": {
      "matchLabels": {
        "k8s:io.kubernetes.pod.namespace": "default"
      }
    },
    "ingress": [
      {}
    ],
    "labels": [
      {
        "key": "io.cilium.k8s.policy.name",
        "value": "deny-all",
        "source": "unspec"
      },
      {
        "key": "io.cilium.k8s.policy.namespace",
        "value": "default",
        "source": "unspec"
      }
    ]
  }
]
Revision: 93

Is this expected behavior? I think this might be back to the predated days when K8s did not support egress policies? @tgraf Feel free to close if this is expected behavior.

Should we change this to egress policy in CNP, now that we support it?

Cilium endpoint list shows all ingress only policies enabled:

root@minikube:~# cilium endpoint list
ENDPOINT   POLICY (ingress)   POLICY (egress)   IDENTITY   LABELS (source:key[=value])               IPv6                 IPv4            STATUS   
           ENFORCEMENT        ENFORCEMENT                                                                                                 
3365       Enabled            Disabled          37299      k8s:id=app3                               f00d::a0f:0:0:d25    10.15.191.0     ready   
                                                           k8s:io.kubernetes.pod.namespace=default                                                
11004      Enabled            Disabled          60284      k8s:id=app1                               f00d::a0f:0:0:2afc   10.15.54.125    ready   
                                                           k8s:io.kubernetes.pod.namespace=default                                                
29898      Disabled           Disabled          39640      reserved:health                           f00d::a0f:0:0:74ca   10.15.242.54    ready   
42910      Enabled            Disabled          55717      k8s:id=app2                               f00d::a0f:0:0:a79e   10.15.236.254   ready   
                                                           k8s:io.kubernetes.pod.namespace=default                                                
49508      Enabled            Disabled          60284      k8s:id=app1                               f00d::a0f:0:0:c164   10.15.114.197   ready   
                                                           k8s:io.kubernetes.pod.namespace=default                                                
root@minikube:~# 
arepolicy kinquestion

Most helpful comment

It looks weird but I think it's correct behaviour. Kubernetes specifies that:

  • Any rule that selects a pod will put that pod into default deny at ingress, regardless of whether the rule has an ingress section or not.
  • Any rule that has egress rule or has the policyTypes: egress field will put the relevant pods into default deny egress.

In this case I'm assuming that the egress: is omitted in the JSON because it is empty and the list has no entries. It's thus a rule with an empty spec and thus only puts ingress into default deny.

@aanm @ianvernon Agreed?

All 3 comments

It looks weird but I think it's correct behaviour. Kubernetes specifies that:

  • Any rule that selects a pod will put that pod into default deny at ingress, regardless of whether the rule has an ingress section or not.
  • Any rule that has egress rule or has the policyTypes: egress field will put the relevant pods into default deny egress.

In this case I'm assuming that the egress: is omitted in the JSON because it is empty and the list has no entries. It's thus a rule with an empty spec and thus only puts ingress into default deny.

@aanm @ianvernon Agreed?

Pasted my thoughts from the discussion on the Cilium Slack:

KNP does not cause any policy change:

When you import a Kubernetes NetworkPolicy, it does not get converted to a Kubernetes CiliumNetworkPolicy / cnp within Kubernetes. It should show up if you perform kubectl get networkpolicies, or some similar variant involving the networkpolicy object.

I do not think the example that you provided for default-deny for egress conforms to the example provided by Kubernetes here.

For ease of reference, the example is:

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

Per the documentation on the same page for policyTypes:

policyTypes: Each NetworkPolicy includes a policyTypes list which may include either Ingress, Egress, or both. The policyTypes field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no policyTypes are specified on a NetworkPolicy then by default Ingress will always be set and Egress will be set if the NetworkPolicy has any egress rules.

The last line is the important part:

If no policyTypes are specified on a NetworkPolicy then by default Ingress will always be set and Egress will be set if the NetworkPolicy has any egress rules.

Since you did not specify policyTypes, by default Ingress is set. And since there are no egress rules, Egress will not be set.

Thus, I am in agreement with @tgraf ; this is expected behavior for the policy you used.

Closing as this is correct behaviour

Was this page helpful?
0 / 5 - 0 ratings