Kubernetes: Best Practices

Twingate can be deployed in Google Kubernetes Engine (GKE), Amazon EKS, and similar Kubernetes and microK8s deployments to address the following use cases. Your intended use case will dictate the best way to deploy Twingate Connectors, as well as the way you'd want to structure Resource definition and Group membership.

The following use cases are covered below:

  1. Managing a Kubernetes cluster using kubectl
  2. Exposing a service in a Kubernetes cluster
  3. Providing access to a specific service in a Kubernetes cluster that isn't exposed

Notes on Connector deployment and Remote Network configuration:

  • A Remote Network in Twingate defines a logical set of Resources that are accessible from the Connectors deployed in that Remote Network. If you are deploying a Connector within a K8s cluster (eg. using Twingate's Helm Chart), it most likely makes sense to define a new Remote Network for Resource addresses that exist within your K8s cluster.
  • If you're deploying Connectors using Helm, you should periodically manually update the Twingate Helm Chart. Please note that upgrading a Connector does not automatically update the Helm Chart.
  • For use cases where only public K8s service access is required, Twingate Connectors can also be deployed on a Linux host using either Docker, or as a native systemd service.

See Connector best practices for more detailed information.

Securely manage a K8s cluster using kubectl

Use case: You'd like to use Twingate to manage services on a K8S Cluster using kubectl without exposing your cluster's API endpoint to the public Internet.

  1. Deploy Connector(s) outside the target K8s cluster. This Connector will be used to secure access to your cluster's API endpoint. The only requirement is that the Connector must have network access to the API endpoint. Neither the Connector nor the API endpoint should be accessible from the public Internet.
  2. Create a new Twingate Resource with the cluster's API endpoint address (eg. 10.1.1.15). This will allow kubectl to connect to the API endpoint while connected to Twingate.
  3. On your local machine where you are using kubectl, modify your kubectl configuration to connect to the API endpoint address you configured in the previous step. Although this address is not directly accessible from your local machine, while connected to Twingate, we will automatically proxy traffic to the API endpoint via the Connector you deployed in the first step.
# Example kubectl config command
# 10.1.1.15 is an example private K8s API endpoint defined as a Resource in Twingate

kubectl config set-cluster example-cluster --server=https://10.1.1.15

As long as you are connected to Twingate, and you are authorized to access to the K8s cluster's API endpoint Resource, you will be able to use kubectl to manage your K8s cluster securely without setting up a separate K8s proxy.

Access an exposed service on a K8s cluster

Use case: You'd like to provide external access to a service inside a K8s cluster but control that access using Twingate Resources and Group assignments.

  1. Deploy Connector(s) outside the target K8s cluster. This Connector will be used to secure access to your cluster's API endpoint. The only requirement is that the Connector must have network access to the API endpoint. Neither the Connector nor the API endpoint should be accessible from the public Internet.
  2. Configure an external IP address (external to the K8s cluster, but not public) for the K8s service. This address must be reachable from the Connector that you deployed in the previous step. You may want to use private DNS to provide access to the exposed service instead of the private IP address.
  3. Create a new Twingate Resource with the service's IP or private DNS address. This will allow authorized Twingate users to access the K8s service without exposing it on the public internet.

Access private services within a K8s cluster

Use case: You'd like to provide access to specific services within a K8s cluster.

  1. Deploy Connector(s) via Helm Chart inside your K8s cluster. The steps for deploying a Connector via Helm Chart are provided within the Connector provisioning flow in the Admin console.
  2. Create a new Twingate Resource with the internal service's IP or K8s cluster internal DNS address. This will allow authorized Twingate users to access the K8s service without exposing it on the public internet.
  3. Users granted access to the Twingate Resource you defined will now be able to access the service using its internal IP or K8s DNS name.

Did this page help you?