Getting Started

The Twingate Operator's goal is to make exposing services running on Kubernetes via Twingate as easy as possible.

This guide will show you how to deploy the Twingate Operator and define your first TwingateResource.

Pre-requisites

To follow this guide, you will need a Kubernetes cluster with admin permissions.

Installing the Operator

1. Go to your Twingate Admin console at http://<network slug>.twingate.com/:
   1. Create a new Remote Network that'll represent your Kubernetes Cluster.
   2. Create a new API key with "Read, Write, & Provision" permissions.
2. Clone the operator's repository to get its Helm chart:

git clone https://github.com/Twingate/kubernetes-operator.git

2. Change directory into the repository's folder
3. Create a values.yaml with the following values:

twingateOperator:
  apiKey: "<the api key from step1>"
  network: "<network slug>"
  remoteNetworkId: "<the id of the remote network from step 1>"
  logFormat: "plain|full|json"

(You can look at ./deploy/twingate-operator/values.yaml at the full list of configuration values) 4. Install the operator using Helm (add -n [namespace] if you want to install to a specific namespace):

helm upgrade tw-op ./deploy/twingate-operator --install --wait -f ./deploy/twingate-operator/values.local.yaml

xhe Twingate Operator introduces new custom resources definitions (CRDs) to Kubernetes to allow declaring various Twingate related settings as Kubernetes objects and have their settings sync to Twingate. You can see the full references for these CRDs at the API Reference. For this guide the CRDs of interest are:

• TwingateConnector
• TwingateResource
• TwingateResourceAccess

Deploy a Connector to connect your cluster to Twingate

In order to start exposing resources on your cluster via Twingate, you first need to run a Twingate Connector on your cluster. To do that we simple need to define a TwingateConnector resource:

apiVersion: twingate.com/v1beta
kind: TwingateConnector
metadata:
  name: my-connector
spec:
  imagePolicy:
    schedule: "0 0 * * *"

This will have the operator provision a new connector and deploy it to the cluster. Also notice that we've given our connector and imagePolicy that'll check and auto-update it if necessary every day at 00:00.

Defining your first Twingate Resource

Lets assume you have an existing Kubernetes Service called foo and you want to allow accessing it via Twingate. The service's internal DNS name would be - foo.default.svc.cluster.info. Lets define a TwingateResource that'll define a Twingate Resource for our foo service:

apiVersion: twingate.com/v1beta
kind: TwingateResource
metadata:
  name: foo
spec:
  name: Foo
  address: foo.default.cluster.local
  alias: foo.local

Now, lets also configure who can access this resource using TwingateResourceAccess. TwingateResourceAccess expects a principalId which is an ID for a Group\Service-Account that we want to give access to this resource to. Lets assume we have a Devops group with ID R3JvdXA6MTE1NzI2MA== that we want to allow accessing this resource via a specific resource policy:

apiVersion: twingate.com/v1beta
kind: TwingateResourceAccess
metadata:
  name: foo-devops-access
spec:
  resourceRef:
    name: foo
    namespace: default
  principalId: R3JvdXA6MTE1NzI2MA==
  securityPolicyId: U2VjdXJpdHlQb2xpY3k6MTc0NTc=