Isolated/Sandbox setup?

[Andre601]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

I want to have a worklfow in a repository, that validates Pull requests targetting a wiki branch for any possible changes that can break the page building.

However, I noticed a major problem. The software used to create the wiki is MkDocs, which provides support for adding extensions, plugins and hooks.
All of them allow execution of any form of python code that can be abused to retrieve the GitHub workflow token secret and execute various tasks in the repository.

Is there any way of sandboxing the repository, meaning isolating from any environment that could allow manipulation of the repository itself?

[Andre601]

To add a bit more context:
I would like to be able to write to the Pull request, reporting the failed site build. This afaik requires issues: write permission to write, which also opens the risk of making more issues or discussions.

Tho, if that would be more or less impossible, will I accept this as a limitation.
My primary goal is some way of isolation to pervent abusive users from accessing and abusing sensitive data.

[Andre601]

Thanks, but I would apreciate less ChatGPT generated replies, as this one clearly is one in format, structure and tone.

[kailashv2]

Your concern is valid. Once you allow MkDocs plugins, hooks, or extensions from an untrusted PR, you're effectively allowing arbitrary Python execution. At that point the question becomes less "how do I sandbox MkDocs?" and more "how do I safely execute hostile code?"

I would avoid pull_request_target entirely here. It is easy to accidentally combine elevated permissions with PR-controlled code.

For this use case I'd split responsibilities:

Workflow A: Untrusted validation

permissions:
  contents: read

on:
  pull_request:
    branches:
      - wiki

• No secrets
• Read-only GITHUB_TOKEN
• actions/checkout with persist-credentials: false
• Build/test only
• Treat everything in the PR as hostile

If a malicious plugin executes:

import os
print(os.environ)

there should be nothing valuable available.

Then:

Workflow B: Privileged reporting

Run separately after validation succeeds.

This workflow can:

• Comment on PRs
• Add labels
• Update status
• Publish results

but it should consume artifacts/results from Workflow A and never execute PR code again.

The important distinction is:

don't sandbox the code; sandbox the privileges.

Containers help with filesystem isolation, but they do not solve the primary risk if tokens, secrets, or write permissions still exist.

Your real security boundary in GitHub Actions is permissions + workflow separation, not Python isolation.

[Andre601]

What I wonder most is how I could make a seconf workflow that:

• Only executes if the validation one failed (mkdocs build --strict exited with an error) and
• Comments to the Pull request in question.

I'm not so well with GitHub Actions, especially in terms of what data can be retrieved across workflows...
But from what I managed to gather so far would I make the comment workflow have a needs configuration setting the other workflow as its dependency and in that validation workflow, export the result as a GITHUB_OUTPUT environment entry to then retrieve?

[kailashv2]

You don't need a second workflow for this unless you specifically want privilege separation across workflows.

A simpler and safer pattern is:

• keep the entire PR build workflow unprivileged
• let the build fail normally
• add a final conditional job that comments on the PR

Example:

name: Validate Wiki

on:
  pull_request:
    branches:
      - wiki

permissions:
  contents: read
  pull-requests: write

jobs:
  validate:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false

      - run: pip install mkdocs
      - run: mkdocs build --strict

  comment-on-failure:
    if: failure()
    needs: validate
    runs-on: ubuntu-latest

    steps:
      - uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: "❌ MkDocs validation failed. Please check the workflow logs."
            })

The important part is:

if: failure()

and:

needs: validate

This avoids passing outputs around entirely.

That said, there is still one important security nuance:

If you allow pull-requests: write in the same workflow that executes PR-controlled MkDocs plugins/hooks, malicious code could still abuse the token to spam comments or manipulate PR metadata.

So for maximum isolation your original instinct was actually correct:

• Workflow A = untrusted execution (read-only token)
• Workflow B = privileged reporting only

In that stricter design, Workflow A uploads an artifact/status result, and Workflow B is triggered via workflow_run.

That's the safer architecture if you truly treat MkDocs plugins as hostile code.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