NetworkPolicy with matchExpressions is not applied to matching pods

[minrk]

What happened:

NetworkPolicy with matchExpressions is not applied to matching pods

What you expected to happen:

NetworkPolicy with matchExpressions is applied to matching pods

How to reproduce it (as minimally and precisely as possible):

1. create a network policy with:

    matchExpressions:
      - key: component
        operator: In
        values:
          - first-value
          - second-value

2. create a pod with:

labels:
  component: first-value

3. verify whether network policy is applied. It will not be.

I used this policy to deny-all egress:

spec:
  egress: []
  podSelector:
    matchExpressions:
    - key: component
      operator: In
      values:
      - first-value
      - second-value
  policyTypes:
  - Egress

and tested with curl https://example.com. It should be blocked. If the policy is applied, it is blocked. If the policy is not applied, it is not blocked. Interestingly, if matchExpressions values list has only one item, it is applied correctly. But if there are two or more items, matching pods are not considered to be matching pods, and no restrictions are applied. matchLabels and other selectors are applying as expected.

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version): v1.16.10
• Size of cluster (how many worker nodes are in the cluster?): 6
• General description of workloads in the cluster (e.g. HTTP microservices, Java app, Ruby on Rails, machine learning, etc.) web app: running https://mybinder.org via https://github.com/juptyerhub/mybinder.org-deploy, but I think any cluster running azure-npm will have this issue
• Others: azure-npm image: mcr.microsoft.com/containernetworking/azure-npm:v1.1.8

original discovery of the issue: jupyterhub/mybinder.org-deploy#1468

[ghost]

Hi minrk, AKS bot here 👋
Thank you for posting on the AKS Repo, I'll do my best to get a kind human from the AKS team to assist you.

I might be just a bot, but I'm told my suggestions are normally quite good, as such:

1. If this case is urgent, please open a Support Request so that our 24/7 support team may help you faster.
2. Please abide by the AKS repo Guidelines and Code of Conduct.
3. If you're having an issue, could it be described on the AKS Troubleshooting guides or AKS Diagnostics?
4. Make sure your subscribed to the AKS Release Notes to keep up to date with all that's new on AKS.
5. Make sure there isn't a duplicate of this issue already reported. If there is, feel free to close this one and '+1' the existing issue.
6. If you have a question, do take a look at our AKS FAQ. We place the most common ones there!

[ghost]

Triage required from @Azure/aks-pm

[ghost]

Action required from @Azure/aks-pm

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[miwithro]

@minrk have you upgraded your cluster? If not, can you upgrade to the the latest and try the config again?

[ghost]

Triage required from @Azure/aks-pm

[minrk]

@miwithro we had to teardown our cluster and start again with calico, which has the right behavior. We no longer have a cluster with azure-npm to test with.

[paulgmiller]

@mirnk @miwithro clsing this in favor of #851 above.