twingate / kubernetes-operator Goto Github PK

To make services accessible on K8S a Service object is used.
Rather than make user manually create an aditional TwingateResource to expose that service we can do that automatically.

Implementation details

• To expose a Service as a Twingate Resource, annotate it with twingate.com/expose value "true" (under its metadata.annotations)
• Operator will listen on annotated services and create a child TwingateResource object with address <service name>.<namespace>.svc.cluster.local

Questions

• What about other TwingateResource properties like isvisible, isBrowserShortcutEnabled and securityPolicyId ? Maybe the twingate.com/expose should actually be an object...
• What if you have the same service on multiple clusters? (prod\non prod) they will all get the same resource address...

Allow defining a TwingateConnector that'll

• Provision a connector via API - get access&refresh tokens
• Start a pod with said connector
• Monitor pod and allow auto updating it

This is a basic building block on top of which we could later define an object that creates multiple of these (like a Deployment with replicas prop)

Technical implementation

Proposal for CRD:

apiVersion: twingate.com/v1beta
kind: TwingateConnector
metadata:
  name: my-connector
spec:
  name: My K8S Connector
  imagePolicy:
    schedule: "0 2 * * *"
    version: 0.1.x
  containerExtra:
    resources:
      requests:
        cpu: 314m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 128Mi
  podExtra: {}

On create operator will:

1. Provision a connector and get tokens
2. Create a child Secret and Pod objects
3. Monitor pod and secret and not allow changing them
4. Create timers based on imagePolicy.check that will
5. Check for newer tag on docker hub (based on imagePolicy.version)
6. Patch the pod's image if a newer tag is detected

Right the remote network ID we run in integration tests is hardcoded.
This is a problem when multiple builds run in parallel.
We should change code to create a new network on the fly via API before starting the test run

What is missing?
In order to get principalId developer needs access to Twingate Admin which he, usually doesn't have.

Example:

apiVersion: twingate.com/v1beta
kind: TwingateResourceAccess
metadata:
  name: my-twingate-access
spec:
  resourceRef:
    name: my-twingate-resource
    namespace: default
  principalExternalRef:
    type: Group
    byName: "my group"

What is missing?
Ability to customize connector log level.
Right now it is hardcoded to 7 but should be able to override it via the TwingateConnector CRD

Why do we need it?
Not all environments need or want the full extent of logs

What is missing?
Ability to have a connector image auto-update from a GCP repository (Google Artifact Registry)

Why do we need it?
Certain customers proxy dockerhub through their GCP for security scanning etc.

What is missing?
values.yaml requires specifying the apiKey directly but for certain customers (dependin on how they manage secrets) it may be better to create the Secret object with the apiKey value themselves and point to it.

** Details **
Extend twingateOperator section in values.yaml to allow either specifying an apiKey value or existingAPIKeySecret:
Example:

twingateOperator:
  network: "acme"
  remoteNetworkId: "123"
  existingAPIKeySecret:
    name: my-secret-object
    key: twingate-api-key

Example for reference:
https://github.com/prometheus-operator/prometheus-operator/tree/main/.github/ISSUE_TEMPLATE

Run a daily job that checks docker scout cves twingate/kubernetes-operator:dev --only-fixed and alerts (Slack?) on fixable vulnerabilities