Questions regarding how to setup FluxCD on a GKE cluster created via fabric-fast modules

[Ferdinanddb]

Hi,

First, thanks for all the great work on this repo! I'm actively using the fabric-fast modules to create my GKE cluster (standard + nodepools) among many other gcp resources, and am very happy with it.

For now, I did the FluxCD setup to connect to my GKE cluster and my Gitlab instance manually, but I would now like to automate this using the FluxCD Terraform/Tofu provider.

My core question is about the recommended way to provision everything (GKE resources + FluxCD bootstrap/setup) from scratch.

1. Is it possible to do this in a single tofu apply? My concern is a potential cyclic dependency, as the Flux provider needs GKE credentials (kubeconfig) before the cluster is created, which would likely cause the tofu plan to fail.

2. Or, is a sequential approach the recommended way? For example:

• Apply 1 (Project 1): Create the GKE cluster and Git repo credentials (PAT).
• Apply 2 (Project 2): Use the outputs from Project 1 (kubeconfig + PAT) to configure the Flux provider and bootstrap the cluster.

My main concern with this approach is the kubeconfig. If I only run the Project 2 plan + apply later, isn't it likely that the kubeconfig output from Project 1 will have expired? How is this scenario typically handled?

3. Finally, what is the most secure way to handle the Git PAT?

• Is it safe to create the PAT via Tofu and have it in the state file (assuming the state is properly secured)?
• Or, given that I have an external vault where I can store credentials, could it be an option to create credentials using Tofu and persist them in the vault instead of the .tf state file?

Thanks a lot for any guidance you can provide!

[juliocc]

We don't have any recommendation, but I can tell you that in the past we had end-to-end GKE examples showing how to deploy specific applications in GKE (from no cluster all the way to a fully-deployed workload), and we used approach 2.

I don't know if things have changed in recent versions, but up until last year, it wasn't possible to configure a provider with a dynamic value. Terraform's documentation still mentions this:

You can use expressions to configure provider arguments, but you can only reference values that Terraform knows before it applies your configuration. You can reference input variables and arguments that you specify directly in your configuration, but you cannot reference computed resource attributes, such as google.web.public_ip.

I don't know about OpenTofu, but it seem approach 1 is still not possible in Terraform-land.