Securing Kubernetes Access: A VPN-Integrated Solution for Public Endpoints

In today's cloud-native landscape, securing access to Kubernetes (K8s) clusters—especially those with public endpoints—is a top priority. This article presents a practical, Azure-centric network architecture that ensures all traffic to public K8s endpoints is funneled through a Virtual Private Network (VPN), providing centralized control, enhanced security, and comprehensive auditability.

The Challenge: Unifying Public and Private Access to Kubernetes

Many organizations deploy Kubernetes clusters that must serve both public-facing applications and internal management needs. Directly exposing K8s public endpoints increases the attack surface and introduces security risks. The challenge is to enforce that even public connections are routed through a secure VPN tunnel, centralizing access and inspection.

Note: If your goal is to force all remote user Internet traffic through Azure (for example, to provide a single egress public IP for SaaS whitelisting or geo-blocking), this cannot be achieved with a standard Point-to-Site VPN Gateway alone. While you can advertise custom default routes, Internet-bound traffic is dropped by design on regular VPN gateways. The only native Azure solution for this scenario is to use Azure Virtual WAN with a Secured Virtual Hub and Azure Firewall.

The Solution: Azure-Centric VPN Gateway Architecture

The proposed architecture leverages Azure's networking capabilities to create a secure, controlled pathway to Kubernetes resources.

Key Components

• Public K8s API Endpoint: The entry point to the Kubernetes cluster, which is not directly exposed but routed through the VPN.
• Internet & Azure Firewall: Incoming connections are directed to a public IP (e.g., 203.0.113.10/32). Azure Firewall acts as the first defense, filtering and inspecting traffic.
• Azure Virtual WAN & Secured Virtual Hub:
  • Virtual WAN acts as a virtual router, enabling forced tunneling for Point-to-Site clients.
  • Secured Virtual Hub integrates with Azure Firewall for centralized egress and security.
  • Virtual Hub Router ensures intelligent routing within the secure network.
• Azure Firewall: Provides SNAT for outbound Internet traffic, ensuring all VPN client traffic exits Azure with a Microsoft public IP.
• P2S Gateway (Point-to-Site Gateway): Facilitates secure VPN connections for clients, ensuring all traffic (even to public endpoints) traverses the VPN.
• P2S VPN Connection: Encrypts all data between clients and the Azure network.
• Client VPN Pool (172.16.0.0/16): Assigns IPs to VPN clients, treating all traffic as originating from a secure source.

How This Architecture Solves the Problem

• Mandatory VPN Traversal: All inbound traffic to the K8s public endpoint is forced through the P2S VPN, treating external requests as VPN client traffic.
• Centralized Security Enforcement: Azure Firewall applies security policies to all incoming traffic, including that for public endpoints.
• Enhanced Auditability: All traffic through the VPN and Virtual WAN is logged and monitored, providing a comprehensive audit trail.
• Simplified Network Management: Azure Virtual WAN streamlines management and scaling of secure access.
• Centralized Egress IP: All outbound Internet traffic from VPN clients is SNATed through Azure Firewall, providing a single, static public IP address for whitelisting or geo-blocking.

Deployment Overview

Setting up forced tunneling for Point-to-Site VPN clients through Azure Virtual WAN and Azure Firewall involves several steps:

1. Deploy a Virtual WAN: Use the Standard SKU to support Point-to-Site connections.
2. Create a Virtual Hub: This managed virtual network will host the VPN gateway and routing. Configure the User VPN (Point-to-Site) gateway here, and use Azure AD authentication if desired.
3. Create a Firewall Policy: Required for Azure Firewall (Standard or Premium SKU). Configure rules to allow necessary VPN traffic.
4. Add the Policy to the Virtual Hub: Assign the firewall policy to the Virtual Hub via Firewall Manager, which deploys Azure Firewall.
5. Assign Security Configuration: In the Virtual Hub, set Internet traffic to route through Azure Firewall. This updates the default route for all VPN clients.
6. Enable the ‘InternetSecurityFlag’: Ensure this property is set on the Point-to-Site gateway to allow forced tunneling.
7. Configure the VPN Client Profile: Download the VPN profile from the Virtual WAN, edit the <version> element in azurevpnconfig.xml to 2 if needed, and import it into the Azure VPN client.

Once connected, all client traffic (including Internet-bound) is routed through Azure Firewall and exits Azure with the firewall’s public IP. This enables centralized egress, easier whitelisting, and enhanced security monitoring.

Real-World Impact

Implementing this architecture can dramatically improve the security and manageability of Kubernetes deployments with public endpoints. Organizations benefit from:

• Centralized control over all access paths
• Improved visibility and auditability of network traffic
• Reduced risk of unauthorized access or data breaches

Cost Considerations

While this architecture significantly enhances security and manageability, it is important to consider the associated costs:

• Azure Firewall: Charged based on deployment, data processed, and rules configured.
• Virtual WAN & Secured Virtual Hub: Incur costs for hub deployment, routing, and data transfer.
• P2S VPN Gateway: Billed for gateway hours and data throughput.
• Public IP Addresses: Static public IPs have associated charges.
• Logging & Monitoring: Storing and analyzing logs (e.g., in Azure Monitor or Log Analytics) adds to operational expenses.

Important: Azure Virtual WAN combined with Azure Firewall is not a low-cost solution. Expect costs well over $1,000 per month for this setup. It is best suited for organizations with broader Azure networking needs, not just for centralized egress.

Optimization Tips:

• Regularly review usage and scale resources to match demand.
• Use Azure Cost Management tools to monitor and forecast expenses.
• Consider reserved capacity or hybrid benefits where applicable.

The investment in these services should be weighed against the value of improved security, compliance, and operational efficiency.

Conclusion

By integrating public Kubernetes endpoints into a VPN-driven Azure architecture—leveraging Azure Virtual WAN and Firewall for forced tunneling and centralized egress—organizations can achieve robust, compliant, and manageable security for their cloud-native workloads. This approach is particularly valuable when a single, static public IP is required for outbound traffic, but comes with significant cost and complexity.

This approach demonstrates a strong understanding of cloud networking principles and a commitment to building secure, resilient infrastructure for modern Kubernetes deployments.