Skip to main content
securing-the-kubernetes_w7oans.webp

Securing the Kubernetes: Implement Zero Trust Network Security with Tailscale

Saurabh Kumar

Saurabh Kumar


Implementing Zero Trust Security in Kubernetes

Containers have transformed application deployment, and Kubernetes has become the de facto standard for container orchestration at scale. However, while Kubernetes streamlines infrastructure management, it also introduces critical security challenges. As organizations deploy complex microservices, their Kubernetes security posture often lags behind rapid expansion. The Kubernetes API server—acting as the control plane’s nerve center—manages administrative operations, workloads, and service interactions. Left exposed without proper safeguards, this high-value target can grant attackers full control over an entire Kubernetes environment.

Research reveals that many Kubernetes API servers remain publicly accessible, significantly increasing the risk of unauthorized access and potential breaches. Beyond the API server, organizations must also secure internal applications, databases, monitoring tools, and other sensitive services against external threats. Traditional perimeter-based network security models are no longer sufficient in today’s cloud-native landscape. Instead, implementing a Zero Trust Kubernetes security approach ensures that only authenticated and authorized users or devices can access critical resources—regardless of location or network connection.

A Zero Trust architecture for Kubernetes isn’t just a best practice; it’s essential for organizations aiming to comply with security frameworks like SOC 2, ISO 27001, and NIST CSF. These standards emphasize strict access controls, continuous verification, and least privilege access, all fundamental to Zero Trust network security. By adopting Zero Trust principles and leveraging solutions like Kubernetes VPN security, organizations can proactively protect their clusters, enforce compliance, and mitigate the risks of unauthorized access.

At CloudRaft, we specialize in securing Kubernetes environments with Zero Trust security solutions that safeguard sensitive infrastructure and ensure compliance. Explore our security consulting services to strengthen your Kubernetes security strategy today.

Zero trust security architecture NIST 800-207
Zero trust security architecture NIST 800-207

What is Zero Trust Security?

Zero Trust security is an IT security model that requires strict identity verification for every person and device trying to access resources on a private network, regardless of whether they are sitting within or outside of the network perimeter. ZTNA is the main technology associated with Zero Trust architecture, but Zero Trust is a holistic approach to network security that incorporates several different principles and technologies.

More simply put: traditional IT network security trusts anyone and anything inside the network. A zero-trust architecture trusts no one and nothing.

What is Tailscale?

Tailscale is a modern VPN built on WireGuard® that creates a secure network between your devices. It simplifies secure connections by handling NAT traversal, key distribution, and offers user-friendly coordination between devices.

Key benefits include:

  • Simple Setup and Configuration: Tailscale can be set up with minimal effort. It does not require complex firewall configurations or VPN server management.
  • Security and Privacy: The Tailscale security model is built on modern, proven technologies and best practices such as end-to-end encryption and a zero-trust architecture. At its core, Tailscale uses WireGuard, a state-of-the-art VPN protocol known for its security and performance. It enables encrypted point-to-point connections using the open source WireGuard protocol, which means only devices on your private network can communicate with each other.

Demo: Implementing Zero Trust Network Security for Kubernetes with Tailscale

In this demo, we are going to secure the AKS cluster endpoint. The same approach applies to any other managed Kubernetes service, regardless of the cloud provider.

Architecture: Tailscale implementation for Kubernetes

Tailscale AKS architecture
Tailscale AKS architecture

Step 1: Configure the Tailscale exit node

  1. Launch a VM in your preferred cloud provider (Azure in this example)
  2. Assign a static public IP address to this VM
  3. Install Tailscale on the VM
    curl -fsSL https://tailscale.com/install.sh | sh
    bash
  4. To configure as an Exit node follow this official guide
  5. Configure the VM as an exit node in the Tailscale admin console(web UI)
    • Navigate to the Machines section
    • Find your VM and enable Exit node functionality.

Step 2: Configure AKS to whitelist the exit node

  1. In the Azure portal, navigate to your AKS cluster.
  2. Under Networking, under Resource Settings.
  3. Enable the checkbox Set authorized IP ranges.
  4. Add the static public IP address of your Tailscale exit node VM.
Whitelisting IP address of the tailscale exit node VM
Whitelisting IP address of the tailscale exit node VM

Step 3: Invite the user to your tailnet

Now invite the user from the tailscale web UI and then provide the permission you want to assign.

Invite users from Tailscale WebUI
Invite users from Tailscale WebUI

