[Enhancement]: How To Bootstrap Flux with GitLab Deploy Tokens using Terrform

[satyamsareen007]

Description

Hi Team

Here PAT refers to Project Access Token.

A couple of questions.

1.)
There is no guide available on how to bootstrap flux with a GitLab deploy token using its terraform provider. What args would I need to set, to do so?

2.)
I also don't get why we are using 2 secrets, Gitlab PAT & Deploy Token/Key. If GitLab PAT can clone and push files to a project, what is the deploy token/key doing?

Are some of the API operations handled by PAT and others by deploy token/key ? Can you please explain how the bootstrapping is happening at a lower level and how these 2 secrets coming into the picture?

3.)
While going through the documentation. https://fluxcd.io/flux/installation/bootstrap/gitlab/#gitlab-deploy-keys.
It says "By default, the GitLab deploy key is set to read-only access. If you’re using Flux image automation, you must give it write access with --read-write-key=true." If the gitlab deploy key is read-only by default and if we are not using flux image automation, then what is the purpose of using a deploy key in the first place if GitLab PAT is able to perform both read & write to a project.

I kind of confused with the 2 secrets (PAT & deploy key/token). Which secret is handling what part of the bootstrapping process and why do we need both of them?

Affected Resource(s) and/or Data Source(s)

No response

Potential Terraform Configuration

No response

References

No response

Would you like to implement a fix?

None

[stefanprodan]

The PAT is used to perform Git push operations locally on the machine running the Terraform CLI. The deploy token is stored in a Kubernetes secret and is used by the Flux source-controller running in the cluster. If you have no security concerns around storing your PAT in the cluster (any user with access to flux-system ns can impersonate your identity), then you can use the PAT for Flux controllers too.

[satyamsareen007]

thanks stefan for quick reply,

makes sense around the security concern.

Another question, how does the flux provider use the PAT to push files to GitLab. In this example : https://github.com/fluxcd/terraform-provider-flux/blob/main/examples/gitlab-via-ssh/providers.tf.

We have just mentioned the deploy key in the flux provider. The PAT was given to the gitlab provider and not to the flux provider. So how does the flux bootstrap resource get hold of PAT when it has push files during first-time bootstrap or during upgrades?

---

And there are no guides provided for bootstrapping using deploy token in the tf docs. Can that be added.
For now, would the below sample test changes work for https bootstrapping using Gitlab deploy tokens :

resource "gitlab_deploy_token" "flux" {
  project    = "12345678"
  name       = "flux"
}

provider "flux" {
  kubernetes = {
    host                   = kind_cluster.this.endpoint
    client_certificate     = kind_cluster.this.client_certificate
    client_key             = kind_cluster.this.client_key
    cluster_ca_certificate = kind_cluster.this.cluster_ca_certificate
  }
  git = {
    url = "https://gitlab.com/${gitlab_project.this.path_with_namespace}.git"
    http = {
      username    = "git"
      password = gitlab_deploy_token.flux.token
    }
  }
}

[stefanprodan]

I'm not a GitLab user so I have no idea how their providers works, maybe @swade1987 knows.

[swade1987]

Hi, @satyamsareen007. Thanks for sharing your Terraform block above! Have you had a chance to test it out to see if it works as expected? Unfortunately, I don’t have a GitLab account to verify this, but I’d appreciate any insights you can provide from your testing.

[satyamsareen007]

Sure @swade1987, I'll keep you posted on how the testing goes,

in the meantime can you help with the other query I have added in my previous comment

adding it here as well

""
Another question, how does the flux provider use the PAT to push files to GitLab. In this example: https://github.com/fluxcd/terraform-provider-flux/blob/main/examples/gitlab-via-ssh/providers.tf.

We have just mentioned the deploy key in the flux provider. The PAT was given to the GitLab provider and not to the flux provider. So how does the flux bootstrap resource get hold of PAT when it has push files during first-time bootstrap or during upgrades?
""

Thanks!

[swade1987]

The flux provider uses whatever creds you provide in the "git" block of the specification to interact with git.

[satyamsareen007]

thanks @swade1987 for the reply,

I am kind of confused here,

as per @stefanprodan's reply, PAT is used to perform the git operations locally (I am assuming operations like pushing flux manifests to Gitlab, creating deploy key/deploy token, etc.) and the creds which we are passing in the flux provider (deploy key/deploy token) are used by the source controller to reconcile flux.

Now as per your response, Flux only uses creds that we pass in its provider block, so it wouldn't use PAT at all right, because PAT was provided to the GitLab provider and not to the flux provider. (https://github.com/fluxcd/terraform-provider-flux/blob/main/examples/gitlab-via-ssh/providers.tf.)

only deploy token/deploy key are being provided to the flux provider.

I can see the deploy key is to can_push=true, over here https://github.com/fluxcd/terraform-provider-flux/blob/main/examples/gitlab-via-ssh/main.tf#L56

so I think flux provider is getting the capability to push its manifest from the deploy key and not from the PAT, as PAT we didn't provide to the flux provider.

And following this logic, deploy tokens won't work with the flux provider right as they are always read-only and they won't be able to push flux manifests to a GitLab project.

If my understanding is correct, maybe this could be a new feature that can be introduced to the flux provider, as GitLab deploy tokens are supported in the flux cli