/

Securing Kubernetes API with Twingate

Securing Kubernetes API with Twingate

Keith Hubner

Jun 15, 2022

Introduction

Kubernetes goes a long way to solve many traditional application and architecture issues, but security must always be a consideration when dealing with public facing services. All too often the path of least resistance is taken to avoid the slow and painful network setup needed to secure services like the k8s API. Twingate looks to take away this pain by providing simple and secure access to your Kubernetes API and services running within your cluster.

Private clusters

Private clusters give you the option of limiting both inbound and outbound communications to and from your Kubernetes cluster by removing the exposure of the public API to the internet. It can be argued that there are other security measures that can be taken to safely expose the API, for example IP restrictions and also Kubernetes own RBAC security model. This is true, however the API is still public facing and still vulnerable to both accidental and malicious exposure. Removing the Kubernetes public API endpoint closes that link to the outside world completely.

This guide assumes you have a requirement to deploy Twingate outside of the Kubernetes cluster. Deploying Twingate inside Kubernetes is also an option you may want to consider and more information on how to do this via a helm chart can be found here.

Getting started

This guide assumes you have the following setup:

  • You have a current Twingate Account (the free tier of Twingate is perfectly suitable for this guide)

  • You have a current AKS / EKS / GKE private cluster setup and accessible via an alternative private connection

  • You have Azure CLI / AWS CLI / Google CLI installed

  • You have Kubectl installed

This guide doesn’t utilize advanced deployment techniques, for example via Terraform or Pulumi. If you are interested in deploying Twingate via Terraform please see the official Terraform provider guide here or for Pulumi please see the Pulumi Registry.

Firstly you must have a Twingate account, so head over here to sign up if you do not have one. You will also need to install the Twingate client from here.

Setting up your network

Login to your Twingate admin portal and click “Add‚ on the remote networks section:

twingate add network

Then select the location of AWS/Azure/Google Cloud, give it a name, and continue to relevant section below.

select remote network

Once you have setup your network(s), please follow the relevant guide below:

Deploying to Azure for Private AKS Access

Deploying to GCP for Private GKE Access

Deploying to AWS for Private EKS Access

Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.

/

Securing Kubernetes API with Twingate

Securing Kubernetes API with Twingate

Keith Hubner

Jun 15, 2022

Introduction

Kubernetes goes a long way to solve many traditional application and architecture issues, but security must always be a consideration when dealing with public facing services. All too often the path of least resistance is taken to avoid the slow and painful network setup needed to secure services like the k8s API. Twingate looks to take away this pain by providing simple and secure access to your Kubernetes API and services running within your cluster.

Private clusters

Private clusters give you the option of limiting both inbound and outbound communications to and from your Kubernetes cluster by removing the exposure of the public API to the internet. It can be argued that there are other security measures that can be taken to safely expose the API, for example IP restrictions and also Kubernetes own RBAC security model. This is true, however the API is still public facing and still vulnerable to both accidental and malicious exposure. Removing the Kubernetes public API endpoint closes that link to the outside world completely.

This guide assumes you have a requirement to deploy Twingate outside of the Kubernetes cluster. Deploying Twingate inside Kubernetes is also an option you may want to consider and more information on how to do this via a helm chart can be found here.

Getting started

This guide assumes you have the following setup:

  • You have a current Twingate Account (the free tier of Twingate is perfectly suitable for this guide)

  • You have a current AKS / EKS / GKE private cluster setup and accessible via an alternative private connection

  • You have Azure CLI / AWS CLI / Google CLI installed

  • You have Kubectl installed

This guide doesn’t utilize advanced deployment techniques, for example via Terraform or Pulumi. If you are interested in deploying Twingate via Terraform please see the official Terraform provider guide here or for Pulumi please see the Pulumi Registry.

Firstly you must have a Twingate account, so head over here to sign up if you do not have one. You will also need to install the Twingate client from here.

Setting up your network

Login to your Twingate admin portal and click “Add‚ on the remote networks section:

twingate add network

Then select the location of AWS/Azure/Google Cloud, give it a name, and continue to relevant section below.

select remote network

Once you have setup your network(s), please follow the relevant guide below:

Deploying to Azure for Private AKS Access

Deploying to GCP for Private GKE Access

Deploying to AWS for Private EKS Access

Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.

Securing Kubernetes API with Twingate

Keith Hubner

Jun 15, 2022

Introduction

Kubernetes goes a long way to solve many traditional application and architecture issues, but security must always be a consideration when dealing with public facing services. All too often the path of least resistance is taken to avoid the slow and painful network setup needed to secure services like the k8s API. Twingate looks to take away this pain by providing simple and secure access to your Kubernetes API and services running within your cluster.

Private clusters

Private clusters give you the option of limiting both inbound and outbound communications to and from your Kubernetes cluster by removing the exposure of the public API to the internet. It can be argued that there are other security measures that can be taken to safely expose the API, for example IP restrictions and also Kubernetes own RBAC security model. This is true, however the API is still public facing and still vulnerable to both accidental and malicious exposure. Removing the Kubernetes public API endpoint closes that link to the outside world completely.

This guide assumes you have a requirement to deploy Twingate outside of the Kubernetes cluster. Deploying Twingate inside Kubernetes is also an option you may want to consider and more information on how to do this via a helm chart can be found here.

Getting started

This guide assumes you have the following setup:

  • You have a current Twingate Account (the free tier of Twingate is perfectly suitable for this guide)

  • You have a current AKS / EKS / GKE private cluster setup and accessible via an alternative private connection

  • You have Azure CLI / AWS CLI / Google CLI installed

  • You have Kubectl installed

This guide doesn’t utilize advanced deployment techniques, for example via Terraform or Pulumi. If you are interested in deploying Twingate via Terraform please see the official Terraform provider guide here or for Pulumi please see the Pulumi Registry.

Firstly you must have a Twingate account, so head over here to sign up if you do not have one. You will also need to install the Twingate client from here.

Setting up your network

Login to your Twingate admin portal and click “Add‚ on the remote networks section:

twingate add network

Then select the location of AWS/Azure/Google Cloud, give it a name, and continue to relevant section below.

select remote network

Once you have setup your network(s), please follow the relevant guide below:

Deploying to Azure for Private AKS Access

Deploying to GCP for Private GKE Access

Deploying to AWS for Private EKS Access