Support Flux Bootstrap or Deploy key creation
ChrisJBurns opened this issue · 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 asconnectionDetailsSecret
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 andknown_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 ofObjects
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
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
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.
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.
Shall close
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.
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 🤔
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.
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.
I would close this as
wantfix
. The whole idea offlux 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.
@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.
@suryapandian It depends how you're installing Flux. If you're using the
flux2-install
andflux2-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.
@ChrisJBurns what did you mean by flux2-install
? I don't see such a chart