Skip to content

Latest commit

 

History

History
146 lines (98 loc) · 6.82 KB

File metadata and controls

146 lines (98 loc) · 6.82 KB

kubernetes NetworkPolicies

Support HackTricks and get benefits!

This tutorial was taken from https://madhuakula.com/kubernetes-goat/scenarios/scenario-20.html

Scenario Information

This scenario is deploy a simple network security policy for Kubernetes resources to create security boundaries.

  • To get started with this scenario ensure you must be using a networking solution which supports NetworkPolicy

Scenario Solution

If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster. NetworkPolicies are an application-centric construct which allow you to specify how a pod is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network.

The entities that a Pod can communicate with are identified through a combination of the following 3 identifiers

  1. Other pods that are allowed (exception: a pod cannot block access to itself) Namespaces that are allowed
  2. IP blocks (exception: traffic to and from the node where a Pod is running is always allowed, regardless of the IP address of the Pod or the node)
  3. When defining a pod- or namespace- based NetworkPolicy, you use a selector to specify what traffic is allowed to and from the Pod(s) that match the selector.

Meanwhile, when IP based NetworkPolicies are created, we define policies based on IP blocks (CIDR ranges).

  • We will be creating DENY all traffic to an application

This NetworkPolicy will drop all traffic to pods of an application, selected using Pod Selectors.

Use Cases:

  • It’s very common: To start whitelisting the traffic using Network Policies, first you need to blacklist the traffic using this policy.
  • You want to run a Pod and want to prevent any other Pods communicating with it.
  • You temporarily want to isolate traffic to a Service from other Pods.

Scenario 20 NSP

Example

  • Run a nginx Pod with labels app=web and expose it at port 80
kubectl run --image=nginx web --labels app=web --expose --port 80
  • Run a temporary Pod and make a request to web Service
kubectl run --rm -i -t --image=alpine test-$RANDOM -- sh
wget -qO- http://web
# You will see the below output
#    <!DOCTYPE html>
#    <html>
#    <head>
#    ...
  • It works, now save the following manifest to web-deny-all.yaml, then apply to the cluster
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-deny-all
spec:
  podSelector:
    matchLabels:
      app: web
  ingress: []
kubectl apply -f web-deny-all.yaml

Try it out

  • Run a test container again, and try to query web
kubectl run --rm -i -t --image=alpine test-$RANDOM -- sh
wget -qO- --timeout=2 http://web
# You will see the below output
#   wget: download timed out
  • Traffic dropped
  • In the manifest above, we target Pods with app=web label to policy the network. This manifest file is missing the spec.ingress field. Therefore it is not allowing any traffic into the Pod.
  • If you create another NetworkPolicy that gives some Pods access to this application directly or indirectly, this NetworkPolicy will be obsolete.
  • If there is at least one NetworkPolicy with a rule allowing the traffic, it means the traffic will be routed to the pod regardless of the policies blocking the traffic.

Cleanup

kubectl delete pod web
kubectl delete service web
kubectl delete networkpolicy web-deny-all

Cilium Editor - Network Policy Editor

A tool/framework to teach you how to create a network policy using the Editor. It explains basic network policy concepts and guides you through the steps needed to achieve the desired least-privilege security and zero-trust concepts.

Scenario 20 NSP Cilium

Miscellaneous

Support HackTricks and get benefits!