Kubernetes Network Policy
What is Kubernetes Network Policy?
Kubernetes Network Policy determines how cloud cluster resources such as pods are segmented. The policy defines access permissions for pods and dictates which pods can communicate with each other, thus creating the necessary segments.
Generally, a network policy is applied to both ends of the pod – incoming and outgoing. The Kubernetes Network Policy ensures the cluster’s security, enables traffic control, and restricts access inside the cluster.
How Does It Work?
An application cluster’s default setting allows communication between all pods, which means no pods are isolated. To create segmentation, Kubernetes Network Policy enables developers to create rules for all pods based on which exclusive inter-pod communication occurs. The rules are known as policies, and overall the Kubernetes Network Policies can create and implement rules on the following levels:
- Namespace: Network policies can be developed on the namespace level, wherein the kind of incoming and outgoing traffic, requests, and instructions can be defined.
- Pods: Typically policies are implemented on the pod level, determining which pods are allowed/disallowed to communicate with each other.
- Specific Traffic: The rules monitor how the pods and the cluster will handle specific types of traffic. The rules for this level are also known as the allow-list based rules.
- Flow-Based: These rules are specific to incoming and outgoing packets of requests. In these rules, if the initiating packets are accepted, the return packets must also be accepted.
These are the major scopes of the Kubernetes Network Policy. All these policies isolate the pods into different segments. Generally, the network policies can be of two types of isolations:
- Ingress: All policies that determine inbound requests and communications are called ingress policies. In simple terms, rules for incoming communications are ingress.
- Egress: All policies that determine outbound requests and communications are called egress policies. In simple terms, rules for outgoing communications are egress.
Both ingress and egress policies are additive and not contradictory. If ingress/egress policies allow communication to/from a pod, then the resultant connection will be the union of all such policies from the pod.
Components of a Network Policy
- spec: A network policy spec comprises information about the desired state of any object. It involves all data required for creating a policy/rule for pods.
- podSelector: This component selects all the pods to which the network policy will apply. If the component is empty, all pods within a namespace are selected by Kubernetes, and the policy becomes applicable to everyone.
- policyType: This component refers to whether the policy will be ingress or egress in nature.
How to create Ingress and Egress Policies
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
– Ingress
– Egress
ingress:
– from:
– ipBlock:
cidr: 172.17.0.0/16
except:
– 172.17.1.0/24
– namespaceSelector:
matchLabels:
project: myproject
– podSelector:
matchLabels:
role: frontend
ports:
– protocol: TCP
port: 6379
egress:
– to:
– ipBlock:
cidr: 10.0.0.0/24
ports:
– protocol: TCP
port: 5978
In the above example,
- All pods with the label role: db are selected using the podSelector component for ingress and egress policies.
- For ingress, pods with label role: db will allow traffic from:
- Pods with label project: myproject and role: frontend.
- IP Addresses between 172.17.0.0 and 172.17.0.255, and 172.17.2.0 and 172.17.255.255, except 172.17.1.0/24
- This will occur on TCP port 6379
- For egress, pods with label role: db can send traffic to:
- CIDR 10.0.0.0/24
- This will occur on TCP port 6379.
Default Ingress and Egress Policies
Deny All Ingress Traffic
The policy selects all pods in a Namespace and disallows their ingress traffic. This way, the Network Policy will isolate all pods in the namespace for incoming communication. The command for this is default-deny-ingress.
Allow All Ingress Traffic
Ingress traffic is allowed for all pods within a namespace. The command for the same is allow-all-ingress. This default policy will not let any other policies to deny ingress traffic.
Deny All Egress Traffic
Like ingress traffic, all egress traffic is denied with the command default-deny-egress. No other egress policy can overrule this default policy.
Allow All Egress Traffic
All egress traffic will be allowed with the command allow-all-egress. Additional egress policy cannot deny traffic to pods within the namespace.
Deny All Egress and Ingress Traffic
With the default-deny-all command, all egress and ingress traffic will be disallowed, and the pods within the namespace will be completely isolated.
Benefits of Kubernetes Network Policy
There are three primary benefits of the Kubernetes Network Policy:
- Securing Clusters: The isolation of different pods improves the security of the application cluster. In case of a malicious attack, only an isolated section of pods will be affected, and thus the damage can be contained.
- Segmentation of the Network: The cluster network can be separated into compartments where only the pods required for specific requests and communications are bound together via the network policies. Other pods which do not participate in those operations needn’t interact with the corresponding pods.
- Optimized Governance: Monitoring and managing clusters become simple and time-efficient. This is due to network segmentation, which enables administrators to identify, troubleshoot, and solve problems easily.
Actionable, contextual, end-to-end
{Kubernetes-native security}
From code to cluster, helm to node, we’ve got your Kubernetes covered:
Cut the CVE noise by significantly reducing CVE-related work by over 90%
Automatic Kubernetes compliance for CIS, NSA, Mitre, SOC2, PCI, and more
Manage Kubernetes role-based-access control (RBAC) visually
Share
