Introduction
In the dynamic world of Kubernetes, securing your applications goes beyond just isolating pods and services. While Kubernetes Network Policies provide robust control over pod-to-pod communication, what about the underlying nodes themselves? How do you protect your cluster nodes from external threats, control outbound traffic originating from the node, or even manage traffic to and from host-networked pods and services? This is where Cilium’s Host Firewall capabilities shine, extending the powerful eBPF-based security model directly to the host operating system.
Traditional host-based firewalls often rely on `iptables`, which can become complex, difficult to manage at scale, and suffer from performance overheads. Cilium, leveraging the power of eBPF, offers a more elegant and performant solution. It allows you to define network policies that apply not just to Kubernetes pods, but also to the host’s network interfaces, acting as a comprehensive node-level firewall. This tutorial will guide you through the process of implementing Cilium Host Firewall policies, empowering you to enforce granular security rules directly on your Kubernetes worker nodes.
TL;DR
Cilium Host Firewall extends eBPF-based network policies to Kubernetes nodes, securing host-networked applications and controlling node-originated traffic. Install Cilium with host firewall enabled, then apply CiliumClusterwideNetworkPolicy or CiliumNetworkPolicy resources targeting host endpoints. Verify policies using cilium status and cilium endpoint get host.
# Install Cilium with host firewall support
helm install cilium cilium/cilium --version 1.15.5 \
--namespace kube-system \
--set hostFirewall.enabled=true \
--set hostServices.enabled=true \
--set egressMasqueradeInterfaces=eth0 \
--set k8sServiceHost=127.0.0.1 \
--set k8sServicePort=6443
# Example Host Firewall Policy (allow SSH to nodes from specific CIDR)
kubectl apply -f - <<EOF
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
name: allow-ssh-to-nodes
spec:
nodeSelector: {} # Applies to all nodes
endpointSelector:
matchLabels:
k8s:host-endpoint: "true" # Targets the host endpoint
ingress:
- fromCIDR:
- 192.0.2.0/24 # Your admin CIDR
toPorts:
- ports:
- port: "22"
protocol: TCP
EOF
# Verify host endpoint status
cilium status --wait
cilium endpoint get host -o wide
# Test connectivity
# ssh user@<node-ip> (from allowed CIDR)
# ssh user@<node-ip> (from disallowed CIDR, should fail)
Prerequisites
Before diving into Cilium Host Firewall, ensure you have the following:
- Kubernetes Cluster: A working Kubernetes cluster (v1.20+ recommended). For this guide, we’ll assume a fresh cluster, but you can adapt it to an existing one.
- `kubectl` and `helm` CLI: Installed and configured to interact with your cluster. Refer to the Kubernetes documentation for `kubectl` and the Helm installation guide.
- `cilium` CLI: Installed on your local machine. This tool is essential for interacting with Cilium directly. You can find installation instructions on the Cilium documentation site.
- Basic Understanding of Cilium: Familiarity with Cilium’s eBPF-based networking and network policy concepts will be beneficial. If you’re new to Cilium, consider reviewing their official documentation.
- Root/Sudo Access to Nodes (Optional but Recommended for Testing): For direct host-level verification and troubleshooting, access to your worker nodes will be helpful.
Step-by-Step Guide: Implementing Cilium Host Firewall
This section will walk you through the process of setting up Cilium with host firewall capabilities and defining your first node-level security policies.
Step 1: Install Cilium with Host Firewall Enabled
The first step is to install or upgrade Cilium on your Kubernetes cluster, ensuring that the host firewall feature is explicitly enabled. This involves setting the `hostFirewall.enabled` flag to `true` during the Helm installation. We’ll also enable `hostServices` to ensure that services exposed on the host’s network are properly handled by Cilium policies, and configure `egressMasqueradeInterfaces` for correct outbound traffic handling. The `k8sServiceHost` and `k8sServicePort` are configured to ensure Cilium agents can communicate with the Kubernetes API server directly, even if it’s running on the host network.
For a robust production setup, you might consider specific Cilium performance tuning parameters depending on your cluster size and traffic patterns. If you’re looking for advanced networking features like WireGuard encryption, remember to check out our guide on Cilium WireGuard Encryption for Pod-to-Pod Traffic.
# Add the Cilium Helm repository
helm repo add cilium https://helm.cilium.io/
# Update your Helm repositories
helm repo update
# Install Cilium with host firewall enabled
# Using a specific version (e.g., 1.15.5) for consistency
helm install cilium cilium/cilium --version 1.15.5 \
--namespace kube-system \
--set hostFirewall.enabled=true \
--set hostServices.enabled=true \
--set egressMasqueradeInterfaces=eth0 \
--set k8sServiceHost=127.0.0.1 \
--set k8sServicePort=6443 \
--set kubeProxyReplacement=strict \
--set tunnel=vxlan \
--set ipam.mode=clusterPool
# Wait for Cilium pods to be ready
kubectl rollout status -n kube-system ds/cilium --timeout=300s
Verify Step 1
After installation, verify that Cilium pods are running and healthy. Also, check the Cilium status to ensure the host firewall component is active.
kubectl get pods -n kube-system -l k8s-app=cilium
# Expected Output (pod names will vary)
# NAME READY STATUS RESTARTS AGE
# cilium-abcde 1/1 Running 0 2m
# cilium-fghij 1/1 Running 0 2m
cilium status --wait
# Expected Output (ensure Host Firewall is listed as enabled)
# ...
# Cluster health: OK
# All host endpoints are ready (2/2)
# All per-node Cilium health endpoints are ready (2/2)
# ...
# Host Firewall: enabled
# ...
Step 2: Identify Host Endpoints
When `hostFirewall.enabled` is set to `true`, Cilium automatically creates a special “host” endpoint on each node. This endpoint represents the node’s operating system itself, allowing you to target it with network policies. This is a crucial concept for applying node-level security. Cilium assigns a label, `k8s:host-endpoint: “true”`, to these host endpoints, which we’ll use in our policies.
Understanding how Cilium manages endpoints is key to its powerful observability features. For deeper insights into network flows and endpoint interactions, explore eBPF Observability: Building Custom Metrics with Hubble.
cilium endpoint get host -o wide
# Expected Output (example for a single node, output will vary per node)
# ENDPOINT ID STATUS POLICY IDENTITY LABELS IPv4 IPv6 NODE
# 8066 ready Enabled 65535 k8s:host-endpoint=true,k8s:io.kubernetes.pod.uid=host-endpoint-test 192.168.1.10 N/A node-1
# ... (similar output for other nodes)
Verify Step 2
The output from the `cilium endpoint get host -o wide` command should clearly show one host endpoint per node with the label `k8s:host-endpoint=true`. This confirms that Cilium has correctly initialized the host firewall feature on your nodes.
Step 3: Create a Basic Host Firewall Policy (Ingress)
Let’s start with a common scenario: restricting SSH access to your Kubernetes nodes. We’ll create a `CiliumClusterwideNetworkPolicy` (CCNP) to allow SSH (port 22 TCP) only from a specific CIDR block, denying all other SSH attempts. CCNPs are ideal for host firewall rules as they apply across the entire cluster.
This policy demonstrates ingress control to the node itself. For traffic leaving the node, you would define egress rules. Remember that these policies apply to traffic *to/from the node’s main network interface*, not necessarily to pods (unless those pods are explicitly using `hostNetwork: true`).
# allow-ssh-to-nodes.yaml
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
name: allow-ssh-to-nodes
spec:
# nodeSelector: {} means this policy applies to all nodes in the cluster.
# You can use standard Kubernetes node labels here to target specific nodes.
nodeSelector: {}
endpointSelector:
matchLabels:
k8s:host-endpoint: "true" # This targets the special host endpoint on each node
ingress:
- fromCIDR:
- 192.0.2.0/24 # REPLACE THIS WITH YOUR ADMIN WORKSTATION/JUMPBOX CIDR!
- 10.0.0.0/8 # Example: Allow from internal management network
toPorts:
- ports:
- port: "22"
protocol: TCP
# You can optionally add an egress section here if you also want to control
# traffic originating from the node itself.
# egress:
# - toEndpoints:
# - matchLabels:
# k8s:io.kubernetes.pod.namespace=kube-system # Example: allow egress to kube-system pods
Apply the policy:
kubectl apply -f allow-ssh-to-nodes.yaml
Verify Step 3
Verify that the policy has been applied and is active on the host endpoints. Then, test connectivity.
# Check if the policy is applied to the host endpoint
cilium endpoint get host -o wide
# Expected Output (verify policy is enabled and policy ID matches)
# ENDPOINT ID STATUS POLICY IDENTITY LABELS IPv4 IPv6 NODE
# 8066 ready Enabled 65535 k8s:host-endpoint=true,k8s:io.kubernetes.pod.uid=host-endpoint-test 192.168.1.10 N/A node-1
# ...
# The 'POLICY' column should show 'Enabled'.
# Describe the policy to see its status
kubectl get ciliumclusterwidenetworkpolicy allow-ssh-to-nodes -o yaml
# Test SSH from an ALLOWED IP (e.g., your workstation if its IP is in 192.0.2.0/24)
# You should be able to SSH into your node.
# ssh user@<node-ip>
# Test SSH from a DISALLOWED IP (e.g., a different network or a VPN not in the CIDR)
# This connection attempt should be blocked. You might see a timeout or connection refused.
# ssh user@<node-ip>
Step 4: Create an Egress Host Firewall Policy
Beyond ingress, controlling outbound traffic from your nodes is equally important. This can prevent nodes from communicating with unauthorized external services or exfiltrating data. Let’s create a policy to restrict egress from the nodes, allowing only DNS (UDP 53) and HTTP/HTTPS (TCP 80, 443) to external services. All other outbound traffic will be implicitly denied by Cilium’s default deny behavior if no other egress policy matches.
When managing egress traffic at scale, especially for large language models or AI workloads, efficient network policies are critical. For more on optimizing Kubernetes for such demanding applications, check out our guide on Running LLMs on Kubernetes: GPU Scheduling Best Practices.
# restrict-node-egress.yaml
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
name: restrict-node-egress
spec:
nodeSelector: {} # Applies to all nodes
endpointSelector:
matchLabels:
k8s:host-endpoint: "true"
egress:
- toPorts:
- ports:
- port: "53"
protocol: UDP
toEntities:
- world # Allow DNS to any external IP
- toPorts:
- ports:
- port: "80"
protocol: TCP
- port: "443"
protocol: TCP
toEntities:
- world # Allow HTTP/HTTPS to any external IP
# You can also specify toCIDR for specific external destinations
# - toCIDR:
# - 1.2.3.4/32
# toPorts:
# - ports:
# - port: "8080"
# protocol: TCP
Apply the policy:
kubectl apply -f restrict-node-egress.yaml
Verify Step 4
Verify the policy’s application and test egress from a node. You’ll need to SSH into a node for this test.
# Check again the host endpoint status for policy updates
cilium endpoint get host -o wide
# SSH into one of your nodes
# ssh user@<node-ip>
# Test allowed egress (e.g., DNS lookup, curl to a public website)
# This should succeed
ping -c 3 google.com
curl -v https://www.example.com
# Test disallowed egress (e.g., trying to reach a non-standard port externally)
# This should fail or timeout
curl -v http://neverssl.com:8080
telnet bad.example.com 1234 # Replace with an actual external IP/port not allowed by policy
Step 5: Securing Host-Networked Pods/Services
Cilium Host Firewall isn’t just for the node’s inherent services; it can also secure Kubernetes pods that run with `hostNetwork: true` or services that directly expose ports on the host. By default, these pods are not subject to standard Kubernetes Network Policies. However, by targeting the `k8s:host-endpoint: “true”` label, you can apply policies to traffic destined for or originating from these host-networked components.
Let’s imagine you have a Prometheus node exporter running with `hostNetwork: true` on port 9100. We want to allow access to this exporter only from a specific monitoring namespace.
For more advanced traffic management and security for services, especially in a hybrid or multi-cluster environment, consider exploring solutions like Istio Ambient Mesh Production Guide or leveraging the Kubernetes Gateway API vs Ingress for modern ingress control.
# prometheus-node-exporter-hostnetwork.yaml
# Example deployment of a (mock) node exporter using hostNetwork
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-exporter
namespace: monitoring # Example namespace
spec:
selector:
matchLabels:
app: node-exporter
template:
metadata:
labels:
app: node-exporter
spec:
hostNetwork: true # CRITICAL: This makes it host-networked
containers:
- name: node-exporter
image: prom/node-exporter:v1.8.1 # Or any other host-networked application
ports:
- containerPort: 9100
hostPort: 9100 # Expose on host port 9100
name: metrics
command: ["/bin/sh", "-c", "echo 'Node exporter metrics' > /tmp/metrics && nc -lk -p 9100 -e cat /tmp/metrics"]
# This is a very basic mock for demonstration; use actual node-exporter in production.
Apply the mock node exporter:
kubectl create namespace monitoring
kubectl apply -f prometheus-node-exporter-hostnetwork.yaml
# Wait for the DaemonSet to be ready
kubectl rollout status -n monitoring ds/node-exporter --timeout=300s
Now, create a Cilium policy to allow access to port 9100 only from pods in the `monitoring` namespace (assuming your Prometheus server is there).
# allow-monitoring-to-node-exporter.yaml
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
name: allow-monitoring-to-node-exporter
spec:
nodeSelector: {} # Apply to all nodes where node-exporter might run
endpointSelector:
matchLabels:
k8s:host-endpoint: "true" # Target the host endpoint
ingress:
- fromEndpoints:
- matchLabels:
k8s:io.kubernetes.pod.namespace: monitoring # Allow from any pod in 'monitoring' namespace
toPorts:
- ports:
- port: "9100"
protocol: TCP
Apply the policy:
kubectl apply -f allow-monitoring-to-node-exporter.yaml
Verify Step 5
Verify the policy and test access to the host-networked service.
# Check policy application
cilium endpoint get host -o wide
# Expected: Policy 'allow-monitoring-to-node-exporter' should be active.
# Try to access node-exporter from a NON-MONITORING pod (e.g., a test pod in default namespace)
kubectl run -it --rm --restart=Never debug-pod --image=busybox -- /bin/sh
# Inside the debug-pod:
# wget -T 2 -qO- http://<node-ip>:9100
# This should FAIL (timeout or connection refused)
# Now, deploy a test pod in the 'monitoring' namespace
kubectl run -it --rm --restart=Never debug-monitoring-pod --image=busybox --namespace monitoring -- /bin/sh
# Inside the debug-monitoring-pod:
# wget -T 2 -qO- http://<node-ip>:9100
# This should SUCCEED and show "Node exporter metrics"
Production Considerations
Implementing Cilium Host Firewall in production requires careful planning and continuous monitoring. Here are some key considerations:
- Granularity and Specificity: Start with broad policies and progressively refine them. Avoid overly permissive rules like `toEntities: [world]` for egress unless absolutely necessary. Use `toCIDR`, `toEndpoints`, and `toServices` for precise control.
- Default Deny Philosophy: Cilium policies, like Kubernetes Network Policies, operate on a default-deny principle. If no policy explicitly allows traffic, it will be blocked. Plan your policies to allow only necessary traffic. For more on secure configurations, refer to our Kubernetes Network Policies: Complete Security Hardening Guide.
- Node Labels for Policy Scope: Utilize Kubernetes node labels with `nodeSelector` in your `CiliumClusterwideNetworkPolicy` to apply policies only to specific groups of nodes (e.g., `prod-nodes`, `database-nodes`). This prevents unintended impacts and allows for environment-specific rules.
- Impact on Node Services: Be mindful of critical node services (kubelet, kube-proxy, CNI, logging agents, monitoring agents, SSH, etc.). Ensure your host firewall policies explicitly allow necessary communication for these services, both ingress and egress. A misconfigured policy can render nodes unreachable or dysfunctional.
- Testing Strategy: Thoroughly test all host firewall policies in a staging environment before deploying to production. Use traffic generators, connectivity checks, and application-level tests to validate expected behavior.
- Observability and Monitoring: Integrate Cilium’s observability tools like Hubble (part of the Cilium project) to monitor network flows and policy enforcement. Hubble can provide real-time visibility into traffic being allowed or denied by your host firewall policies. See our guide on eBPF Observability: Building Custom Metrics with Hubble.
- Incident Response: Have a clear plan for quickly identifying and troubleshooting network connectivity issues caused by host firewall policies. This includes knowing how to temporarily disable policies or debug with `cilium monitor` and `cilium endpoint get`.
- Integration with Cloud Provider Firewalls: Cilium Host Firewall operates at a different layer than cloud provider security groups or network ACLs. Consider them as complementary layers of defense. Cloud provider firewalls provide perimeter defense, while Cilium offers granular, identity-aware enforcement within the cluster and on the nodes.
- Resource Overhead: While eBPF is highly performant, complex policies can consume resources. Monitor CPU and memory usage of the Cilium agent on your nodes, especially in clusters with many nodes and intricate policies.
- Backup and Version Control: Treat your Cilium policies as critical infrastructure code. Store them in version control (Git) and include them in your backup strategy.
Troubleshooting
Cilium Host Firewall, while powerful, can sometimes lead to unexpected connectivity issues if policies are not carefully constructed. Here are common issues and their solutions:
-
Issue: SSH access to nodes is blocked, even from allowed CIDR.
Solution: Double-check the `fromCIDR` in your `CiliumClusterwideNetworkPolicy`. Ensure it exactly matches the source IP range you are trying to connect from. Also, verify that no other policy is implicitly denying SSH. Use `cilium policy get` to review all active policies and `cilium endpoint get host -o wide` to see which policies are applied to the host endpoint.
# Check applied policies cilium policy get cilium endpoint get host -o wide # Example of a misconfigured policy: # - fromCIDR: [ "192.168.1.0/24" ] # Your workstation is 192.168.2.10, so it's blocked. -
Issue: Pods using `hostNetwork: true` are unreachable or cannot reach external services.
Solution: Host-networked pods are treated as part of the host endpoint. Their traffic is subject to host firewall policies. Ensure you have specific `ingress` and `egress` rules in your `CiliumClusterwideNetworkPolicy` targeting the host endpoint (via `endpointSelector: { matchLabels: { k8s:host-endpoint: “true” } }`) that permit the necessary traffic for these pods. Also, verify that `hostServices.enabled=true` during Cilium installation.
# Verify Cilium installation parameters helm get values cilium -n kube-system # Example policy to allow ingress to a host-networked service on port 8080: # ingress: # - toPorts: # - ports: # - port: "8080" # protocol: TCP # fromEndpoints: # - matchLabels: # k8s:io.kubernetes.pod.namespace=my-app-clients # or fromCIDR -
Issue: Node-originated traffic (e.g., `apt update`, `curl` from node) is blocked.
Solution: This indicates an issue with your egress policies on the host endpoint. Ensure you have rules allowing DNS (UDP 53) to `world` or specific DNS servers, and HTTP/HTTPS (TCP 80, 443) to `world` or relevant package repositories/API endpoints. If using `kubeProxyReplacement=strict`, ensure your `k8sServiceHost` and `k8sServicePort` are correctly configured to reach the API server.
# Example of allowing basic egress # egress: # - toPorts: # - ports: [{port: "53", protocol: UDP}] # toEntities: [world] # - toPorts: # - ports: [{port: "80", protocol: TCP}, {port: "443", protocol: TCP}] # toEntities: [world] # Check Cilium logs for denied traffic kubectl logs -n kube-system -l k8s-app=cilium --tail 100 | grep "policy denied" -
Issue: Cilium agent pods are not ready or in an unhealthy state.
Solution: Check the Cilium agent logs for errors. Common reasons include misconfigured `kubeProxyReplacement`, network interface issues, or resource constraints. Ensure your `k8sServiceHost` and `k8sServicePort` correctly point to your Kubernetes API server. If you encounter issues with Cilium’s core functionality, refer to the official Cilium troubleshooting guide.
kubectl logs -n kube-system -l k8s-app=cilium -f cilium status -
Issue: Policies are applied but don’t seem to have an effect.
Solution: Verify that the `endpointSelector` in your policy correctly targets the host endpoint (`matchLabels: { k8s:host-endpoint: “true” }`). Also, ensure the `nodeSelector` (if present) matches the nodes you expect. Use `cilium monitor` to see real-time traffic flows and identify if packets are being dropped by a policy. You can also use `cilium policy trace` for detailed policy evaluation.
# Monitor traffic and policy decisions cilium monitor --type drop --verbose # Trace policy decisions for a specific connection # Replace <source-ip>, <destination-ip>, <port>, <protocol> cilium policy trace --src-ip <source-ip> --dst-ip <destination-ip> --dst-port <port> --proto <protocol>
FAQ Section
-
Q: What is the difference between Cilium Host Firewall and regular Kubernetes Network Policies?
A: Regular Kubernetes Network Policies (`NetworkPolicy` kind) apply only to Kubernetes pods. They control traffic between pods and from/to external services but do not directly manage traffic to/from the Kubernetes nodes themselves. Cilium Host Firewall, using `CiliumClusterwideNetworkPolicy` or `CiliumNetworkPolicy` with `endpointSelector: { matchLabels: { k8s:host-endpoint: “true” } }`, extends this capability to the host operating system, securing traffic to and from the node’s network interfaces and host-networked applications. -
Q: Can I use Cilium Host Firewall with other CNI plugins?
A: No. Cilium Host Firewall is a feature of Cilium and relies on Cilium’s eBPF dataplane. It requires Cilium to be your active CNI plugin. -
Q: How does Cilium Host Firewall interact with cloud provider security groups or `iptables`?
A: Cilium Host Firewall operates at a lower level (eBPF hooks in the kernel) than traditional `iptables` rules. Generally, Cilium’s eBPF policies take precedence or coexist, often replacing the need for complex `iptables` management for host-level filtering. Cloud provider security groups (e.g., AWS Security Groups) act as a perimeter firewall at the instance level. Cilium Host Firewall provides a more granular, identity-aware layer of security *on* the instance. They are complementary layers of defense. -
Q: Is it safe to apply policies to the host endpoint without `nodeSelector`?
A: Applying policies without a `nodeSelector` means they will apply to *all* nodes in the cluster. This is often the desired behavior for cluster-wide host security rules (like restricting SSH). However, for policies that should only affect specific types of nodes (e.g., database nodes), using `nodeSelector` is crucial to prevent unintended side effects on other nodes. -
Q: How can I monitor traffic that is being blocked by my Host Firewall policies?
A: The `cilium monitor` command is your primary tool. Specifically, `cilium monitor –type drop –verbose` will show you packets that are being dropped by Cilium, including the policy decision that led to the drop. You can also use `cilium policy trace` for a detailed simulation of how a specific packet would be handled by your policies. For a more visual approach, deploy Hubble, Cilium’s observability tool, which provides a UI for network flows. Learn more about it in our eBPF Observability with Hubble guide.
Cleanup Commands
To remove the resources created during this tutorial:
# Delete the CiliumClusterwideNetworkPolicies
kubectl delete ciliumclusterwidenetworkpolicy allow-ssh-to-nodes
kubectl delete ciliumclusterwidenetworkpolicy restrict-node-egress
kubectl delete ciliumclusterwidenetworkpolicy allow-monitoring-to-node-exporter
# Delete the mock node-exporter DaemonSet and namespace
kubectl delete daemonset node-exporter -n monitoring
kubectl delete namespace monitoring
# Uninstall Cilium (this will remove all Cilium components and policies)
helm uninstall cilium -n kube-system
# Remove the Cilium Helm repository
helm repo remove cilium
# Remove the Cilium CLI (if desired)
# For Linux:
# rm /usr/local/bin/cilium
# For macOS:
# rm /usr/local/bin/cilium
Next Steps / Further Reading
You’ve now mastered the basics of securing your Kubernetes nodes with Cilium Host Firewall. To deepen your knowledge and explore more advanced use cases:
- Cilium Network Policy Deep Dive: Explore the full range of selectors and rules available in Cilium policies, including L7 enforcement and DNS-based policies. Refer to the Cilium Network Policy documentation.
- Identity-Aware Security: Understand how Cilium uses identities for policy enforcement, which is more robust than traditional IP-based rules.
- Hubble for Observability: Deploy Hubble to visualize network flows, troubleshoot connectivity, and gain deep insights into your cluster’s network behavior. Our guide on eBPF Observability: Building Custom Metrics with Hubble is a great starting point.
- Advanced Cilium Features: Investigate features like Transparent Encryption (including WireGuard integration, which we cover in Cilium WireGuard Encryption for Pod-to-Pod Traffic) and Egress Gateway for managing outbound traffic from specific pods.
- Kubernetes Security Best Practices: Combine Host Firewall with other security measures like admission controllers (e.g., Kyverno, as discussed in Securing Container Supply Chains with Sigstore and Kyverno), pod security standards, and regular vulnerability scanning.
- Cost Optimization: While not directly related to security, optimizing your cluster’s resource usage can indirectly improve its security posture by reducing the attack surface. Explore tools like Karpenter
