netw_policies

Home

Kubernetes Network Policy Examples

This guide demonstrates how Kubernetes Network Policies and Calico Network Policies can be used to control traffic flow to and from Pods. We will set up a demo application, implement a default deny policy, and then incrementally allow specific traffic.

(Assumption: The examples use a custom Docker image named xxradar/hackon for testing with curl. If this image is not available, you can substitute it with a standard image like alpine/curl or curlimages/curl.)

1. Setup and Initial Access Tests

1.1 Cleanup Previous Environment (Optional)

If you have run this lab before, clean up old resources.

kubectl delete ns hacker --ignore-not-found=true
kubectl delete ns friend --ignore-not-found=true
kubectl delete ns wwwnginx --ignore-not-found=true
# The 'demo' directory operations are for local file management
rm -rf demo
mkdir demo
cd demo

(Added --ignore-not-found=true to delete commands.)

1.2 Deploy a Demo Application

We'll create a simple Nginx deployment and service in the wwwnginx namespace.

kubectl create ns wwwnginx
kubectl apply -n wwwnginx -f https://raw.githubusercontent.com/xxradar/kuberneteslearning/master/nginx-deployment.yaml
kubectl apply -n wwwnginx -f https://raw.githubusercontent.com/xxradar/kuberneteslearning/master/nginx-expose-clusterip.yaml

Verify the deployment:

kubectl get po -n wwwnginx -o wide
kubectl get svc -n wwwnginx -o wide

1.3 Test Initial Access

Before applying any network policies, all pods should be able to communicate.

1. Test access from within the wwwnginx namespace:

   # Launch a temporary 'curler' pod in 'wwwnginx' namespace
   kubectl run curler-www -it -n wwwnginx --rm --image=xxradar/hackon -- bash

   Inside the curler-www pod's shell:

   # (curler-www) # Test service by its name (DNS within namespace)
   curl http://my-nginx-clusterip
   
   # (curler-www) # Check DNS resolution
   cat /etc/resolv.conf
   
   # (curler-www) # Test service by its FQDN
   curl http://my-nginx-clusterip.wwwnginx.svc.cluster.local
   
   # (curler-www) # Exit the pod
   exit

2. Test access from other namespaces: Create two additional namespaces, hacker and friend.

   kubectl create ns hacker
   kubectl create ns friend

   Test from hacker namespace:

   kubectl run curler-hacker -it -n hacker --rm --image=xxradar/hackon -- bash

   Inside curler-hacker pod's shell:

   # (curler-hacker) # Access service in wwwnginx namespace by FQDN
   curl http://my-nginx-clusterip.wwwnginx.svc.cluster.local
   exit

   Test from friend namespace:

   kubectl run curler-friend -it -n friend --rm --image=xxradar/hackon -- bash

   Inside curler-friend pod's shell:

   # (curler-friend) # Access service in wwwnginx namespace by FQDN
   curl http://my-nginx-clusterip.wwwnginx.svc.cluster.local
   exit

   (At this point, all curl commands should succeed as there are no network policies in place.)

2. Implementing a Default Deny Policy

Now, let's apply a policy in the wwwnginx namespace that denies all ingress traffic by default.

1. Create default-deny-ingress.yaml:

   cat > default-deny-ingress.yaml <<EOF
   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: default-deny-ingress
     namespace: wwwnginx # Apply this policy in the 'wwwnginx' namespace
   spec:
     podSelector: {} # An empty podSelector selects all pods in the namespace
     policyTypes:
     - Ingress # Apply this policy to Ingress traffic
   EOF

2. Apply the policy and inspect it:

   kubectl apply -f default-deny-ingress.yaml
   # Note: namespace is in the YAML, so -n wwwnginx is not strictly needed on apply
   # but good for explicitness if the YAML didn't specify it.
   kubectl get netpol -n wwwnginx
   kubectl describe netpol default-deny-ingress -n wwwnginx

