Support Flux Bootstrap or Deploy key creation

Question

Support Flux Bootstrap or Deploy key creation

ChrisJBurns opened this issue 2 years ago · comments

Is your feature request related to a problem ?

Currently, after #102 was merged, it is now possible to allow the flux-sync helm chart create (using the flux-cli) the SSH keys that would be used to push and pull to Git. However, for use in Crossplane (where I am using it), there is no way of getting the identity.pub where I can pass it to a Gitlab provider to create the Deploy key.

Describe the solution you'd like.

In spirit of "if you don't ask you don't get" (although in this case, I think I know what the answer is), do people feel it would be possible to create another wrapper around the flux-cli where it only creates the deploy key to gitlab / github based on the SSH keys it created previously? Currently, reading the docs, it doesn't seem that there is a dedicated command on the flux-cli and only possible via the flux bootstrap command?, but wondering if there was another way someone felt this would be possible? This would reduce complexity in the flavours of Crossplane compositions (see below) that attempts to install Flux, and the SSH keys and create the DK in the relevant Git repository. Instead, there would only need to be a flux-install and a flux-sync step, and no others.

Describe alternatives you've considered.

Several flavours in Crossplane

Key creation via Terraform:

Create keys using TLS terraform provider inside the Terraform Crossplane provider where the keys are output to a connectionDetailsSecret
Try to reference the keys created via Terraform, in the flux-sync resource - but not possible to do yet as connectionDetailsSecret aren't referenceable in Crossplane resources yet. crossplane/crossplane#2772
Downsides:
- The known hosts have to be provided manually

Let flux-sync create the SSH keys

Use the flux-sync Chart to create the keys and known_hosts in remote cluster
Use K8s crossplane provider to retrieve the identity.pub from remote cluster and share it with a Gitlab crossplane provider in order to create the deploy key
Downsides
- Current implementation of K8s provider does not allow for access of Objects from remote clusters crossplane-contrib/provider-kubernetes#41
Current implementation of Gitlab providers doesn't allow for DK's to be created crossplane-contrib/provider-gitlab#13

Additional context.

No response

Surya · Answer 1 · Thu Jun 02 2022 16:49:38 GMT+0800 (China Standard Time)

there is no way of getting the identity.pub

Flux creates a secret with the below details

Data
====
identity:      
identity.pub:  
known_hosts:

You can look into the secret that is base64 encoded. You can then decode it to get these details.

Hope this helps

Chris Burns · Answer 2 · Fri Jun 03 2022 00:51:11 GMT+0800 (China Standard Time)

Hi @suryapandian that's correct, although you need to retrieve them by another means. This issue is around possibly implementing functionality into the Helm chart that calls the fluxcli that does the creation of the deploy keys.

Stefan Prodan · Answer 3 · Fri Jun 03 2022 01:00:52 GMT+0800 (China Standard Time)

I would close this as wantfix. The whole idea of flux bootstrap github is that the PAT never leaves your local machine, the CLI talks to the GitHub API, while the cluster only has the SSH key. If you need to write the deploy key from the cluster to GitHub then you need a GitHub PAT with admin access to the repo as a secret in Kubernetes, which makes the whole thing pointless, if you have a PAT, then use that for Flux instead of a deploy key and you don't need to talk to GitHub API at all.

Chris Burns · Answer 4 · Fri Jun 03 2022 01:02:55 GMT+0800 (China Standard Time)

Shall close

Chris Burns · Answer 5 · Fri Jun 03 2022 01:04:12 GMT+0800 (China Standard Time)

I will also add, the 2nd point(Let flux-sync create the SSH keys) in my original post actually works now. So this ticket isn't needed anymore.

Surya · Answer 6 · Fri Jun 03 2022 01:08:33 GMT+0800 (China Standard Time)

Hi @suryapandian that's correct, although you need to retrieve them by another means. This issue is around possibly implementing functionality into the Helm chart that calls the fluxcli that does the creation of the deploy keys.

What do you mean by "retrieve them by another means"? The current version of helm chart already creates deploy keys 🤔

Chris Burns · Answer 7 · Fri Jun 03 2022 01:10:47 GMT+0800 (China Standard Time)

I don't think it does, it creates the SSH keys and puts them in the Cluster, but an additional task is needed to be performed by the engineer to ensure the Gitlab / Github Deploy Key is created with the publicKey created via Flux. In our case, we have Crossplane composition resources to do this.

Surya · Answer 8 · Fri Jun 03 2022 01:14:14 GMT+0800 (China Standard Time)

I don't think it does, it creates the SSH keys and puts them in the Cluster, but an additional task is needed to be performed by the engineer to ensure the Gitlab / Github Deploy Key is created with the publicKey created via Flux. In our case, we have Crossplane composition resources to do this.

Yes, that is true. We were thinking of writing a k8s job that goes through the logs that prints the publicKey and upload it to the Github/Gitlab. And yes, that would need a PAT. But perhaps instead of providing the PAT as a value in values.yaml, we can point to a secretRef that has the PAT. That way the PAT is not explicitly committed anywhere.

Surya · Answer 9 · Fri Jun 03 2022 01:22:49 GMT+0800 (China Standard Time)

I would close this as wantfix. The whole idea of flux bootstrap github is that the PAT never leaves your local machine, the CLI talks to the GitHub API, while the cluster only has the SSH key. If you need to write the deploy key from the cluster to GitHub then you need a GitHub PAT with admin access to the repo as a secret in Kubernetes, which makes the whole thing pointless, if you have a PAT, then use that for Flux instead of a deploy key and you don't need to talk to GitHub API at all.

For bootstrapping from "local" machines it is okay to expose PAT. However, for automating bootstrap process across various clusters in an organization adding PAT in values.yaml is not a good idea.

We should have a mechanism where PAT is not explicitly added to values.yaml but the helm chart is still able to create a helm release of flux that is able to sync from Github/Gitlab.

Chris Burns · Answer 10 · Fri Jun 03 2022 01:25:30 GMT+0800 (China Standard Time)

@suryapandian It depends how you're installing Flux. If you're using the flux2-install and flux2-sync, they will install Flux and create the SSH keys. But if you're running this installation of Flux via Crossplane, the linked issue above will show you how you can configure Gitlab Deploy Key. If you're running the Helm charts from Terraform, again, you can also use the Gitlab provider to create the Deploy Key.

Surya · Answer 11 · Fri Jun 03 2022 01:31:45 GMT+0800 (China Standard Time)

@suryapandian It depends how you're installing Flux. If you're using the flux2-install and flux2-sync, they will install Flux and create the SSH keys. But if you're running this installation of Flux via Crossplane, the linked issue above will show you how you can configure Gitlab Deploy Key. If you're running the Helm charts from Terraform, again, you can also use the Gitlab provider to create the Deploy Key.

hmm we use Github, Tf. Creation of deploy key has not been a problem for us. Uploading the deploy key to GH is kind of a sore spot at the moment. We are looking at clean ways to do this.

I am relatively new to the world of k8s, flux, helm etc.. So, let me process my thoughts on this.

Thanks for explaining me and maintaining these helm charts, they are very helpful.

Surya · Answer 12 · Fri Jun 03 2022 17:22:08 GMT+0800 (China Standard Time)

@ChrisJBurns what did you mean by flux2-install? I don't see such a chart

Chris Burns · Answer 13 · Sat Jun 04 2022 00:04:13 GMT+0800 (China Standard Time)

This one: https://github.com/fluxcd-community/helm-charts/tree/main/charts/flux2