docs: detailed documentation on options for securing a Forgejo Runner installation #1429

I'm not sure what this sentence means. It feels like something was lost, maybe around "with different configurations will be applicable for different use-cases."

Changed in 97f3cc2f39393c7970a55d9de39e83b36f0edb6f to:

There is no ideal configuration for these values, as changing them affects Forgejo access and security, but limits functionality.

What I originally wanted to do here is document common configurations that people might use, such as:

• I'm self-hosting Forgejo but just for myself and no collaborators
• I'm self-hosting Forgejo but just for my project and I want collaborators, but I don't want random other repos
• ... but just for my organization/company ...
• ... as a public service ...
  But I think some of this is self-evident given the call out of these parameters, and I think it also feels like it's a stretch to be in the Forgejo Runner docs. So anyway, that's where that original sentence was going and never got to. Maybe it can be dropped, or maybe the new version is useful. :-)

This is good now.

Global is what I would expect although I get what you mean.

I like Global. 97f3cc2f39393c7970a55d9de39e83b36f0edb6f

The on: pull_request target workflows

you meant

The on: pull_request_target workflows

i think

This section was intended to be on: pull_request, not target, but the use of the word target was definitely incorrect. I meant the workflow event. Clarified in 97f3cc2f39393c7970a55d9de39e83b36f0edb6f.

This can risk the confidentiality of other services

I thought it should be

This can be a risk for the confidentiality of other services

or something similar. But then realized it is my non native English speaker ignorance.

I've tweaked to refer to the confidentiality of the data hosted by the service, as you're right to point out it felt like a mismatch of some kind. 97f3cc2f39393c7970a55d9de39e83b36f0edb6f

I am not aware of self. Did you mean host?

Ah, yup. Confusion here over the label name and label value. I was fairly sure I checked this twice and yet it was not correct. Fixed in 06f3433dbc94f069ec4424f24b863d1f34236610.

s/on the wild variety /on the wide variety /

Corrected in 97f3cc2f39393c7970a55d9de39e83b36f0edb6f.

They can create a new branch with a on: push configuration and configure the workflow to run when modifications are made to their branch

Can be confusing, since the on: push isn't a configuration "on the branch" per se, just something that references the branch.

Maybe this instead:

They can create a new branch that isn't covered by branch protection, and a workflow with a matching on: push

Depending on how comprehensive you want to be, you could also mention that one can create a branch protection rule to restrict/disable pushes to all branches. PRs would be required to come from a fork, then.

re: on: push, updates in a26ca16ad50a1005b7fa6376c390e467173aa187.

re: creating branch protection rule to disable pushes... hm... trying to square that with why they would have write access to the repo. I guess the thought is that they'd write access to the repo for PR merges but can't create other branches? And if there were review requirements on the PR, then they also couldn't just merge their own PRs to bypass the restrictions. Sure... it feels hard to describe this in this document flow, and it kinda just boils down to the next paragraph about "does not have direct write access". I'm thinking it'd be confusing to describe here.

re: creating branch protection rule to disable pushes... hm... trying to square that with why they would have write access to the repo. I guess the thought is that they'd write access to the repo for PR merges but can't create other branches?

Yes. "write access" is often equated to just have rights to merge PRs, and having to create PRs from forks themselves if they want to add code.

Maybe this, then?

-If Mallory has write access to the repository, they can run arbitrary workflows.
+If Mallory can push directly to the repository, they can run arbitrary workflows

Revised in 210857d4dd5236b071d6c46416ece2af31c4dc78.

The on: pull_request workflows [...] do have elevated security
they have no access to the secrets in the repository

Those two are contradicting each other.

Clarified to additional restrictions. a26ca16ad50a1005b7fa6376c390e467173aa187

-rather than with the content of the branch
+rather than with the content of the pull request

"branch" by itself is ambiguous, and even with "source branch", people are sometimes confused what the source or target is.
"content of the pull request" should make this easier for those.

It might make sense to mention actions/checkout checking out the target instead of the source for this event type, and that even if one does check out the source, they should take care not to run scripts/code that could have been modified by the PR.

re: branch -> pull request -- revised in a26ca16ad50a1005b7fa6376c390e467173aa187.

re: actions/checkout and other care -- that is described in detail in the referenced link for on.pull_request_target, so I'd prefer to not repeat them here.

A container can always communicate with the host (unless it doesn't have an IP at all). You'd need to figure out the host's IP, but that's not particularly hard in most cases.

If "a server on localhost:3000" does happen to mean a socket of (127.0.0.1, 3000), then the container can indeed not access that unless network mode is host. But listening on 0.0.0.0 is relatively common, and any container on the same host, regardless of its network mode, can access that by default.

localhost:3000 did mean 127.0.0.1 binding to me, but I'll be specific. Revised in a26ca16ad50a1005b7fa6376c390e467173aa187.

but scoped only to other docker containers running on the same docker daemon

Only to other containers that are also on the default bridge. Containers that are connected to user-defined bridges (i.e. custom networks) cannot be accessed from the default bridge.

Revised in a26ca16ad50a1005b7fa6376c390e467173aa187.