3. Retest Access: All access attempts to my-nginx-clusterip from any namespace (including wwwnginx itself) should now fail (timeout).

   # From wwwnginx namespace
   kubectl run curler-www-denytest -it -n wwwnginx --rm --image=xxradar/hackon -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local || echo 'Failed as expected'"
   # From hacker namespace
   kubectl run curler-hacker-denytest -it -n hacker --rm --image=xxradar/hackon -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local || echo 'Failed as expected'"
   # From friend namespace
   kubectl run curler-friend-denytest -it -n friend --rm --image=xxradar/hackon -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local || echo 'Failed as expected'"

   (Added -m 5 for timeout and informative echo.)

3. Allowing Traffic with Kubernetes NetworkPolicy

We will now create policies to allow specific ingress traffic to our Nginx pods (which have the label app: nginx). The curler pods we run for testing will be assumed to have the label run: curler (kubectl run adds this label by default).

3.1 Allow Ingress on Port 80 from Pods with Label run: curler (within same namespace)

1. Create allow-nginx-ingress-podselector.yaml: This policy applies to pods with app: nginx in wwwnginx namespace. It allows ingress on TCP port 80 from any pod in the wwwnginx namespace that has the label run: curler.

   cat > allow-nginx-ingress-podselector.yaml <<EOF
   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-nginx-ingress-podselector
     namespace: wwwnginx
   spec:
     podSelector:
       matchLabels:
         app: nginx # Apply to our Nginx pods
     policyTypes:
     - Ingress
     ingress:
     - from:
       - podSelector: # Allow traffic from pods within 'wwwnginx' namespace
           matchLabels:
             run: curler # That have this label
       ports:
       - protocol: TCP
         port: 80
   EOF

2. Apply the policy:

   kubectl apply -f allow-nginx-ingress-podselector.yaml

3. Retest Access:

   • Access from curler pod in wwwnginx namespace should now succeed.

   • Access from curler pods in hacker and friend namespaces should still fail.

   # From wwwnginx namespace (should succeed)
   kubectl run curler-www-allowtest1 -it -n wwwnginx --rm --image=xxradar/hackon -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local && echo 'Succeeded as expected' || echo 'Failed unexpectedly'"
   # From hacker namespace (should fail)
   kubectl run curler-hacker-allowtest1 -it -n hacker --rm --image=xxradar/hackon -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local && echo 'Succeeded unexpectedly' || echo 'Failed as expected'"
   # From friend namespace (should fail)
   kubectl run curler-friend-allowtest1 -it -n friend --rm --image=xxradar/hackon -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local && echo 'Succeeded unexpectedly' || echo 'Failed as expected'"

3.2 Allow Ingress also from friend Namespace

Let's modify the policy to also allow access from pods labeled run: curler in any namespace labeled project: friend.

1. Label the friend and hacker namespaces:

   kubectl label ns friend project=friend --overwrite
   kubectl label ns hacker project=hacker --overwrite

   (Added --overwrite)

2. Create allow-nginx-ingress-namespaceselector.yaml: This policy builds upon the previous one.

   cat > allow-nginx-ingress-namespaceselector.yaml <<EOF
   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-nginx-ingress # Can be the same name to update, or a new one
     namespace: wwwnginx
   spec:
     podSelector:
       matchLabels:
         app: nginx
     policyTypes:
     - Ingress
     ingress:
     - from:
       - podSelector: # Allows from 'run:curler' pods in 'wwwnginx' (local namespace)
           matchLabels:
             run: curler
       - namespaceSelector: # Allows from any pod in namespaces labeled 'project:friend'
           matchLabels:
             project: friend
         # To be more specific, you can combine namespaceSelector with podSelector:
         # podSelector:
         #   matchLabels:
         #     run: curler
       ports:
       - protocol: TCP
         port: 80
   EOF

   (Modified the policy to show a common way to allow from other namespaces. The original had a combined rule which might be confusing. This one has two from entries - one for local pods, one for pods in 'friend' namespaces. If the intent was that pods in 'friend' namespace must also have run:curler, then the podSelector needs to be nested under the namespaceSelector entry.)

   Self-correction: The original policy had the second podSelector at the same level as namespaceSelector, which is not how it's combined. An ingress rule is a list of NetworkPolicyIngressRule, each from is a list of NetworkPolicyPeer. A peer can have podSelector OR namespaceSelector OR ipBlock. If both namespaceSelector and podSelector are specified within the same NetworkPolicyPeer entry, they are ANDed. Let me refine the policy to correctly reflect allowing from run:curler pods in wwwnginx AND from any pod in project:friend namespaces, then a more specific version.

   Refined allow-nginx-ingress-friend-ns.yaml (allowing any pod from 'friend' namespace AND specific pods from local namespace):

   cat > allow-nginx-ingress-friend-ns.yaml <<EOF
   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-nginx-ingress-friend-ns
     namespace: wwwnginx
   spec:
     podSelector:
       matchLabels:
         app: nginx
     policyTypes:
     - Ingress
     ingress:
     - from:
       - podSelector: # Rule 1: Allow from 'run:curler' pods in 'wwwnginx'
           matchLabels:
             run: curler
       - namespaceSelector: # Rule 2: Allow from ANY pod in namespaces labeled 'project:friend'
           matchLabels:
             project: friend
       ports: # This ports section applies to all 'from' rules in this ingress entry
       - protocol: TCP
         port: 80
   EOF

