Rework repo security levels

[anbraten]

closes #336

I thought about adding an allow list for users to by-pass the approval setting, but that makes the settings quite complex and might actually introduce some potential security issues.

Actually it seems a quite small list of options could solve most common cases as well:

• allow every pipeline (including fork PRs without approval)
• require approval for fork PRs (would be the new default)
• require approval for every pipeline (PR, tag, push, ...)

Changes

• replace AllowPull and IsGated with SecurityMode
• migrate old settings to SecurityMode
• adjust docs

[woodpecker-bot]

Deployment of preview was successful: https://woodpecker-ci-woodpecker-pr-3348.surge.sh

[qwerty287]

Actually it seems a quite small list of options could solve most common cases as well:

In my opinion, we should support more here.

For a lot of different ideas here see #2293.
My main point is: You can use the approve feature also as a feature if you don't want to run all pipelines to save resources. Having as many options as possible could help here.

Can't you create an interface which just checks whether the pipeline needs approval or not so we can easily extend the feature by adding a new implementation? Maybe also with support for an external http extension?

[xoxys]

Can't you create an interface which just checks whether the pipeline needs approval or not so we can easily extend the feature by adding a new implementation? Maybe also with support for an external http extension?

If we need that level of flexibility, why not use something like open policy agent, as proposed in the issue? Approval rules can be written by users via the UI or CLI by repo admins without writing external services and without blowing up the server code for every single use case that we have not yet thought about.

[anbraten]

In my opinion, we should support more here.

Sure, we can make it highly adjustable, but on the other hand, to keep things simple (which is often a quite import benefit / feature as well for users) it's sometimes more helpful to support just the most common options IMO.

If we need that level of flexibility, why not use something like open policy agent, as proposed in the issue? Repo rules can be written by users and added via UI by repo admins without writing external services and without blowing up the server code for every single use case that we have not yet thought about.

I don't think open policy agent would be that helpful as we still need to provide context data (usernames, if user is admin / maintainer / ..., amount of pipeline executed for a context (like PR), ...) to be even able to write rules
as suggested here: #2293 (comment)

[xoxys]

Sure, but implementing something like a SecurityContext would be required for external services as well.

it's sometimes more helpful to support just the most common options IMO.

To be honest (please don't get me wrong) we also implement stuff like cli auto-updates cli auto-setup etc. just because it's convenient. This also adds code complexity, and we still do it even if it is easier to just let users download the binary from a release. Especially for security related features, flexibility is key IMO.