Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using repository trust in security contexts #3538

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

zc-devs
Copy link
Contributor

@zc-devs zc-devs commented Mar 23, 2024

Addresses #3537 (comment)

@zc-devs
Copy link
Contributor Author

zc-devs commented Mar 23, 2024

As it uses step's privileged, should close #3537.

@zc-devs zc-devs marked this pull request as ready for review March 23, 2024 18:03
@6543
Copy link
Member

6543 commented Mar 23, 2024

@zc-devs bugfix or enhancement :)

@zc-devs
Copy link
Contributor Author

zc-devs commented Mar 23, 2024

bugfix or enhancement

As a user I would call #3537 a bug => bugfix.

I also should have notified, that I did not test it. If code looks good, then I would request image to test by me and probably @everflux.


BTW, I noticed the same error as I almost always face. This occurs not only with fr.js. Does someone know what is it and how to get rid of? Now, I'm restarting a pipeline until it works.

@6543 6543 added build_pr_images If set, the CI will build images for this PR and push to Dockerhub bug Something isn't working labels Mar 24, 2024
@everflux
Copy link

Happy to test it out, do you have a pullable image?

@@ -464,6 +480,15 @@ func mapToEnvVars(m map[string]string) []v1.EnvVar {
return ev
}

func isRepoTrusted(step *types.Step) bool {
// TODO: probably, should be stored in the model (pipeline/backend/types/config.go)
trustedRepo, err := strconv.ParseBool(step.Environment["CI_REPO_TRUSTED"])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it safe to read it from the env? It can't be overwritten by users?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it safe to read it from the env?

¯_(ツ)_/¯
Elaborate, please.
Do you suggest to use dedicated variable in pipeline/backend/types/config.go?
What is the difference between env var (one map's entry) vs dedicated variable?

It can't be overwritten by users?

Seems, not for now, at least: #3164.

Copy link
Member

@xoxys xoxys Mar 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Elaborate, please.
Do you suggest to use dedicated variable in pipeline/backend/types/config.go?

Right now I have not suggested anything :) I just asked if it is safe to read a security-related setting from an env var. If only the server can set it, and it can't be overwritten by the pipeline config, I'm fine with it, but it might increase the possibilities to become an issue in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, might be an issue. Depends on #3164 implementation.
So, what are we gonna do?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, the clean solution would be to pass down the repo settings to the backend similar to Environment e.g.
Step.RepoSettings.

@zc-devs
Copy link
Contributor Author

zc-devs commented Mar 24, 2024

do you have a pullable image?

There.
@6543, thanks for a label.
@everflux, I've tested ⬇️ trusted/untrusted logic. Could you test if plugin works?

@zc-devs
Copy link
Contributor Author

zc-devs commented Mar 24, 2024

Pipeline:

skip_clone: true
steps:
  server:
    image: alpine
    commands:
      - echo Hello
      - sleep 60
    backend_options:
      kubernetes:
        securityContext:
          privileged: true
          runAsUser: 0
          runAsGroup: 0

woodpecker-agent.log
pod-untrusted.yaml
pod-trusted.yaml.txt

@everflux
Copy link

Thanks for looking into it this quickly.
I have currently only arm machine at my disposal I plan to verify tomorrow evening.

@everflux
Copy link

Successfully tested the prebuilt image with buildx plugin. Only setting "trusted repository" and no additional "privileged" setting on the workflow or workflow.backend level. Nice!

@stevapple
Copy link
Contributor

Only setting "trusted repository" and no additional "privileged" setting on the workflow or workflow.backend level.

IIRC running a trusted plugin (with a privileged container) shouldn't require the repository to be trusted?

@everflux
Copy link

I would be really happy if this could be included in 2.5.0 and any further changes could be discussed separately. (For example should escalated plugins be treated as trusted implicitly, would handling of volumes differently from privileged make sense etc)

@zc-devs
Copy link
Contributor Author

zc-devs commented Mar 26, 2024

Only setting "trusted repository"

Now, Buildx plugin should work without "trusted repository" as it was before, on 2.3.x.

@qwerty287 qwerty287 added this to the 2.5.0 milestone Mar 29, 2024
@everflux
Copy link

everflux commented Apr 2, 2024

Any chance this could be merged into a 2.4.x release?

@qwerty287
Copy link
Contributor

Probably not, but if this is merged you can use next. 2.5.0 should be released on Apr 17 at the latest.

@everflux
Copy link

everflux commented Apr 2, 2024

Too bad, I have a training planned on April 9th...

@xoxys
Copy link
Member

xoxys commented Apr 2, 2024

We can add a label to build an image for this PR and you can use that one for your training.

That exists already https://hub.docker.com/layers/woodpeckerci/woodpecker-server/pull_3538-alpine/images/sha256-ed7b0918be40787a5d4293a372195b3dedab165b63d2189a0585c2e64efaf20b?context=explore

@everflux
Copy link

everflux commented Apr 2, 2024

Thanks for the proposal, but that won't suffice (mixed user base with apple arm64 and amd64 architectures). No worries, though, I can use drone instead, the concepts are similar enough. And I don't want to cause additional effort in any way, I was just hoping for a point release before 2.5.

@pat-s
Copy link
Contributor

pat-s commented Apr 8, 2024

I would be ok merging this to allow @everflux to possible use WP on April 9th (if not too late). Besides, I am seeing the same issues on our PROD instance with more than 50+ files I would need to adapt on a mixed cluster, hence I am also having a strong need for a fix that restores 2.3.x functionality.

If not everything is working percectly yet we can still iterate until 2.5.x but in the meantime allow for a workaround via next for mixed cluster users.

@zc-devs Merging main caused some build failures now. In addition, cspell.json needs a fix. I just a few minutes right now but can look into it later this evening.

@xoxys
Copy link
Member

xoxys commented Apr 8, 2024

Not perfectly working and introducing another security issue again is a difference 🙂 if we are sure reading the repo trust setting from the env var and it cant be manipulated by end users feel free to go on.

# Conflicts:
#	pipeline/backend/kubernetes/pod.go
@zc-devs
Copy link
Contributor Author

zc-devs commented Apr 8, 2024

Merging main caused some build failures now

Fixed.

reading the repo trust setting from the env var...

the clean solution would be to pass down the repo settings to the backend similar to Environment e.g.
Step.RepoSettings

TBH, I don't want to put my dirty hands in the "core". And definitely won't before majority agreed on implementation or at least said something on topic.
Looks like a separate PR to me.

@xoxys
Copy link
Member

xoxys commented Apr 8, 2024

Fully agree on that but the PR should not be merged untill the majority agreed than as well.

@pat-s
Copy link
Contributor

pat-s commented Apr 16, 2024

@zc-devs @xoxys It seems one conversation from you is still open (see above). How can we make progress there?

If this doesn't make it into 2.5.0 (release date tomorrow), 2.5.0 will also be unusable as 2.4.x for folks coming from 2.3.x without touching many workflow files.

The current situation is therefore a bit suboptimal. If we can't find an agreement, I'd also consider reverting the backend change in 2.4 and restore the 2.3 behavior and include the proposed changes of this PR in a new/updated approach?

@zc-devs
Copy link
Contributor Author

zc-devs commented Apr 16, 2024

I think, Xoxys and I have met agreement. Moreover, I'm on his side in general (otherwise didn't leave the TODO).

How can we make progress there?

the majority agreed

@6543, @anbraten, @qwerty287

release date tomorrow

It can be merged as is by deadline. At least I cannot develop in next few days.

reverting the backend change in 2.4

You cannot.

@pat-s
Copy link
Contributor

pat-s commented Apr 16, 2024

You cannot #3537 (comment).

I know about the issue but that doesn't mean it is not revertable at all. Anyone can still run and install any WP version (even the ones including the mentioned flaws). But anyway, as this is not the main goal here, let's focus on getting this one here merged and move onward.

@everflux
Copy link

Perhaps the release could wait for resolving this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend/kubernetes bug Something isn't working build_pr_images If set, the CI will build images for this PR and push to Dockerhub
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants