Beyond VPNs: How Modern Teams Secure Access to Cloud Environments, Kubernetes Clusters

A VPN, or Virtual Private Network, is like a secret tunnel on the internet. When you use a VPN, it creates a private path for your online activities, keeping them hidden from others. It's similar to sending your internet traffic through a private tunnel instead of a busy public highway. This helps keep your information safe from people who might want to peek at what you're doing online, like hackers or advertisers.

VPNs are essential for securing remote access and protecting data in transit, especially in cloud-first environments where DevOps and IT professionals focus on remote operations and cloud services. Implementing an effective VPN allows your team to improve security, enforce compliance, and maintain high performance across dispersed architectures, making it a crucial component of a modern, scalable, and secure infrastructure. In this blog, I cover the challenges associated with traditional VPNs and demonstrate how Twingate is revolutionizing remote access for organizations, offering enhanced security and efficiency.

Setbacks in VPN-Enabled Environments

While VPNs are helpful for creating secure connections to private networks, they often come with challenges:

1. Performance Issues: VPNs can slow down internet speeds because all traffic must be encrypted and sent through a VPN server before reaching its destination. This additional routing can lead to latency and reduced bandwidth, which is problematic for activities like streaming videos or transferring large files.

2. Complex Setup and Management: Setting up a VPN for enterprises is a daunting task and requires deep technical knowledge. This includes setting up secure connections, managing server configurations, and ensuring compatibility with various devices and operating systems.

3. Scalability Issues: As organizations grow, scaling a VPN to accommodate more users and higher traffic can become challenging. More resources and better infrastructure are needed, which can be costly and difficult to manage.

4. Security Risks: While VPNs are designed to secure data, they can sometimes become targets for cyberattacks. Misconfigurations, outdated software, or flaws in the VPN protocol can expose the network to security risks. Once a user is authenticated, VPNs often provide broad access to the network, increasing the risk of a security breach.

5. Limited User Access Controls: Traditional VPNs typically do not offer granular access controls. Once users are connected, they often have access to more information than necessary, which can pose a risk if those credentials are compromised.

Introducing Twingate

Twingate is a modern zero-trust network access solution that offers smooth and secure resource access over various networks. Unlike traditional VPNs, Twingate focuses on fine-grained access control, ensuring that only authenticated users can connect to specific resources without exposing the entire network. Twingate is an efficient and user-friendly solution for secure remote access, allowing users to access resources by their Fully Qualified Domain Name (FQDN) or IP address without needing to know the underlying network setups. Twingate enables access to infrastructure without requiring it to be publicly exposed on the internet via a jump server, Bastion host, or other endpoints. It also allows for easy access to multiple clouds or environments (e.g., staging) simultaneously.

Architecture of Twingate

Twingate's architecture emphasizes security, with multiple components working together before allowing any data flow. This minimizes the risk of unauthorized access. Four main components provide secure and encrypted communication: Controller, Client, Connector, and Relay. These components ensure that only authenticated and authorized users can access the resources they are permitted to access.

Securing Resources Using Twingate

In this demo, I will cover three important use cases of Twingate as a secure layer for accessing your private resources.

Use Case 1: Secure Kubernetes with Twingate

Step 1: Create a Kubernetes Cluster

To secure access to our Kubernetes applications, we need to spin up a cluster where our applications will run. Follow the Civo Documentation to create a Kubernetes cluster.

NOTE: Make sure to select Helm from the Civo Marketplace while configuring your cluster.

REASON: We will use the Helm chart method to access resources from the Kubernetes cluster.

Step 2: Create NGINX Deployment and Service

To run a private resource in our newly created Kubernetes cluster on Civo, we need deployment and service configuration files.

Deployment File: nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Service File: nginx-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

To keep the access to NGINX limited to our cluster and not accessible from outside, we will set the service type to ClusterIP.

Once both files are saved, apply these configurations to your Civo Kubernetes cluster using the following commands:

kubectl apply -f nginx.yaml
kubectl apply -f nginx-svc.yaml

You will see the following output after running the above commands:

deployment.apps/nginx-deployment created
service/nginx-service created

You can also verify the deployment creation using the following command:

kubectl get deployments

Output:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           2m24s

Verify the service creation using the following command:

kubectl get services

Output:

NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes      ClusterIP   10.43.0.1      <none>        443/TCP   8m59s
nginx-service   ClusterIP   10.43.216.34   <none>        80/TCP    3m46s

Since this service is not accessible outside our Kubernetes cluster, we will need to install a Twingate connector in our cluster. You can verify this by trying to access the service by copying the CLUSTER-IP of nginx-service and pasting it into your browser.

Step 3: Deploy Twingate Connector Using Helm

For this step, ensure you have completed the Twingate Account Setup. Once your Twingate account is configured, head over to Networks and create a new remote network as shown below:

You can either configure an already created connector or deploy/add a new connector. Make sure to choose Helm from the deployment configuration list and click on the "Generate Tokens" button.

Once the tokens are generated, copy the Helm commands and paste them into your Kubernetes cluster environment.

This step will add a Twingate Helm chart and create a Helm repo in your Kubernetes cluster. Once the repo is created, run the second command to deploy the Twingate connector.

Note: Don't directly copy commands from the blog; they may not align with the dashboard.

Commands:

helm repo add twingate https://twingate.github.io/helm-charts
helm upgrade --install twingate-prompt-hedgehog twingate/connector -n default --set connector.network="<network-name>" --set connector.accessToken="<access-token>" --set connector.refreshToken="<refresh-token>"

Output:

Release "twingate-prompt-hedgehog" does not exist. Installing it now.
NAME: twingate-prompt-hedgehog
LAST DEPLOYED: Tue Aug 20 16:05:15 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

Once the connector is deployed, you will see it online in your Twingate network.

Step 4: Create a Resource on Twingate

Create a resource on Twingate and add it to your remote network. Copy and paste the CLUSTER-IP of your nginx-service while creating this resource.

You can create teams, add users, and assign roles to provide access to resources. In this scenario, I will provide access to everyone.

Step 5: Accessing the Resource

After completing the above steps, download and install the Twingate app on the device you want to use to access the running resource. Authenticate the app with your account, and you will be able to see the resource running through the app.

Copy your NGINX service's CLUSTER-IP and paste it into your browser to access the running resource.

Use Case 2: Securing Access to GitHub

For this section, we will use GitHub Actions to provide secure access to Twingate resources.

Step 1: Creating a Workflow for GitHub Actions

Ensure you have a GitHub Repository with a .github/workflows directory. Create a new YAML file with the following configurations inside the .github/workflows directory to trigger a new GitHub Action.

name: Twingate on GitHub Actions Demo
on: [push]
jobs:
  Twingate-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - name: Install Twingate
        run: |
          echo "deb [trusted=yes] https://packages.twingate.com/apt/ /" | sudo tee /etc/apt/sources.list.d/twingate.list
          sudo apt update -yq
          sudo apt install -yq twingate

      - name: Setup and start Twingate
        env:
          TWINGATE_SERVICE_KEY: ${{ secrets.SERVICE_KEY }}
        run: |
          echo $TWINGATE_SERVICE_KEY | sudo twingate setup --headless=-
          sudo twingate start

      - name: (optional) Twingate status
        run: twingate status

      - name: (optional) Twingate logs
        run: journalctl -u twingate

      - name: Access a secure resource
        env:
          TEST_URL: <URL-of-secure-resource>
        run: |
          echo Calling $TEST_URL 🚀
          curl $TEST_URL

      - name: Access a public resource
        env:
          TEST_URL: https://www.twingate.com/
        run: |
          echo Calling $TEST_URL 🚀
          curl -v $TEST_URL

      - run: echo "SUCCESS!!! 🤩 This job's status is ${{ job.status }}."

      - name: Stop Twingate
        run: sudo twingate stop

In this scenario, we will try to access the previously created nginx-service. Replace the value of TEST_URL under the Access a secure resource section with the address of your Twingate resource, such as http://10.43.12.110:80/.

Step 2: Setting up a Service Account

Learn more about Twingate service accounts here. To access the secure resource using GitHub Actions, you need to create a service account on Twingate and add the resource to it.

Head back to Twingate, and under the Team section, you will see the Services option. Create a service account.

Once the service account is created, generate a service key.

Download and copy the service key.

Add the resources you want to access using this service account.

Step 3: Accessing the Resource

To access the resource using GitHub Actions, set up the service key created as a secret in your GitHub repository using this guide. Name the key SERVICE_KEY when creating a secret in the GitHub repository.