3. Apply the updated policy:

   kubectl apply -f allow-nginx-ingress-friend-ns.yaml

4. Retest Access:

   • wwwnginx (with run: curler label): Should succeed.

   • hacker (no specific allow rule for this namespace label): Should fail.

   • friend (any pod, due to namespaceSelector): Should succeed.

   kubectl run curler-www-allowtest2 -it -n wwwnginx --rm --image=xxradar/hackon --labels="run=curler" -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local && echo 'Succeeded as expected' || echo 'Failed unexpectedly'"
   kubectl run curler-hacker-allowtest2 -it -n hacker --rm --image=xxradar/hackon --labels="run=curler" -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local && echo 'Succeeded unexpectedly' || echo 'Failed as expected'"
   kubectl run curler-friend-allowtest2 -it -n friend --rm --image=xxradar/hackon --labels="run=curler" -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local && echo 'Succeeded as expected' || echo 'Failed unexpectedly'"

   (Added labels to test pods for clarity, especially if the policy were to combine namespace and pod selectors.)

3.3 Allow Ingress from All Namespaces (but only specific pods)

Let's create a policy that allows access from pods labeled run: curler irrespective of their namespace.(The original document's "allow from all namespaces" policy still had a specific podSelector: { matchLabels: { run: curler } } combined with namespaceSelector: { matchLabels: {} }. This means it allows pods labeled run: curler from any namespace that itself has any label. A true "allow all pods from all namespaces" would be just from: {} or from: - namespaceSelector: {} without a podSelector in that rule.)

Let's interpret the original intent as "allow run:curler pods from any namespace".

1. Create allow-nginx-ingress-all-ns-curler-pods.yaml:

   cat > allow-nginx-ingress-all-ns-curler-pods.yaml <<EOF
   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-curler-pods-all-ns
     namespace: wwwnginx
   spec:
     podSelector:
       matchLabels:
         app: nginx
     policyTypes:
     - Ingress
     ingress:
     - from:
       - namespaceSelector: {} # Selects all namespaces
         podSelector:         # And within those namespaces, selects pods with this label
           matchLabels:
             run: curler
       ports:
       - protocol: TCP
         port: 80
   EOF

2. Apply the policy:

   kubectl apply -f allow-nginx-ingress-all-ns-curler-pods.yaml

3. Retest Access: Now, curler pods from wwwnginx, hacker, and friend namespaces should all succeed.

   kubectl run curler-www-allowtest3 -it -n wwwnginx --rm --image=xxradar/hackon --labels="run=curler" -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local && echo 'Succeeded as expected' || echo 'Failed unexpectedly'"
   kubectl run curler-hacker-allowtest3 -it -n hacker --rm --image=xxradar/hackon --labels="run=curler" -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local && echo 'Succeeded as expected' || echo 'Failed unexpectedly'"
   kubectl run curler-friend-allowtest3 -it -n friend --rm --image=xxradar/hackon --labels="run=curler" -- bash -c "curl -m 5 http://my-nginx-clusterip.wwwnginx.svc.cluster.local && echo 'Succeeded as expected' || echo 'Failed unexpectedly'"

