this risks exposing secrets from the deployed manifests,
but those are currently deployed beforehand so we should
be good as long as kustomization.yaml does not contain
any.
* To do so, we need to ensure that the generated kubeconfig is part of
terraforms dependency graph. This has the additional benefit of not
depending on local files anymore which should enable multi-user
setups.
* This also means that we can't deploy CCM, CSI & Traefik from our local
host, because we don't have kubeconfig.yaml locally while provisioning
the control plane, only afterwards.
* So we just run kubectl apply on the control plane itself, after k3s is
ready.
* To do so, we need to deploy all manifests. I've merged the patches
into a single kustomization.yaml file, because that makes the
deployment of those files to the control-plane server easier.
* we could also put the traefik config into the same kustomization file,
which would save us one of the file provisioner blocks. I didn't want
this PR to get any bigger, and will consider merging this config later
on. kustomization.yaml is small enough that we could yamlencode() for
it and store the patches in separate files again, not as
inline-strings which is kind of ugly.
the current implementation works co-incidentally for most
setups, when terraform apply is run from the repos root,
but not when kube-hetzner is used as a terraform module
Newly added ssh commands were missing the flag -i to pass an
identity file. This means that those commands use different
settings then the provisioners and their connection blocks
around them.
While adding this parameter, I decided it would be cleanest
to add local.ssh_args.
Setting private_key to null uses the local ssh-agent as a fallback for
authentication. Using the public_key instead of the private_key for
ssh -i lets the agent select the right identity if loaded. tested
with a yubikey
