#758  Allow to set CI job as protected (need owner approval)
Marcos de Oliveira opened 4 weeks ago

It would be cool to have the option to set an CI job as protected, so we could use secrets on it, and still allow it in pull requests (needing owner approval, though). This way, owners can give a quick glance at the code to see if no secrets would be leaked, and then "approve" the CI job to run.

While at it, you could also add the possibility to specify PR authors/groups for whom jobs would be auto-approved.

*Don't know it this is an "Improvement" or "New feature". Feel free to change.

Robin Shen commented 4 weeks ago

Instead of introducing a new workflow, I'd suggest to configure your CI job to use different job secret for pull request CI build and normal CI build on master branch:

To do it, please switch to menu Administration / Groovy Scripts to define a script with name say get-ci-secret-key with below content:

if (build.request != null)
    return build.getJobSecretAuthorizationContext().getSecretValue("ci_pull_request_key")
    return "ci_key" 

Then you can use @script:get-ci-secret-key@ to get value of desired secret. This way trusted code and untrusted code can use different environments for testing.

Marcos de Oliveira commented 4 weeks ago

But then secrets may still be leaked by a malicious/tampered pull request... Even having separate secrets for CI and CD, one may still want to prevent CI (testing) secrets from being exposed, but still be able to use it on pull requests.
Pull request build approval is something that's broadly adopted by CI/CD platforms. Here are some:

  • GitLab
  • Drone
  • Jenkins
  • Woodpecker (Fork of drone)
  • Agola
  • Concourse
  • GoCD
  • Circle CI
Robin Shen commented 4 weeks ago

Secrets can be configured with authorized branches, which means only code reachable from these branches can use the secret. So it is not possible for malicious pull request to use protected secret, unless you merged the code, in which case means you've verified code to make sure it is safe.

As to pull request build approval, can you please guide me the detailed feature description in these products? I know that they have manual approval builds, but that can be achieved easily by manually running subsequent jobs in same OneDev pipeline.

Marcos de Oliveira commented 3 weeks ago

Generally, when you set a project as "protected", it only run jobs if committer is the owner (or one of) of the project, other jobs wait for owner approvals, so secrets may be allowed in pull requests safely. When an contributor creates a PR, owners get notified that there are jobs waiting for their approval. This way, secrets may not need to be restricted to certain branches, as if an untrusted person creates a PR, jobs will not run, unless approved.

Robin Shen commented 3 weeks ago

Isn't this workflow very verbose? Since for each pull request and each update you need to approve the job... I doubt if this approach is practical in real world projects. 

Marcos de Oliveira commented 3 weeks ago

Like, if there is the need to use a secret for testing something and you don't want to expose it, there is no much choices without merging...

Robin Shen changed state to 'Closed' 3 weeks ago
Previous Value Current Value
issue 1 of 1
Issue Votes (0)
Watchers (4)
issue onedev/server#758
Please wait...
Page is in error, reload to recover