¶ Ingress/Egress
Traffic coming into something is called Ingress. Traffic leaving someting (Server, service, pod...) is called Egress.
The picture below shows how traffic would normally flow for a 3-tier application in k8s.
- Traffic would ingress to the web server on port 80 from the outside
- Traffic would then leave the web service to hit the API service on port 5000.
- Traffic would then leave the API service to hit the database service on port 3306.
¶ Example Application Flow
Note: For traffic between pods, you should have an ingress rule (coming into the service) as well as an egress rule fo the traffic leaving the pod/pods that are calling the service.
¶ Example Ingress/Egress Rules
¶ Network Security
¶ Pod Network Example
All pods within a namespace should have their own internal vlan to allow them to communicate with one another without needing to configure anything like routes, even across the various nodes within a cluster..
- In the example above, all the pods are able to communicate with one another across all the nodes in the cluster and reachable via pod name, ip address or service name/ip address.
- By Default, kubernetes is configured with a network "allow all" policy, which means that any pod can talk to another other pod on the cluster.
- The problem with this is that, in a 3 tier application, there is nothing stopping the front end pod (nginx) from talking to the database pod, even though, only the api (python) pod needs to talk to the database pod.
- In order to prevent that, we use a network policy on the database pod that only allows ingress ttraffic on port 3306 from the api (python) pod. This will block incoming traffic from all other pods.
¶ Ingres Network Policy
¶ Example ingress network policy
This will allow traffic on port 3306 into
apiVersion: networking.k8s.io/vi
kind: NetworkPolicy
metadata:
name: db-policy
spec:
podSelector: # Apply this policy to all pods
matchLabels:
role: db # that have the role label set to db
policyTypes:
- Ingress # allow incoming traffic
ingress:
- from: # from any pod
- podSelector:
matchLabels:
name: api-pod # that has a name label = api-pod
ports:
- protocol: TCP
port: 3306 # on port 3306.
¶ Ingress and Egress Network Policy
¶ Example
¶ Yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: internal-policy
namespace: default
spec:
podSelector:
matchLabels:
name: internal
policyTypes:
- Egress
- Ingress
ingress:
- {}
egress:
- to:
- podSelector:
matchLabels:
name: mysql
ports:
- protocol: TCP
port: 3306
- to:
- podSelector:
matchLabels:
name: payroll
ports:
- protocol: TCP
port: 8080
- ports:
- port: 53
protocol: UDP
- port: 53
protocol: TCP
¶ fqdn-netpol.yml:
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: default.allow-egress-to-photos
namespace: myclientnamespace
spec:
order: 1005 # must be set (lower values take precedence)
selector: app == 'frontend' # apply policy on pod(s) with matching label
types:
- Egress
egress:
- action: Allow
protocol: TCP
destination:
domains:
- photos.aaronhatcher.com # allow egress to specific FQDN
ports: # must define ports on destination
- 443 # allow egress to port 443
¶ ip-netpol.yaml
```yaml
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: default.allow-egress-to-photos
namespace: myclientnamespace
spec:
order: 1005 # must be set (lower values take precedence)
selector: app == 'frontend' # apply policy on pod(s) with matching label
types:
- Egress
egress:
- action: Allow
protocol: TCP
destination:
nets:
- 123.43.232.13/32 # allow egress to specific FQDN
- 123.43.232.14/32
ports: # must define ports on destination
- 443 # allow egress to port 443
¶ Rules controlling network access to Pods.
-
Similar to firewalls or security groups that control access to virtual machines running in a cloud.
-
Scoped to Namespaces.
- The container network plugin running in your cluster must support network policies to get any of their benefits. Otherwise, you will create network policies and there won't be anything to enforce them. In the worse case, you might think that you have secured access to an application but the pods are actually still open to request from anywhere. There won't be any error messages when you create the policy. It will be created successfully but we'll simply have no effect. The cluster administrator can tell you if the network plugin in your cluster supports network policy or not.
- Some examples of network plugins that support network policy are:
- Calico and
- Romana.
-
Sample network Policy:
-
If the podSelector: section is left empty, the policy is applied to all pods in the namespace
-
under the ingress/egress:
-
if the from list, if left empty, all hosts will be allowed.
-
it support namespaces, podSelector (labels within a pod) and ipBlock
-
if the ports list is left empty, all ports
-
if both from and ports are left, empty, all traffic will be allowed
¶ To view a policy:
kubectl describe -n <namespace> networkpolicies <policy name>
¶ Project Calico network policies
kubectl get networkpolicy.projectcalico.org
¶ Sample to block all outgoing traffic to a single ip address
- Network policies are added together. If any policy allows traffic, regardless if there is a deny policy, traffic will be allowed.
- Network policies are not applied to existing connections, only to new connections.
- Applying a policy will not be applied to any existing connections.
¶ Services
Network policies are configured on the pods, not the services. So, while a pod maybe configured to call a service:<service port>, you still need to create the network, policy for the actual port the Pod sitting behind the service is using. This can make configuring