I use practical security measures that match my level of exposure and don’t severely limit my convienience.
If your lab isn’t exposed directly to the internet, at the very least update your servers from time to time, use a string root (admin users as well) password. That’s more than enough.
If your lab is exposed, the same applies but update more often. Use SSH keys.
Don’t go overboard - the majority of security incidents are from lack of basic security
Automating router/networking configs is a whole thing in itself, it’s mainly done in Python though. Like Netmiko, Genie, or Ansible (which is a wrapper around those packages).
Most routers don’t have their own scripting language either. Most solutions are creating SSH tunnels and then running network commands.
It’s also mostly stateless and not idempotent. Which is why you aren’t going to find many routers that have good terraform support, it’s stateful. (How do you reverse commands in a way that doesn’t destroy the router?)
Either way, if it has an API you can always write your own GO Rest Client and create a Terraform module.
But your best bet is to go with the Python solutions, since most our vendor supported.
I will say that I have automated a K3s cluster including the networking with Vyos Cloud-Init capabilities in Proxmox, using Terraform. BGP was used upstream to make routing dynamic
Just be careful how much you depend on the git repo for Flux.
I made the mistake of doing the same thing but took it a two further and used Gitea for my container images and helm charts. When I messed up Gitea during an ArgoCD sync, I couldn’t roll back because the custom helm chart for Gitea and Postgres came from Gitea.
It also messed up every other application and ended up deleting all my resources during auto sync.
Best thing I ended up doing was mirroring Gitea to GitHub, including images and charts. Then using that for ArgoCD.