Kubernetes Firewall: A Practical Guide to Securing K8s Networks

What Is a Kubernetes Firewall?

Kubernetes is a popular container management platform that supports containerized applications distributed across public, private, and hybrid clouds.

While Kubernetes doesn’t offer built-in solutions for securing ingress/egress traffic between internal clusters and external networks, there are specialized firewalls that can restrict traffic and prevent data leaks.

A Kubernetes firewall tracks and filters all inbound and outbound communication with production clusters. It should allow the necessary traffic, keeping specified default and custom ports open while blocking other data transfers to and from each Kubernetes cluster. Kubernetes firewalls protect clusters from the outside.

This is part of our series of articles about Kubernetes security.

In this article:

• Why Is a Kubernetes Firewall Needed?
• Kubernetes Network Policies vs. Firewalls: What Is the Difference?
• What Ports and Protocols Should Be Allowed by a Kubernetes Firewall?
• Kubernetes Firewalls and Network Security Best Practices
  • Protect Ingress, Egress, and East-West Traffic
  • Secure the Kubernetes Datastore and API Server
  • Restrict Cloud Metadata API Access
• Kubernetes Security and Observability with Calico

Why Is a Kubernetes Firewall Needed?

When a Kubernetes cluster is running in production, all communication must be secured to prevent data exfiltration and other threats. Both ingress and egress network traffic must be monitored and controlled according to a set of security rules defined by the organization.

In particular, egress traffic should be limited to an absolute minimum of accessible ports and addresses to enable cluster maintenance operations and access by external integrated systems.

This is where a firewall comes in—it can restrict inbound and outbound traffic to and from a Kubernetes cluster. Here are some of the benefits a firewall can provide in a Kubernetes environment:

• Preventing data leaks and malware – Firewalls can inspect traffic, including TLS/SSL encrypted traffic, to identify outbound packets with sensitive data or inbound packets with malicious payloads.
• IP and URL filtering – Blocks inbound and outbound connections to potentially malicious websites, such as malware repositories.
• Establishing strong trust boundaries – In many Kubernetes environments, Kubernetes namespaces are trust boundaries. The firewall enforces threat defense policies not only between Kubernetes namespaces, but also between Kubernetes namespaces and other types of workloads such as virtual machines and bare metal servers. This prevents the transfer of threats between cloud-native and legacy environments.
• Blocking open ports – Many attacks use arbitrary ports to circumvent port-based network security controls. A firewall can restrict traffic to a list of allowed ports, and inspects network traffic to ensure that only authorized applications can access those ports.

Kubernetes Network Policies vs. Firewalls: What Is the Difference?

In a Kubernetes cluster, by default any pod can communicate with any other pod. This is detrimental to security, because it means that attackers who compromise one container can move laterally across the entire cluster without any restrictions. The Kubernetes NetworkPolicy resource allows you to limit traffic to and from pods.

Kubernetes networking capabilities, including NetworkPolicy, are powered by networking plugins. To use NetworkPolicy, you must have a plugin that implements it. Calico is one example of a popular open source networking plugin available for Kubernetes, which offers advanced monitoring, application-layer filtering, integration with cloud networks, and network policy enforcement.

While it is very important to implement NetworkPolicy in a Kubernetes cluster, it is not a replacement for firewalls. A NetworkPolicy controls traffic within the cluster (known as east-west traffic) while a firewall restricts ingress and egress traffic to or from the cluster (known as north-west traffic).

Related content: Read our guide to Kubernetes security policy

What Ports and Protocols Should Be Allowed by a Kubernetes Firewall?

When deploying a Kubernetes firewall, you should be aware of the ports and protocols used by the Kubernetes control plane. These must be allowed to enable the cluster to function.

The following TCP ports are used by Kubernetes control plane components:

• Port 6443 – Kubernetes API server
• Ports 2379-2380 – etcd server client API
• Port 10250 – Kubelet API
• Port 10259 – kube-scheduler
• Port 10257 – kube-controller manager

The following TCP ports are used by Kubernetes nodes:

• Port 10250 – Kubelet API
• Ports 30000-32767 – NodePort Services

The above are the default ports defined by Kubernetes—if you set custom ports for any of them, the firewall should be enabled for the custom port.

Kubernetes Firewalls and Network Security Best Practices

Protect Ingress, Egress, and East-West Traffic

It is important to protect both ingress and egress traffic in a Kubernetes cluster. The cluster must be protected from malicious inbound traffic, but must also be prevented from sending malicious outbound traffic to elements outside the cluster. Here are cybersecurity best practices to ensure that your cluster integrates securely with the surrounding environment:

