Installing Tailscale Operator on OpenShift 4.19.2

I decided to try out tailscale operator on OpenShift 4.19.2 this weekend. It recently went GA (April 2025) and Tailscale Operator fitted perfectly to my use case to expose apps over HTTPS and offload TLS cert management to TLS. You can read more about tailscale operator from their blog. I won’t be typing step by step of the installation documentation, but what you’ll see below are my use cases and the steps I took to get there to get it working on OpenShift. The installation is fairly straight forward.

I wanted the following use cases:

Utilise my github IDP
Access internal applications/services over tailscale with HTTPS
Access OpenShift via tailscale hostname:443
Follow my current ACL that restricts OpenShift from accessing the other sites/networks

I also personally didn’t want to maintain my own CA, and in most of my current container services, these has been offloaded to letsencrypt/cloudflare. This blog post isn’t about TLS/SSL termination nor cert management, but it should help someone who wants to install tailscale operator on OpenShift and the missing parts (scc) which you need to enable.

The installation uses helm to get an operator up and working,

Their instructions are perfect. And there are After creating oauth client on tailscale admin portal, replace the clientId and clientSecret accordingly. If you noticed the noauth in the variables, that’s meant to apply to deployment’s APISERVER_PROXY value, and allow me to retain github as my IDP.

helm upgrade \
  --install \
  tailscale-operator \
  tailscale/tailscale-operator \
  --namespace=tailscale \
  --create-namespace \
  --set-string oauth.clientId="XXXXX" \
  --set-string oauth.clientSecret="XXXXX" \
  --set-string apiServerProxyConfig.mode="noauth" \
  --wait

Release "tailscale-operator" does not exist. Installing it now.
NAME: tailscale-operator
LAST DEPLOYED: Sun Jul 13 01:02:44 2025
NAMESPACE: tailscale
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
You have successfully installed the Tailscale Kubernetes Operator!

Once connected, the operator should appear as a device within the Tailscale admin console:
https://login.tailscale.com/admin/machines

If you have not used the Tailscale operator before, here are some examples to try out:

* Private Kubernetes API access and authorization using the API server proxy
  https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy

* Private access to cluster Services using an ingress proxy
  https://tailscale.com/kb/1439/kubernetes-operator-cluster-ingress

* Private access to the cluster's available subnets using a subnet router
  https://tailscale.com/kb/1441/kubernetes-operator-connector

You can also explore the CRDs, operator, and associated resources within the tailscale namespace:

$ kubectl explain connector
$ kubectl explain proxygroup
$ kubectl explain proxyclass
$ kubectl explain recorder
$ kubectl explain dnsconfig

If you're interested to explore what resources were created:

$ kubectl --namespace=tailscale get all -l app.kubernetes.io/managed-by=Helm

However, by simply installing the helm release, your pod is going to encounter CrashLoopBackOff caused by default SecurityContextConstraints. To help someone new who just simply wants to skip through all the details, and get tailscale operator running, you need to create a policy which is added to the service account (operator) on the tailscale namespace. See the command below.

oc adm policy add-scc-to-user anyuid -z operator -n tailscale

Once you have executed this, delete the pod and wait for the new container to be spun up. It takes less than a minute. Enter the pod logs and you should see the following in my screenshot:

I might create another post infuture on exposing k8s cluster workload to your tailnet, but this is pretty straight forward after you have gotten your Tailscale Operator up. See the extract from their blog below.

You can use the Tailscale Kubernetes operator to expose a Kubernetes cluster workload to your tailnet in three ways:

Create a LoadBalancer type Service with the tailscale loadBalancerClass that fronts your workload.
Annotate an existing Service that fronts your workload.
Create an Ingress resource fronting a Service or Services for the workloads you wish to expose.

Anyway, that’s all that you need! If you need help, feel free to reach out to me or comment in this blog.

Cheers!

Leave a Reply Cancel reply