4. Calico Network Policies (Advanced)

Calico offers its own CRDs for network policies (NetworkPolicy, GlobalNetworkPolicy) which provide more features than Kubernetes' built-in NetworkPolicy.

Note: To use Calico policies, Calico must be installed as the CNI plugin in your cluster.

4.1 Example: Calico Policy to Deny hacker Namespace

This policy denies traffic from pods in any namespace labeled project: hacker to Nginx pods in wwwnginx on TCP port 80, and it has an order of 510.

1. Create calico-deny-hacker.yaml: (Original filename was calico-allow-port80.yaml but the rule is a Deny)

   cat > calico-deny-hacker.yaml <<EOF
   apiVersion: projectcalico.org/v3
   kind: NetworkPolicy # Could also be GlobalNetworkPolicy for cluster-wide effect
   metadata:
     name: deny.hacker.to.wwwnginx # Changed name for clarity
     namespace: wwwnginx # This policy is specific to wwwnginx namespace
   spec:
     order: 500 # Calico policies have an order of evaluation
     selector: app == "nginx" # Applies to pods with label app=nginx
     ingress:
       - action: Deny
         protocol: TCP
         source:
           namespaceSelector: project == "hacker" # From namespaces labeled project=hacker
         destination:
           ports:
             - 80 # To port 80
     types:
       - Ingress
   EOF

   (Corrected filename and metadata.name for clarity based on the rule's action. Adjusted order slightly.)

2. Apply using calicoctl: You might need to install calicoctl.

   # Ensure calicoctl is configured to talk to your datastore (Kubernetes API or etcd)
   calicoctl apply -f calico-deny-hacker.yaml
   # Note: -n wwwnginx is not needed if namespace is in metadata for calicoctl apply

   Verify:

   calicoctl get networkpolicy -n wwwnginx deny.hacker.to.wwwnginx -o yaml
   calicoctl get networkpolicies -n wwwnginx -o wide # List all Calico policies in namespace

3. Test Access (Conceptual): At this point, if you have a Kubernetes NetworkPolicy that allows traffic from project=hacker (like the "Allow Ingress from All Namespaces (but only specific pods)" one), and this Calico policy which denies it, the Deny action in Calico (especially with a lower order number, making it process earlier) would typically take precedence for traffic matching its source. Testing this combined behavior would require careful setup of both K8s and Calico policies.

4.2 Example: Calico Global Quarantine Rule

This GlobalNetworkPolicy aims to quarantine pods labeled quarantine == "true" by denying all their ingress and egress traffic, and logging attempts.

1. Create calico-quarantine-gnp.yaml:

   cat > calico-quarantine-gnp.yaml <<EOF
   apiVersion: projectcalico.org/v3
   kind: GlobalNetworkPolicy
   metadata:
     name: quarantine-pods-by-label
   spec:
     order: 100 # Process this policy relatively early
     selector: quarantine == "true" # Applies to any pod with this label, in any namespace
     # namespaceSelector: '' # Empty means all namespaces (default for GlobalNetworkPolicy selector)
     # serviceAccountSelector: '' # Empty means all service accounts
     ingress:
       - action: Log
       - action: Deny
     egress:
       - action: Log
       - action: Deny
     # Removed source/destination from Log/Deny for a blanket block.
     # Original had empty source/dest which implies allow all if not for Deny.
     # doNotTrack, applyOnForward, preDNAT are advanced fields, kept as in original.
     doNotTrack: false
     applyOnForward: false
     preDNAT: false
     types:
       - Ingress
       - Egress
   EOF

   (Simplified Log/Deny rules for clarity of a blanket deny after log. Adjusted name.)

2. Apply the Global Network Policy:

   calicoctl apply -f calico-quarantine-gnp.yaml

   Now, any pod in any namespace that you label with quarantine=true (e.g., kubectl label pod mypod -n myns quarantine=true) should be isolated.

Home