Disallow collaborators with write permissions to deploy to fleet

[maxammann]

With the current configuration any user with write permissions can change the fleet config by creating a new branch and deploying from it.

I think this is unexpected as you maybe want to allow members to propose changes but only use them from the main branch.

[getvictor]

Hi @maxammann thank you for your contribution. I'd like to get some additional context. When do you see that changes are made from the non-main branch? Is that because people are using manual workflow dispatch, or under other circumstances as well?

I'd like to keep workflow_dispatch since it is useful for initial bringup/debug. But we can change the flow so that we always do dry-run on a non-main branch.

[maxammann]

So the original though was that anyone with write permission to a feature branch can deploy their changes without first merging to main.

However, as long as the secrets are available to feature branches any employee with write permissions could change the config by exfiltrating the secrets.
I'm looking here at the thread model of a malicious insider essentially.

So feel free to close this PR. It only makes it slightly more difficult for a malicious insider to change endpoints. The proper fix here is to restrict secrets to the main branch through GitHub environments/deployments.

[getvictor]

@maxammann What do you recommend for a high-security gitops deployment?

Perhaps something like the following:

• have a staging branch -- reviewed PRs are merged to the staging branch and only then they run gitops --dry-run
• after staging dry run succeeds, manually or automatically merge into main branch
• use environment secrets, which are only available to main and staging branches

[maxammann]

@maxammann What do you recommend for a high-security gitops deployment?

Perhaps something like the following:

• have a staging branch -- reviewed PRs are merged to the staging branch and only then they run gitops --dry-run
• after staging dry run succeeds, manually or automatically merge into main branch
• use environment secrets, which are only available to main and staging branches

Any staging branches won't really cut it. As long as secrets are available to non-protected branches this can be misused.

Ideally, write access to a repo should not allow users to perform fleet changes without approval. This also includes dry runs, unless Fleet would have API keys for Gitops that are read-only.

So either environment secrets or actually managing secrets via OIDC would work. This seems out-of-scope of Fleet though. The best thing would be to document this in the readme and to limit updates (including dry-runs) to "main" as this one has the highest chance of being more protected with Fleet's customers.