{"id":21190,"date":"2022-12-06T02:03:04","date_gmt":"2022-12-06T02:03:04","guid":{"rendered":"https:\/\/mailinvest.blog\/index.php\/2022\/12\/06\/securing-kubernetes-cluster-traffic-with-pod-network-policies\/"},"modified":"2022-12-06T02:03:04","modified_gmt":"2022-12-06T02:03:04","slug":"securing-kubernetes-cluster-traffic-with-pod-network-policies","status":"publish","type":"post","link":"https:\/\/mailinvest.blog\/index.php\/2022\/12\/06\/securing-kubernetes-cluster-traffic-with-pod-network-policies\/","title":{"rendered":"Securing Kubernetes Cluster Traffic With Pod Network Policies"},"content":{"rendered":"

<\/a>\n<\/p>\n

\n

\"Kubernetes<\/p>\n

Kubernetes Pods can freely communicate with each other by default. This poses a security risk when your cluster\u2019s used for multiple applications or teams. Errant behavior or malicious access in one Pod could direct traffic to the other Pods in your cluster.<\/p>\n

This article will teach you how to avoid this scenario by setting up network policies<\/a>. These rules let you control Pod-to-Pod traffic flows at the IP address level (OSI layer<\/a> 3 or 4). You can precisely define the ingress and egress sources permitted for each Pod.<\/p>\n

Creating a Network Policy<\/h2>\n

Network policies are created by adding NetworkPolicy<\/code> objects to your cluster. Each policy defines the Pods it applies to and one or more ingress and egress rules. Here\u2019s a basic policy manifest:<\/p>\n

\n
\n
\n
\n
\n
\n
\n
apiVersion<\/strong>: <\/strong>networking.k8s.io\/v1\nkind<\/strong>: <\/strong>NetworkPolicy\nmetadata<\/strong>:\n  name<\/strong>: <\/strong>network-policy\n  namespace<\/strong>: <\/strong>app\nspec<\/strong>:\n  podSelector<\/strong>:\n    matchLabels<\/strong>:\n      component<\/strong>: <\/strong>database\n  policyTypes<\/strong>:\n<\/strong>    - Ingress\n    - Egress\n  ingress<\/strong>:\n    - from<\/strong>:\n      - podSelector<\/strong>:\n          matchLabels<\/strong>:\n            component<\/strong>: <\/strong>api\n  egress<\/strong>:\n    - to<\/strong>:\n        - podSelector<\/strong>:\n            matchLabels<\/strong>:\n              component<\/strong>: <\/strong>api<\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
This network policy applies to any Pod with a component: database<\/code> label in the app<\/code> namespace. It states that ingress (incoming) and egress (outgoing) traffic is only allowed from and to Pods with a component: api<\/code> label. Any requests originating from other Pods, such as component: web-frontend<\/code>, will be blocked.<\/p>\n
Network policies can be applied like any other object by using Kubectl. They\u2019ll take effect immediately after they\u2019re created. You can add the networking policy before you start the Pods it selects.<\/p>\n
$ kubectl apply -f policy.yaml
\nnetworkingpolicy.networking.k8s.io\/network-policy created<\/pre>\n
How Network Policies Work<\/h2>\n
Network policies are implemented by your cluster\u2019s active networking plugin<\/a>. Your policies won\u2019t have any effect if your plugin doesn\u2019t support the feature. Most popular options such as Calico<\/a> and Cilium<\/a> ship with network policy support enabled.<\/p>\n
When a network policy applies to a Pod, the plugin will inspect its traffic to check it\u2019s compliant with the policy\u2019s requirements. Any connections that don\u2019t meet the criteria will be disallowed. The Pod that tried to initiate the connection will find the remote host is unreachable, either because it was trying to access a resource blocked by an egress rule, or because a remote Pod denied the incoming connection using an ingress rule.<\/p>\n
A successful connection between two Pods can only be established when the network policies on both<\/em> of them permit it. The connection could be forbidden by an egress rule of the initiating Pod, or an ingress rule on the target.<\/p>\n
Network policies are always additive<\/em> in nature. When multiple policies select the same Pod, the list of permitted ingress and egress sources will be the combination of all the policies.<\/p>\n
Example Network Policies<\/h2>\n
Network policies support many different options for customizing the Pods they target and the types of connection that are allowed. The following examples showcase several common use cases.<\/p>\n
Apply a policy to every Pod in the namespace, only allowing Ingress traffic from a specific IP address block<\/h3>\n
\n
\n
\n
\n
\n
\n
\n
apiVersion<\/strong>: <\/strong>networking.k8s.io\/v1\nkind<\/strong>: <\/strong>NetworkPolicy\nmetadata<\/strong>:\n  name<\/strong>: <\/strong>network-policy\n  namespace<\/strong>: <\/strong>app\nspec<\/strong>:\n  podSelector<\/strong>: <\/strong>{<\/strong>}<\/strong>\n  policyTypes<\/strong>:\n<\/strong>    - Ingress\n  ingress<\/strong>:\n    - from<\/strong>:\n        - ipBlock<\/strong>:\n            cidr<\/strong>: <\/strong>172.17.0.0\/16<\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
The empty podSelector<\/code> block means all the namespace\u2019s Pods are targeted by the policy. The ipBlock<\/code> rule restricts ingress traffic to Pods with an IP address in the specified range. Egress traffic is not blocked.<\/p>\n
Allow Ingress traffic from an IP address block, but exclude some specific IPs<\/h3>\n
\n
\n
\n
\n
\n
\n
\n
apiVersion<\/strong>: <\/strong>networking.k8s.io\/v1\nkind<\/strong>: <\/strong>NetworkPolicy\nmetadata<\/strong>:\n  name<\/strong>: <\/strong>network-policy\n  namespace<\/strong>: <\/strong>app\nspec<\/strong>:\n  podSelector<\/strong>: <\/strong>{<\/strong>}<\/strong>\n  policyTypes<\/strong>:\n<\/strong>    - Ingress\n  ingress<\/strong>:\n    - from<\/strong>:\n        - ipBlock<\/strong>:\n            cidr<\/strong>: <\/strong>172.17.0.0\/16\n            except<\/strong>:\n<\/strong>              - 172.17.0.1\/24\n              - 172.17.0.2\/24\n              - 172.17.0.3\/24<\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
ipBlock<\/code> rules support an except<\/code> field to exclude traffic originating from, or being directed to, specific IPs.<\/p>\n
Allow Ingress traffic from all Pods in the namespace, but only from a specific port<\/h3>\n
\n
\n
\n
\n
\n
\n
\n
apiVersion<\/strong>: <\/strong>networking.k8s.io\/v1\nkind<\/strong>: <\/strong>NetworkPolicy\nmetadata<\/strong>:\n  name<\/strong>: <\/strong>network-policy\n  namespace<\/strong>: <\/strong>app\nspec<\/strong>:\n  podSelector<\/strong>: <\/strong>{<\/strong>}<\/strong>\n  policyTypes<\/strong>:\n<\/strong>    - Ingress\n  ingress<\/strong>:\n    - from<\/strong>:\n        - podSelector<\/strong>: <\/strong>{<\/strong>}<\/strong>\n          ports<\/strong>:\n            - protocol<\/strong>: <\/strong>TCP\n              port<\/strong>: <\/strong>443<\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
The ports<\/code> field is available on ingress and egress rules. It defines the ports that traffic can be received from and sent to. You can optionally specify a range of ports, such as 3000 \u2013 3500, by setting the endPort<\/code> field (3500) in addition to port<\/code> (3000).<\/p>\n
Allow traffic from Pods with a specific label that exist in a different namespace<\/h3>\n
\n
\n
\n
\n
\n
\n
\n
apiVersion<\/strong>: <\/strong>networking.k8s.io\/v1\nkind<\/strong>: <\/strong>NetworkPolicy\nmetadata<\/strong>:\n  name<\/strong>: <\/strong>network-policy\n  namespace<\/strong>: <\/strong>database\nspec<\/strong>:\n  podSelector<\/strong>: <\/strong>{<\/strong>}<\/strong>\n  policyTypes<\/strong>:\n<\/strong>    - Ingress\n  ingress<\/strong>:\n    - from<\/strong>:\n        - namespaceSelector<\/strong>:\n            matchLabels<\/strong>:\n              application<\/strong>: <\/strong>demo-app\n          podSelector<\/strong>:\n            matchLabels<\/strong>:\n              component<\/strong>: <\/strong>database<\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
The policy states that any Pod labelled component: database<\/code> can reach all the Pods in the database<\/code> namespace, if its own namespace is labelled demo-app<\/code>.<\/p>\n
You can allow traffic from all<\/em> the Pods in an external namespace by creating a rule that only includes a namespaceSelector<\/code> field.<\/p>\n
Explicitly allow all traffic<\/h3>\n
Sometimes you might want to explicitly allow all traffic of a particular type within a namespace. Include the type in your policy but supply an empty Pod selector and no rules:<\/p>\n
\n
\n
\n
\n
\n
\n
\n
apiVersion<\/strong>: <\/strong>networking.k8s.io\/v1\nkind<\/strong>: <\/strong>NetworkPolicy\nmetadata<\/strong>:\n  name<\/strong>: <\/strong>network-policy\n  namespace<\/strong>: <\/strong>app\nspec<\/strong>:\n  podSelector<\/strong>: <\/strong>{<\/strong>}<\/strong>\n  policyTypes<\/strong>:\n<\/strong>    - Ingress\n    - Egress\n  ingress<\/strong>:\n<\/strong>    - {<\/strong>}<\/strong>\n  egress<\/strong>:\n<\/strong>    - {<\/strong>}<\/strong><\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
All the Pods in the namespace can freely communicate, as if there was no policy. Creating the policy anyway lets you indicate your intentions to other cluster users. They might question the presence of a namespace with unrestricted networking in a cluster which has otherwise been secured.<\/p>\n
When to Use Network Policies<\/h2>\n
Network policies should be created for each of the namespaces and Pods in your cluster. This better isolates your Pods and puts you in control of traffic flow.<\/p>\n
Try to make your policies as granular as possible. Widening access too much, such as allowing access between all Pods in a namespace, leaves you exposed to risks if one of your containers is compromised. Consider using precise selectors to identify individual ingress and egress remotes for sensitive Pods such as authentication services, databases, and payment handlers.<\/p>\n
Kubernetes doesn\u2019t enable any network policies by default which can allow oversights to occur, even if you intend all Pods to be protected by a policy. You can mitigate against this risk by adding a catch-all policy to your namespaces. This policy selects every Pod in the namespace and applies a rule that forbids all network communication:<\/p>\n
\n
\n
\n
\n
\n
\n
\n
apiVersion<\/strong>: <\/strong>networking.k8s.io\/v1\nkind<\/strong>: <\/strong>NetworkPolicy\nmetadata<\/strong>:\n  name<\/strong>: <\/strong>deny-all<\/strong>\n  namespace<\/strong>: <\/strong>app\nspec<\/strong>:\n  podSelector<\/strong>: <\/strong>{<\/strong>}<\/strong>\n  policyTypes<\/strong>:\n<\/strong>    - Ingress\n    - Egress<\/pre>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n
Network policies are always scoped to namespaces so you\u2019ll need to create a separate catch-all for each one.<\/p>\n
Summary<\/h2>\n
Kubernetes allows all the Pods in your cluster to communicate with each other. This is too permissive for real-world applications running in multi-purpose clusters. Network policies address this problem by providing a firewall-like system for managing the ingress sources and egress targets that each Pod accepts.<\/p>\n
It\u2019s good practice to configure a network policy on all of your Pods. This will secure your cluster so only legitimate traffic flows are permitted. Network policies are only one part of Kubernetes security, however: other protection mechanisms<\/a> such as RBAC<\/a> and Pod security contexts<\/a> are also essential tools for hardening your environment.<\/p>\n<\/div>\n