202510050106 A Necessary Boostrap
There is a chicken-egg problem.
For my Kubernetes cluster to reach my secrets manager infisical I require Tailscale to be set up. For tailscale-operator to be configured, I need to instantiate the secrets into the cluster, requiring the oauth credentials.
Typically, for most applications in the cluster, the secrets are stored externally in Infisical and synced via the secrets-operator. However, for my cluster to reach the infisical instance, which is self-hosted and behind a VPN, I need the cluster to have egress into and access to the private subnet.
Therefore, I cannot have the tailscale-operator retrieve the secret to configure tailscale-operator because the secret I need… requires the exact same secret to already exist.
So here’s a dilemma. I had thought a Kubernetes Auth solution might’ve worked. The goal was to have the cluster be able to authenticate and authorise between other services through its own Service Account and Cluster Role bindings. I guess not.
Solutions
I guess my most preferred solution is the simplest one: empty secret + manual patch. However, I think with FluxCD there is a potential that it might revert the changes as part of its reconciliation process is to ensure the state remains intact with the config.
So alternatively, I might want to look into Sealed Secrets
I charted out an image that hopefully might make sense, some way or another.