--- title: "Kubernetes Firewall" source: "https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-firewall/" description: "A Kubernetes firewall tracks and filters all inbound and outbound communications with production Kubernetes clusters." --- ## Guides: Kubernetes Firewall # Kubernetes Firewall: A Practical Guide to Securing K8s Networks - [Kubernetes Security](https://www.tigera.io/learn/guides/kubernetes-security/) - [Kubernetes Distributions](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-distributions/) - [High Availability Kubernetes](https://www.tigera.io/learn/guides/kubernetes-security/high-availability-kubernetes/) - [Kubernetes Statistics](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-statistics/) - [NGINX Ingress](https://www.tigera.io/learn/guides/kubernetes-security/nginx-ingress/) - [Kubernetes Security Tools for Enterprises](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-security-tools-for-enterprises/) - [Kubernetes Security Platforms](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-security-platforms/) - [Kubernetes Security Software](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-security-software/) - [Kubernetes Gateway API](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-gateway-api/) - [Kubernetes Multi Tenancy](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-multi-tenancy/) - [Kubernetes Namespace](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-namespace/) - [GKE Security](https://www.tigera.io/learn/guides/kubernetes-security/gke-security/) - [Kubernetes Certification](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-certification/) - [Kubernetes Security Context](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-security-context/) - [Kubernetes CIS Benchmark](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-cis-benchmark/) - [Kubernetes WAF](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-waf/) - [Kubernetes Federation](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-federation/) - [Kubernetes Network Policy](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-network-policy/) - [Kubernetes Network Security](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-network-security/) - [KSPM](https://www.tigera.io/learn/guides/kubernetes-security/kspm/) - [Kubernetes Compliance](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-compliance/) - [Kubernetes Firewall](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-firewall/) - [Kubernetes Security Policy](https://www.tigera.io/blog/kubernetes-security-policy-10-critical-best-practices/) - [Kubernetes Vulnerability](https://www.tigera.io/blog/kubernetes-q3-2020-threats-exploits-and-ttps/) - [Kubernetes Vulnerability Scanning](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-vulnerability-scanning/) - [AKS Security](https://www.tigera.io/learn/guides/kubernetes-security/aks-security/) - [EKS Security](https://www.tigera.io/learn/guides/kubernetes-security/eks-security/) - [OpenShift Security](https://www.tigera.io/learn/guides/kubernetes-security/openshift-security/) ## 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. **Editor’s note:** Updated to address AI and LLM security use cases of Kubernetes firewalls. This is part of our series of articles about [Kubernetes security](https://www.tigera.io/learn/guides/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? - The Role of Kubernetes Firewalls in Securing AI and LLM Workloads - Kubernetes Firewalls and Network Security Best Practices - 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. Firewall rules are only part of the picture—security teams also need to track each new [Kubernetes vulnerability](https://www.tigera.io/blog/kubernetes-q3-2020-threats-exploits-and-ttps/) and the exploits attackers use against clusters. 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. - **Protecting LLM and AI Workloads –** As organizations increasingly deploy large language models (LLMs) and AI inference services in Kubernetes, these workloads become high-value targets. Firewalls can isolate AI services from unauthorized network access, restrict outbound calls to only approved APIs, and prevent data leakage of model inputs or outputs. ## 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](https://www.tigera.io/blog/kubernetes-security-policy-10-critical-best-practices/)*** ## 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. ## The Role of Kubernetes Firewalls in Securing AI and LLM Workloads As AI and LLM services move into production, their inference endpoints become high-value entry points into Kubernetes clusters. These services are typically exposed through REST or gRPC APIs and can trigger expensive GPU operations and access sensitive internal data. This changes the security requirements at the cluster edge. Kubernetes firewalls must now inspect and control application-layer traffic to prevent cost abuse, data exposure, and service instability before inference begins: - **Cost-based abuse of inference endpoints:** AI requests are computationally expensive. Attackers can send large or complex prompts that appear valid but keep GPUs saturated. The goal is not to cause downtime, but to generate sustained resource consumption and inflated cloud bills. A firewall with Layer 7 inspection can analyze request payloads and block abusive traffic before it reaches the model and consumes GPU capacity. - **Prompt injection and input manipulation:** AI endpoints are vulnerable to prompt injection attacks that attempt to override safeguards, extract sensitive information, or force unintended behavior. These threats exist in the request body, not just in headers or IP addresses. Network-level controls cannot detect this type of abuse. Firewalls that inspect full HTTP payloads can enforce application-level rules and filter suspicious prompt content before inference starts. - **Data exposure in AI pipelines:** Modern AI services often connect to vector databases and retrieval-augmented generation (RAG) systems. If ingress traffic is not deeply inspected, attackers may exploit application-layer weaknesses to probe or manipulate backend data sources. This can result in leakage of sensitive information, corruption of data pipelines, or untrustworthy model outputs. Layer 7 controls help detect and block these patterns at the edge. - **Limitations of traditional ingress controls:** Most Kubernetes ingress controllers focus on TLS termination, authentication, and routing. They provide limited visibility into request complexity and cannot distinguish between legitimate usage and targeted cost abuse. Rate limiting based only on IP address or request count is not sufficient for AI workloads, where a single request may carry high computational cost. - **Identity-aware access and fine-grained rate limiting:** AI inference endpoints are often exposed with minimal authentication. A firewall can enforce identity-based access policies so only authorized users or services can trigger inference. It can also apply multi-dimensional rate limiting based on API keys, request type, or source identity. This allows teams to protect high-cost operations without blocking legitimate traffic. - **Operational stability and early threat detection:** Because AI workloads rely on heavy compute, ingress latency or abuse can cause cascading failures across microservices. Firewalls at the cluster edge provide visibility into abnormal traffic patterns and enable early enforcement. By filtering malicious or abusive requests before they reach backend services, teams can maintain reliability and predictable performance. ## 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. For more granular, role-oriented control over ingress traffic and routing, teams are increasingly adopting the [Kubernetes gateway API](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-gateway-api/) as a successor to the traditional Ingress resource. - **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](https://www.tigera.io/blog/deep-dive/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](https://www.tigera.io/blog/using-web-application-firewall-at-container-level-for-network-based-threats/) - Read our guide: [Kubernetes observability](https://www.tigera.io/blog/kubernetes-observability-challenges-the-need-for-an-ai-driven-solution/) - Check out our solution datasheet, [Calico for Kubernetes Security](https://info.tigera.io/rs/805-GFH-732/images/Tigera_solution_datasheet_Calico_for_Kubernetes_Security.pdf) - Read our O’Reilly book: [Kubernetes Security and Observability](https://www.tigera.io/blog/oreilly-ebook-kubernetes-security-and-observability-early-release/?utm_campaign=O%27Reilly-book&utm_medium=blog&utm_source=blog-CTA) (free download)