• Restrict Internet access to the cluster – A cluster might require public Internet access either directly (via the nodes’ public IP addresses) or indirectly (via a load balancer). It is not recommended to allow access to the cluster from the Internet unless absolutely necessary, and if it is required, use an ingress controller to only expose the required services and pods.
• Restrict workload and host communication – Network policies within the cluster can be used to restrict communication between the cluster and the surrounding infrastructure. Network policies are workload-aware, making it possible to set highly granular rules.
• Restrict traffic to and from the cluster – You can use a cloud security control, such as a security group. However, because these tools are not workload-aware, they cannot set granular security policies. Therefore, they can be useful in combination with workload-aware controls inside the cluster.
• Limit east-west traffic – Implement a zero trust networking policy to only allow traffic inside the cluster if absolutely needed. This helps limit the damage done by limiting the attacker’s ability to move laterally to other potentially sensitive components in the cluster.

Secure the Kubernetes Datastore and API Server

Kubernetes datastores are the first and most critical asset you should secure in your clusters. The etcd datastore contains all data about the cluster configuration and desired state, so once an attacker gains access, they can take full control of the cluster.

An etcd data store can be secured using etcd’s own security features, which encrypt data transmitted over TLS using X.509-based keys and certificates. Additionally, you can restrict access to the etcd datastore to ensure only the node hosting the Kubernetes API server (the control node) can ever contact it. This can be done using network-level firewall rules.

The Kubernetes API Server similarly allows attackers complete control over a cluster, allowing them to configure the entire Kubernetes management lifecycle. The API server is the heart of the Kubernetes control plane, facilitating communication between the different parts of the cluster, end users, and external components. The API Server must also be secured using X.509 and TLS.

Restrict Cloud Metadata API Access

Cloud platforms (AWS, Azure, GCE, etc.) typically expose metadata services locally on compute instances (from the perspective of a Kubernetes cluster, nodes). By default, these APIs are accessible by pods running on the instance and can contain configuration data such as cloud credentials or kubelet credentials for that node. Attackers can use these credentials to escalate privileges to other cloud services within the cluster or in the same cloud account.

When running Kubernetes on a cloud platform, you should restrict the permissions granted to instance credentials, use network policies to restrict pod access to metadata APIs, and never distribute configuration data or secrets using cloud provider metadata.

Kubernetes Security and Observability with Calico

Tigera’s commercial solutions provide Kubernetes security and observability for multi-cluster, multi-cloud, and hybrid-cloud deployments. Both Calico Enterprise and Calico Cloud provide the following features for security and observability:

Security

• Zero trust for workloads – Prevent lateral movement of threats and maintain compliance by applying fine-grained security policies to restrict communication between workloads and third-party applications, the internet, and other workloads.
• Compliance reporting and alerts – Continuously monitor and enforce compliance controls, easily create custom reports for audit.
• Intrusion detection & prevention (IDS/IPS) – Detect and mitigate Advanced Persistent Threats (APTs) using machine learning and a rule-based engine that enables active monitoring.
• Microsegmentation across Host/VMs/Containers – Deploy a scalable, unified microsegmentation model for hosts, VMs, containers, pods, and services that works across all your environments.
• Data-in-transit encryption – Protect sensitive data and meet compliance requirements with high-performance encryption for data-in-transit.

Observability

• Dynamic Service and Threat Graph – Observe upstream and downstream dependencies for microservices, and service-to-service interactions within a Kubernetes cluster, with a dynamic live view that helps identify security gaps and troubleshoot connectivity issues faster.
• Application-layer observability – Gain visibility into service-to-service communication within your Kubernetes environment, without the operational complexity and performance overhead of service mesh.
• Dynamic Packet Capture – Perform packet capture for a specific pod or collection of pods with this self-service, on-demand tool. The tool integrates with Kubernetes RBAC to limit and secure users’ access to the endpoints and namespaces assigned to them.
• DNS Dashboard – Quickly confirm or eliminate DNS as the root cause for microservice and application connectivity issues in Kubernetes.
• Flow visualizer – Get a 360-degree view of a namespace or workload, including analytics around how security policies are being evaluated in real time and a volumetric representation of flows.

Next steps:

• Read our blog post: Enabling Workload-Level Security for AKS with Azure Firewall and Calico Egress Gateway
• Read our blog post: Using Web Application Firewall at container-level for network-based threats
• Read our guide: Kubernetes observability
• Check out our solution datasheet, Calico for Kubernetes Security
• Read our O’Reilly book: Kubernetes Security and Observability (free download)