Step 4: Connect to Tailnet using exit node

When the user tries to interact with the AKS cluster then they need to connect to the tailscale network and select exit node as the tailscale VM name.

Connect to Kubernetes via exit node
Connect to Kubernetes via exit node

Verification

To verify the setup is working correctly:

  1. Users check their public IP before connecting to Tailscale (Who is going to interact with AKS):

    curl ifconfig.me
    bash
  2. After connecting to Tailscale with the exit node-enabled:

    curl ifconfig.me
    bash

    NOTE: The IP should now match the exit node's public IP

  3. Test connectivity to Kubernetes cluster

    kubectl get nodes
    bash

Only authorized users routing through Tailscale should be able to successfully connect to the Kubernetes API server.

Demo: How to secure Kubernetes internal applications

This demonstration shows how to protect internal applications (or those not meant for public exposure) by isolating them and only via the Tailscale network (tailnet). For this demo We have an AKS cluster, and we've deployed the Traefik ingress controller. As a result, the controller created a load balancer that can expose internal applications externally. Now, we will configure the load balancer to restrict traffic and only accept requests from the public IP of the Tailscale exit node. This way, only users connected to the tailnet can access the internal applications via the exit node.

Architecture of the demo

Architecture: To connect to internal applications domain on AKS
Architecture: To connect to internal applications domain on AKS

When the user connected to the Tailscale VPN only then they can able to access their internal applications domains

Step 1: Configure the tailscale exit node

Refer to the Step 1: Configure the Tailscale Exit Node section above for the steps to configure the Tailscale exit node.

Step 2: Configure the Ingress controller Load Balancer to Accept Traffic Only from the Tailscale Exit Node Public IP Address

Navigate to the Network Security Group (NSG) associated with the subnet where the AKS cluster is deployed.

Create a new inbound security rule to allow traffic from the Tailscale exit node's public IP address.

  • Source IP: The static public IP address of the Tailscale VM exit node.
  • Destination IP: The IP address of the ingress controller's load balancer.
  • Port: 443, 80
  • Protocol: TCP
 Inbound rule for allow traffic from only tailscale VM(exit node)
Inbound rule for allow traffic from only tailscale VM(exit node)

In this step, we discussed how to expose our application's Ingress so that it is accessible only to users connected to the Tailscale VPN. However, if we want to access the application using its ClusterIP or Service IP—similar to how we use port forwarding in development—we need to ensure that the user has access to the API server (as configured above). Only then will they be able to access the application via its Service IP or ClusterIP.

Step 3: Access the internal application via Tailscale VPN

Invite the user you wish to grant access to your domain. Once the invitation is accepted, connect to the Tailscale VPN and set the exit node to your designated exit node VM.

To verify your configuration, follow these steps:

Before connecting to Tailscale: Check your current IP address by running the command:

curl ipconfig.me
bash

After connecting to Tailscale and setting the exit node: Run the same command again:

curl ipconfig.me
bash

Alternatively, you can use a website like WhatIsMyIP to check your IP address.

Once connected to Tailscale with the exit node set to your exit node VM, your IP address should match the IP address of the exit node VM. This confirms that your VPN connection is working correctly.

Now that you're connected to the VPN, you can access the domain associated with the ingress controller to reach your internal applications.

Final thoughts on implementing Zero trust security for Kubernetes

By securing your Kubernetes cluster endpoint and internal applications with Tailscale, you implement a Zero Trust Kubernetes security model that protects both infrastructure and services. This ensures that only authenticated and authorized users—verified through Tailscale’s secure VPN—can access sensitive Kubernetes API server resources and internal applications, regardless of location.

With Tailscale’s Kubernetes VPN security, organizations benefit from end-to-end encryption, auto-rotating private keys, and granular access controls via ACL policies. These features drastically reduce the attack surface, preventing unauthorized access and minimizing security risks. Furthermore, this flexible solution extends beyond a single cloud provider, allowing businesses to apply Zero Trust principles for Kubernetes security across multi-cloud and hybrid environments.

Implementing Zero Trust network security for Kubernetes is no longer optional—it’s a necessity for safeguarding containerized workloads, ensuring compliance with security frameworks like SOC 2, ISO 27001, and NIST CSF, and maintaining operational resilience.

Protect your Kubernetes clusters today.

Implement a Zero Trust Kubernetes security strategy that enhances protection, reduces complexity, and ensures compliance.

Enjoying this post?

Get our posts directly in your inbox.