Run flux with read-only access to repository

[jml]

A few times I've spoken to flux users and potential flux users who really like the way flux keeps deployments in sync, but would rather not have flux actually edit their YAMLs.

They have a variety of reasons, include some or all of:

• general wariness about granting write access
• desire for all changes to be reviewed by a human
• desire for all changes to go through some automated CI process before being applied
• wanting to lock down which humans can trigger changes to the UI
• general desire for as few ways of doing a thing as possible (simplifies processes, training, etc. in larger orgs)

[rade]

Sounds like this is really a "sync-only" mode, correct?

desire for all changes to be reviewed by a human
desire for all changes to go through some automated CI process before being applied

Flux could open a PR.

[jml]

Yup. Yes re opening PR. @squaremo mentioned that when we spoke. His ideas sounded fleshed out enough that I thought I’d leave it to him to speculate.

…

On Tue, 12 Jun 2018 at 18:27, Matthias Radestock ***@***.***> wrote: Sounds like this is really a "sync-only" mode, correct? desire for all changes to be reviewed by a human desire for all changes to go through some automated CI process before being applied Flux could open a PR. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1139 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHq6um_aZAtMif7Ob0rg9Tv-QHKWrI2ks5t7_nkgaJpZM4Uk0xg> .

[squaremo]

Flux could open a PR.

You can't open a PR if you can't write to the repo.

[squaremo]

The main technical difficulty with this is that flux currently assumes it can forcepush its "sync tag" to the upstream repo. This is largely a mechanism to prevent duplicate events, though it is tangled up in a few other places. To have properly read-only repos, we'd have to figure out another way to keep a high water mark or otherwise prevent duplicate events. (The event receiver should really be deduplicating anyway, but we shouldn't rely on that here.)

[stefanprodan]

We could store the checkpoint in an annotation on the SSH key secret that's under Flux control.

[ariep]

Potential flux user here. I would also be very interested in this feature for yet another reason: our use-case would consist of a single repository specifying a deployment, and many (small) clusters, that are not under our control, using flux to pull from the specification and update accordingly. We would not want to give the people controlling the clusters write access to our source repo.

[primeroz]

really interested in this.

I need it to run CI Clusters where, due to an higher risk of leaking credentials, i really don't want to attach a RW ssh key

is there any plan to work on this ? I can see work on it being done as soon as 3 hours ago :)

[ghost]

Is there any documentation for how to do this?

[2opremio]

There is a flux flag for this --git-readonly

[2opremio]

See https://docs.fluxcd.io/en/1.18.0/faq.html#can-i-run-flux-with-readonly-git-access