Once all the above steps are correctly configured, you will be able to access the resource every time your GitHub Action pipeline triggers an update in your repository. You can check your workflow logs by visiting the Actions tab in the GitHub repository's navbar.

In this scenario, we were running NGINX as a resource and got the following output. However, outputs may differ based on the application running on the Twingate resource.

Use Case 3: Secure Cloud Environments

In this section, we will explore how to secure connections to cloud environments using Twingate. We will create two EC2 Instances under one VPC. One instance will be publicly accessible, while the other will be a private instance.

Step 1: Create a VPC

Ensure you have the following configurations in your VPC:

• Public and Private Subnets

• Route Tables for both public and private subnets

• Internet Gateway and NAT Configured

Step 2: Create EC2 Instances

For the first instance, name it twingate-connector (public instance) and choose a base Linux image. For this scenario, I used Ubuntu as the base Linux image. Edit the network settings before launching the instance, and your network settings should look similar to the image below:

• Choose the VPC created in the previous step

• Choose the public subnet for this instance

• Enable the auto-assign IP feature

• Create a new security group, or use an existing one

Configuration of twingate-connector:

For the second instance, name it private-instance and choose a base Linux image (I used Ubuntu for this scenario). Edit the network settings before launching the instance, and your network settings should look similar to the image below:

• Choose the VPC created in the previous step

• Choose the private subnet for this instance

• Disable the auto-assign IP feature

• Choose the security group created above

Configuration of private-instance:

Step 3: Deploy the Twingate Connector

Now, if you SSH into the twingate-connector instance using the key pair created for the instances, you won't get any errors. However, if you try to SSH into the private instance, you will encounter connection errors. We can manage access to the private instance using the Twingate connector and also secure this connection.

Head over to the Twingate network you created and create a new remote network:

Choose Linux from the deployment types in the connector under the newly created remote network and click the "Generate Tokens" button.

SSH into the twingate-connector instance using the following command:

ssh -i "<key-pair-path>" ubuntu@ec2-<public-ip>.compute-1.amazonaws.com

Example:

ssh -i twingate-demo.pem ubuntu@ec2-54-210-165-102.compute-1.amazonaws.com

Once inside the twingate-connector instance, copy the command from the Linux connector and run it to deploy the connector and establish the connection.

Command:

curl "https://binaries.twingate.com/connector/setup.sh" | sudo TWINGATE_ACCESS_TOKEN="<access-token>" TWINGATE_REFRESH_TOKEN="<refresh-token>" TWINGATE_NETWORK="<network-name>" TWINGATE_LABEL_DEPLOYED_BY="linux" bash

Head back to Twingate, and you will see that the connector is online.

Step 4: Add the Private Instance to Access via Twingate

Create a resource on Twingate and paste the Private-IP of the private instance into this resource.

You will see that the resource is online. Open the Twingate app, and you will now be able to SSH into the private instance.

You can now securely run any desired application on this private instance.

To establish a connection over multiple VPCs using the same network, repeat the steps above.

Key Features of Twingate

Twingate offers various features designed to enhance network security, ease of use, and performance:

1. Zero Trust Network Access:

Twingate focuses on fine-grained access control, ensuring that users can only access the resources they are authorized to use, rather than providing broad network access. 2. Integration with Identity Providers: Twingate supports user authentication with external identity providers like Okta, Azure AD, or Google Workspace, enhancing security by separating authentication from the network. 3. Ease of Deployment and Scalability: The controller is hosted and managed by Twingate, providing redundancy and high availability. Twingate works without requiring changes to existing network configurations, making it easy to deploy and scale across different environments. 4. Decentralized Architecture: Twingate's decentralized architecture ensures security by dividing responsibilities among the four components. The controller manages access policies and authenticates users, the client handles authentication, authorization, and network routing, the connector forwards traffic to local resources, and the relay sets up connections between clients and connectors when direct peer-to-peer connections cannot be established. 5. End-to-End Encryption: All traffic between the client and connector is encrypted using certificate-pinned TLS tunnels, ensuring data integrity and confidentiality.

Why Businesses Are Switching to Twingate

As cybersecurity threats increase and remote work becomes more common, organizations seek more secure ways to manage network access. Twingate is becoming a preferred choice due to its innovative approach to remote access. Here are some key reasons why businesses are making the switch:

1. Enhanced Security with the Zero Trust Model: Twingate operates on the zero trust model, ensuring that only authenticated and authorized users can access specific applications or services, reducing the risk of cyberattacks.

2. Improved User Experience: Twingate runs in the background, streamlining the user experience. Unlike other VPNs, which require manual connection and disconnection, Twingate automates the process and provides a more stable connection.

3. Simplified Management and Scalability: Traditional VPNs are complex to manage, involving intricate infrastructure setup and frequent maintenance. Twingate simplifies configuration and monitoring, allowing IT teams to focus on other business areas. Twingate's cloud-native nature also enables it to scale as the organization grows, accommodating an increasing number of users and workloads without additional infrastructure.

4. Reduced Costs: Twingate can reduce operational costs by eliminating the need for costly hardware deployments and reducing the workload on IT teams.

5. Global Accessibility: For organizations with a global workforce, Twingate's network optimization techniques ensure consistent and reliable access worldwide.

Use Cases

Twingate offers several use cases, but here are three key ones:

1. Remote Work Access: Twingate enables employees to securely access company resources from anywhere, ensuring a seamless remote work experience.

2. Secure Third-Party Access: Businesses often need to grant access to external parties, such as contractors or partners, to specific parts of their network. Twingate's granular access control allows organizations to provide only the necessary resource access without exposing the entire network, enhancing security and control.

3. Development and IT Operations: Twingate supports DevOps practices by providing developers and IT teams with secure access to development environments, servers, and databases without exposing them to the public internet. Its compatibility with automation tools like Terraform and Pulumi, along with advanced configuration capabilities through CLI tools, makes it an ideal choice for agile and secure software development.

Differences Between Twingate and Traditional VPNs

1. Direct Peer-to-Peer (P2P) Connections: P2P direct connections offer faster performance and greater reliability than traditional VPNs.

2. Private Proxy Architecture: Unlike traditional VPNs, which require time and cost to set up, Twingate's private proxy architecture acts as a bridge between clients and network resources, simplifying deployment and offering flexibility.

3. API-First Design: Traditional network security tools often lack comprehensive API support, limiting automation and integration capabilities. In contrast, Twingate's API-first design prioritizes using APIs to manage network access and security settings, enabling powerful automation.

4. Streamlined Zero-Trust: Traditional security models require extensive setup by IT teams, while Twingate is accessible to all key stakeholders in a zero-trust project: IT, security, developers/DevOps, and end users. Twingate facilitates secure application access and development processes without interfering with productivity. End users benefit from a seamless connection experience that requires minimal interaction.

Ideal Market for Twingate

Twingate is designed to cater to various audiences, offering secure and efficient remote access solutions:

• Remote and Hybrid Workforces: Enables secure access to corporate resources from any location.

• IT and Cybersecurity Teams: Enhances network security with a zero-trust architecture.

• Healthcare Providers: Ensures compliance with privacy regulations like HIPAA.

• Financial Services: Manages sensitive financial data securely, aiding in regulatory compliance.

• Educational Institutions: Supports remote access to educational materials and administrative systems.

• Legal and Consulting Firms: Provides secure access to sensitive client data and communications.

• Technology Startups and SMEs: Offers scalable and easy deployment for growing businesses.

• Government Agencies: Improves cybersecurity while enabling secure remote operations.

Getting Started with Twingate

Starting with Twingate is easy, and it's free for small teams or testing it out. You can use it for up to 5 users without paying anything. Here’s how to get started:

1. Sign Up: Go to the Twingate website, choose the free plan, and sign up.

2. Install: Follow the simple steps to get Twingate set up on your devices.

3. Set Up: Adjust the settings to suit your team's needs.

4. Connect: Link Twingate with other tools you use. You can find the tools it works with here.

5. Try It Out: Start using Twingate with your team and see how it works for you.

Conclusion

As projects, organizations, and businesses increasingly move towards remote work, traditional VPNs present challenges like performance, security, and scalability that hinder productivity. To enhance productivity and enable secure remote network access, Twingate's architecture and features—such as direct P2P connections, private proxy architecture, API-first design, and user-friendly approach—provide the scalability and security needed in a modern work environment.

Shoutout to Twingate for collaborating with me on this blog.