Block outbound calls from ci runners to unallowed endpoints#1175
Block outbound calls from ci runners to unallowed endpoints#1175
Conversation
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (10)
WalkthroughMultiple GitHub Actions workflows had their Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 37 minutes and 31 seconds.Comment |
spoorcc
force-pushed
the
feature/harden-runners
branch
2 times, most recently
from
4f82a71 to
5ee4598
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/build.yml:
- Around line 25-30: The egress allowlist for the step-security/harden-runner
action currently is empty while egress-policy: block is set, which will break
outbound installs; update the allowed-endpoints entries (the two
allowed-endpoints blocks associated with the harden-runner invocation) to
include the external package and metadata hosts your jobs need (for example
pypi.org and files.pythonhosted.org for pip, rubygems.org for gem,
community.chocolatey.org or chocolatey.org for choco, api.nuget.org and
nuget.org for dotnet/nuget, plus github.com and raw.githubusercontent.com if
workflows fetch releases), ensuring both occurrences (the block at the top and
the one around lines ~211-216) are populated before enforcing egress-policy:
block.
In @.github/workflows/codeql-analysis.yml:
- Around line 37-42: The workflow sets step-security/harden-runner with
egress-policy: block but leaves allowed-endpoints empty (allowed-endpoints: >+),
which will block outbound calls needed by actions/checkout; fix by populating
allowed-endpoints with the required hosts (at minimum github.com:443 and
api.github.com:443, and optionally raw.githubusercontent.com:443) or change to a
Policy Store-backed configuration instead of block mode so actions/checkout can
access the network; update the allowed-endpoints entry in the harden-runner step
accordingly.
In @.github/workflows/dependency-review.yml:
- Around line 19-23: The workflow currently sets step-security/harden-runner
with egress-policy: block while leaving allowed-endpoints blank, which will
block all outbound traffic and break steps like actions/checkout and
actions/dependency-review-action; fix by populating allowed-endpoints with the
necessary GitHub endpoints (e.g., api.github.com, github.com,
raw.githubusercontent.com, uploads.github.com, objects.githubusercontent.com and
any required registry or API hosts your jobs need) so that the harden-runner
action (egress-policy and allowed-endpoints) allows those outbound calls; ensure
allowed-endpoints is not empty and includes any additional third-party hosts
used by your jobs.
In @.github/workflows/devcontainer.yml:
- Around line 18-22: The harden-runner step currently sets egress-policy: block
with an empty allowed-endpoints list, which blocks all outbound traffic; update
the step-security/harden-runner action configuration (the harden-runner step
using egress-policy and allowed-endpoints) to include the required endpoints
(e.g., api.github.com, github.com, raw.githubusercontent.com, npm
registry/registry.npmjs.org or your container registry, and any build/dependency
hosts) or else change egress-policy to allow or remove the harden-runner step
until you provision a Policy Store policy; ensure allowed-endpoints contains all
hosts needed by checkout, Docker/push/pull, and package managers so subsequent
steps can access the network.
In @.github/workflows/docs.yml:
- Around line 19-23: The workflows set harden-runner with egress-policy: block
and an empty allowed-endpoints, which blocks all outbound traffic (breaking
actions/checkout and pip installs); update each job that uses harden-runner with
egress-policy: block (look for uses: step-security/harden-runner and the
allowed-endpoints field) to include at minimum the allowlist entries
github.com:443, api.github.com:443, pypi.org:443, and files.pythonhosted.org:443
under allowed-endpoints so checkout, PyPI installs and actions-gh-pages can
reach their endpoints, or alternatively switch those jobs to use StepSecurity’s
Policy Store if you want a centralized allowlist.
In @.github/workflows/python-publish.yml:
- Around line 23-27: The workflow currently sets step-security/harden-runner
with egress-policy: block but leaves allowed-endpoints empty, which will block
all outbound network calls and break subsequent steps; update the harden-runner
configuration by populating allowed-endpoints with the required host:port
entries (e.g., github.com:443, api.github.com:443, pypi.org:443 and any other
services your job needs) or switch to using the Policy Store option instead so
that actions/checkout, actions/setup-python, pip installs and artifact uploads
can reach their endpoints; modify the block in the
.github/workflows/python-publish.yml where allowed-endpoints is declared to
include the necessary endpoints.
In @.github/workflows/release.yml:
- Around line 24-27: The prepare-release job is using harden-runner with
egress-policy: block and an empty allowed-endpoints list so actions/checkout
cannot reach GitHub; update the job configuration (prepare-release) to either
switch egress-policy to audit or populate allowed-endpoints with the GitHub
domains required by actions/checkout (at minimum github.com,
raw.githubusercontent.com and api.github.com) so outbound access to those
endpoints is permitted, or start in audit mode to discover additional domains
before locking down.
In @.github/workflows/run.yml:
- Around line 18-23: The workflow sets step-security/harden-runner with
egress-policy: block but leaves allowed-endpoints empty (allowed-endpoints: >+),
which blocks all outbound traffic and causes checkout to fail; update the
hardened runner usage by populating allowed-endpoints with the necessary
endpoints (GitHub API/registry domains, actions/checkout host, package
registries, etc.) or switch to audit mode while iterating; locate the step
referencing step-security/harden-runner and the keys egress-policy and
allowed-endpoints and add the required hostnames/URLs for both occurrences (the
block at lines shown and the similar block at lines 77-81) so actions/checkout
and other network calls are permitted.
In @.github/workflows/scorecard.yml:
- Around line 29-33: The workflow currently sets the harden-runner step (uses:
step-security/harden-runner) with egress-policy: block but leaves
allowed-endpoints empty, which blocks outbound calls required by
actions/checkout; update the allowed-endpoints value for that harden-runner
invocation to include at minimum github.com:443 and api.github.com:443 (or apply
the recommended allowed endpoints policy from the step-security/harden-runner
docs) so actions/checkout and GitHub API calls are permitted.
In @.github/workflows/test.yml:
- Around line 13-17: The workflow currently sets step-security/harden-runner
with egress-policy: block but leaves allowed-endpoints empty, which blocks all
outbound traffic and breaks steps like actions/checkout, apt-get, pip install
and codacy upload; fix by populating allowed-endpoints with the required
hostnames/IPs (e.g., github.com, api.github.com, debian/apt repos, pypi.org,
files.pythonhosted.org, Codacy endpoints) or change egress-policy to allow or
configure a Policy Store before merging so the harden-runner step does not block
necessary network calls; update the allowed-endpoints entry in the harden-runner
step accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: fda5d88b-5845-468d-ba06-3dd79af4543c
📒 Files selected for processing (10)
.github/workflows/build.yml.github/workflows/codeql-analysis.yml.github/workflows/dependency-review.yml.github/workflows/devcontainer.yml.github/workflows/docs.yml.github/workflows/python-publish.yml.github/workflows/release.yml.github/workflows/run.yml.github/workflows/scorecard.yml.github/workflows/test.yml
spoorcc
force-pushed
the
feature/harden-runners
branch
2 times, most recently
from
6f64f66 to
09a27e0
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (6)
.github/workflows/devcontainer.yml (1)
18-25:⚠️ Potential issue | 🟠 Major | ⚡ Quick winExpand the allowlist for the package installs this job performs.
The current list covers GitHub and Docker registry traffic, but the later
pip install -e .[development,docs,casts]andpre-commitsteps will still need PyPI access. Add at leastpypi.org:443andfiles.pythonhosted.org:443before switching to block.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/devcontainer.yml around lines 18 - 25, The allowlist for the harden-runner step (uses: step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40) is missing PyPI hosts needed for package installs; update the allowed-endpoints value in that step to include pypi.org:443 and files.pythonhosted.org:443 (in addition to github.com:443, registry-1.docker.io:443, auth.docker.io:443) so pip install -e .[...] and pre-commit can access PyPI before egress-policy: block is applied..github/workflows/release.yml (1)
24-27:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winPopulate the release job allowlist.
This harden-runner step is still deny-all, so
actions/checkoutandactions/setup-pythonwill be blocked before release creation starts. Add the GitHub endpoints required by this job, or keep audit mode until the list is complete.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 24 - 27, The harden-runner step (step-security/harden-runner) is currently blocking all egress because allowed-endpoints is empty, which prevents actions/checkout and actions/setup-python from working; update the allowed-endpoints list under the harden-runner step to include the necessary GitHub endpoints (e.g., api.github.com, github.com, raw.githubusercontent.com, codeload.github.com, packages.github.com, actions.githubusercontent.com, and any runner update or package hosts your job needs) or switch the step to audit mode until you’ve enumerated all required hosts; modify the allowed-endpoints entry referenced in the release workflow so the egress-policy: block behavior permits those endpoints for the release job..github/workflows/dependency-review.yml (1)
19-23:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winPopulate the allowlist before enforcing block mode.
This step still blocks all outbound traffic, so
actions/checkoutand the dependency-review action will fail immediately. Add the GitHub endpoints this job needs before merging.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/dependency-review.yml around lines 19 - 23, The harden-runner step currently sets egress-policy: block before any allowed endpoints are listed, which will break actions/checkout and dependency-review; update the step-security/harden-runner usage to populate allowed-endpoints with the required GitHub endpoints (e.g., api.github.com, download.github.com, github.com, uploads.github.com, packages.githubusercontent.com, token.actions.githubusercontent.com, and any registry endpoints you use) so the job can reach GitHub services while still blocking other egress; keep the parameter name allowed-endpoints and preserve the multiline >+ format used in the diff..github/workflows/python-publish.yml (1)
23-27:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winFill the allowlist before blocking egress.
This job runs
actions/checkout,actions/setup-python, andpip install, so an empty allowlist will break the build as soon asblockis enforced. Add the GitHub and PyPI endpoints this job needs.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/python-publish.yml around lines 23 - 27, The workflow enables step-security/harden-runner with egress-policy: block but leaves allowed-endpoints empty; populate the allowed-endpoints input for the harden-runner step (the step using step-security/harden-runner) to include all required GitHub and PyPI hosts so checkout/setup-python/pip can run (e.g., github.com, api.github.com, raw.githubusercontent.com, codeload.github.com, actions.githubusercontent.com, pypi.org, files.pythonhosted.org and any mirrors your CI uses)..github/workflows/scorecard.yml (1)
29-33:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winPopulate the allowlist before enabling block mode.
allowed-endpointsis still empty here, soegress-policy: blockwill stopactions/checkoutfrom reaching GitHub and the workflow will fail immediately. Add the GitHub endpoints this job needs before merging.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/scorecard.yml around lines 29 - 33, The workflow enables the step-security/harden-runner action with egress-policy: block but leaves allowed-endpoints empty, which will block actions/checkout and other GitHub API calls; update the step named "Harden the runner (Block egress traffic: Only allow calls to allowed endpoints)" (step-security/harden-runner) to populate the allowed-endpoints list with the required GitHub endpoints (e.g., api.github.com, raw.githubusercontent.com, github.com, and any other service hosts your job needs such as marketplace or third‑party APIs used by this workflow) so the runner can reach GitHub and required external services before merging..github/workflows/run.yml (1)
18-23:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winGive the Cygwin job a real allowlist.
actions/checkout,cygwin-install-action,choco install, andpip installall need network access, so an empty allowlist will block the job end-to-end. Populate the endpoints this matrix needs instead of leaving this blank.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/run.yml around lines 18 - 23, The harden-runner step currently sets allowed-endpoints to empty which blocks network access; update the step-security/harden-runner step (the "Harden the runner (Block egress traffic...)" entry) to populate allowed-endpoints with the real allowlist needed by actions/checkout, cygwin-install-action, choco and pip — e.g. add github.com, api.github.com, codeload.github.com, raw.githubusercontent.com, pypi.org, files.pythonhosted.org, community.chocolatey.org (and chocolatey.org if used), cygwin.com plus its common mirror host(s) and any specific download hosts your cygwin-install-action or choco packages require — by listing those hosts under the allowed-endpoints key so the job can reach required endpoints.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/build.yml:
- Around line 25-39: The runner hardening step using step-security/harden-runner
currently sets allowed-endpoints in the job block but is missing endpoints
needed by the Windows jobs; update the allowed-endpoints list used by the
harden-runner step (the block with uses: step-security/harden-runner and with:
allowed-endpoints) to include community.chocolatey.org:443, api.nuget.org:443,
and uploads.github.com:443 so choco install, dotnet tool install --global wix,
and softprops/action-gh-release asset uploads succeed under egress-policy:
block.
In @.github/workflows/docs.yml:
- Around line 92-102: Add uploads.github.com:443 to the allowed-endpoints list
used by the "Harden the runner (Block egress traffic: Only allow calls to
allowed endpoints)" step (uses:
step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40) for the
pdf job, because the pdf job's publisher (softprops/action-gh-release) needs to
reach uploads.github.com to upload release assets; update the allowed-endpoints
block to include the entry uploads.github.com:443 so the publish step can
complete when egress-policy is block.
---
Duplicate comments:
In @.github/workflows/dependency-review.yml:
- Around line 19-23: The harden-runner step currently sets egress-policy: block
before any allowed endpoints are listed, which will break actions/checkout and
dependency-review; update the step-security/harden-runner usage to populate
allowed-endpoints with the required GitHub endpoints (e.g., api.github.com,
download.github.com, github.com, uploads.github.com,
packages.githubusercontent.com, token.actions.githubusercontent.com, and any
registry endpoints you use) so the job can reach GitHub services while still
blocking other egress; keep the parameter name allowed-endpoints and preserve
the multiline >+ format used in the diff.
In @.github/workflows/devcontainer.yml:
- Around line 18-25: The allowlist for the harden-runner step (uses:
step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40) is missing
PyPI hosts needed for package installs; update the allowed-endpoints value in
that step to include pypi.org:443 and files.pythonhosted.org:443 (in addition to
github.com:443, registry-1.docker.io:443, auth.docker.io:443) so pip install -e
.[...] and pre-commit can access PyPI before egress-policy: block is applied.
In @.github/workflows/python-publish.yml:
- Around line 23-27: The workflow enables step-security/harden-runner with
egress-policy: block but leaves allowed-endpoints empty; populate the
allowed-endpoints input for the harden-runner step (the step using
step-security/harden-runner) to include all required GitHub and PyPI hosts so
checkout/setup-python/pip can run (e.g., github.com, api.github.com,
raw.githubusercontent.com, codeload.github.com, actions.githubusercontent.com,
pypi.org, files.pythonhosted.org and any mirrors your CI uses).
In @.github/workflows/release.yml:
- Around line 24-27: The harden-runner step (step-security/harden-runner) is
currently blocking all egress because allowed-endpoints is empty, which prevents
actions/checkout and actions/setup-python from working; update the
allowed-endpoints list under the harden-runner step to include the necessary
GitHub endpoints (e.g., api.github.com, github.com, raw.githubusercontent.com,
codeload.github.com, packages.github.com, actions.githubusercontent.com, and any
runner update or package hosts your job needs) or switch the step to audit mode
until you’ve enumerated all required hosts; modify the allowed-endpoints entry
referenced in the release workflow so the egress-policy: block behavior permits
those endpoints for the release job.
In @.github/workflows/run.yml:
- Around line 18-23: The harden-runner step currently sets allowed-endpoints to
empty which blocks network access; update the step-security/harden-runner step
(the "Harden the runner (Block egress traffic...)" entry) to populate
allowed-endpoints with the real allowlist needed by actions/checkout,
cygwin-install-action, choco and pip — e.g. add github.com, api.github.com,
codeload.github.com, raw.githubusercontent.com, pypi.org,
files.pythonhosted.org, community.chocolatey.org (and chocolatey.org if used),
cygwin.com plus its common mirror host(s) and any specific download hosts your
cygwin-install-action or choco packages require — by listing those hosts under
the allowed-endpoints key so the job can reach required endpoints.
In @.github/workflows/scorecard.yml:
- Around line 29-33: The workflow enables the step-security/harden-runner action
with egress-policy: block but leaves allowed-endpoints empty, which will block
actions/checkout and other GitHub API calls; update the step named "Harden the
runner (Block egress traffic: Only allow calls to allowed endpoints)"
(step-security/harden-runner) to populate the allowed-endpoints list with the
required GitHub endpoints (e.g., api.github.com, raw.githubusercontent.com,
github.com, and any other service hosts your job needs such as marketplace or
third‑party APIs used by this workflow) so the runner can reach GitHub and
required external services before merging.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: e6397370-acac-4e3a-8616-2a14da35cc1a
📒 Files selected for processing (10)
.github/workflows/build.yml.github/workflows/codeql-analysis.yml.github/workflows/dependency-review.yml.github/workflows/devcontainer.yml.github/workflows/docs.yml.github/workflows/python-publish.yml.github/workflows/release.yml.github/workflows/run.yml.github/workflows/scorecard.yml.github/workflows/test.yml
spoorcc
force-pushed
the
feature/harden-runners
branch
4 times, most recently
from
371d7a8 to
cb3e54f
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
cb3e54f to
fd31851
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
fd31851 to
0d3ed0b
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
0d3ed0b to
f06975f
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
f06975f to
700219d
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
700219d to
ce325ba
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
ce325ba to
a2a67bf
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
a2a67bf to
426b9b3
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
426b9b3 to
e53db44
Compare
There was a problem hiding this comment.
Actionable comments posted: 5
♻️ Duplicate comments (4)
.github/workflows/scorecard.yml (1)
29-34:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winEmpty allowlist with block mode will break the workflow.
The
allowed-endpoints: >+on line 33 is followed by no endpoints, resulting in an empty allowlist. Withegress-policy: block, all outbound traffic is denied, and theactions/checkoutstep on line 36 will fail immediately. Theossf/scorecard-actionand subsequent upload steps also require network access.🐛 Proposed fix to add required endpoints
with: egress-policy: block allowed-endpoints: >+ + github.com:443 + api.github.com:443 + uploads.github.com:443 - name: "Checkout code"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/scorecard.yml around lines 29 - 34, The workflow currently sets step-security/harden-runner with egress-policy: block but leaves allowed-endpoints empty (allowed-endpoints), which will block actions/checkout and network-requiring steps; fix by populating allowed-endpoints with the necessary hostnames used by GitHub Actions and the scorecard/upload steps (at minimum include github.com, api.github.com, raw.githubusercontent.com, codeload.github.com, uploads.github.com, and any scorecard endpoints), ensuring the allowed-endpoints block for the step-security/harden-runner action includes these hosts so actions/checkout and ossf/scorecard-action can access required resources..github/workflows/build.yml (1)
25-39:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMissing endpoints for Windows build operations.
The
buildjob runs on Windows (windows-latest) and requires additional endpoints not in the current allowlist:
- Chocolatey (line 53:
choco install zig): Needscommunity.chocolatey.org:443andchocolatey.org:443- NuGet (line 73:
dotnet tool install --global wix): Needsapi.nuget.org:443- Release uploads (line 128:
softprops/action-gh-release): Needsuploads.github.com:443Without these, the Windows build will fail at the Zig installation step.
🐛 Proposed fix
allowed-endpoints: >+ github.com:443 api.github.com:443 + uploads.github.com:443 release-assets.githubusercontent.com:443 pypi.org:443 files.pythonhosted.org:443 packages.microsoft.com:443 azure.archive.ubuntu.com:80 esm.ubuntu.com:443 index.rubygems.org:443 rubygems.org:443 + community.chocolatey.org:443 + chocolatey.org:443 + api.nuget.org:443🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build.yml around lines 25 - 39, The harden-runner egress allowlist for the step using step-security/harden-runner (egress-policy: block, allowed-endpoints) is missing endpoints required by the Windows build; update the allowed-endpoints list used in that step to include community.chocolatey.org:443 and chocolatey.org:443 for choco install zig, api.nuget.org:443 for dotnet tool install (NuGet), and uploads.github.com:443 for softprops/action-gh-release uploads so the Windows job can reach those services..github/workflows/devcontainer.yml (1)
22-24:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winMissing
api.github.com:443- checkout will fail.The allowed-endpoints list includes
github.com:443but is missingapi.github.com:443. Theactions/checkoutstep at line 41 requires both endpoints and will fail withoutapi.github.com:443.🐛 Proposed fix
allowed-endpoints: >+ github.com:443 + api.github.com:443 registry-1.docker.io:443🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/devcontainer.yml around lines 22 - 24, The allowed-endpoints list is missing api.github.com:443 which causes the actions/checkout step to fail; update the allowed-endpoints block (the >+ block containing github.com:443 and registry-1.docker.io:443) to also include api.github.com:443 so the actions/checkout step can contact the GitHub API..github/workflows/docs.yml (1)
96-109:⚠️ Potential issue | 🟠 Major | ⚡ Quick winThe PDF publish path still isn't allowlisted for GitHub release uploads.
When
inputs.release_idis provided,softprops/action-gh-releaseneedsapi.github.comto create/update the release anduploads.github.comto send the PDF asset. This block list still omits both, so the upload step will fail even though the build succeeds.Suggested patch
allowed-endpoints: >+ _http._tcp.azure.archive.ubuntu.com:443 _https._tcp.archive.ubuntu.com:443 _https._tcp.security.ubuntu.com:443 + api.github.com:443 archive.ubuntu.com:443 azure.archive.ubuntu.com:443 azure.archive.ubuntu.com:80 files.pythonhosted.org:443 github.com:443 plantuml.com:443 plantuml.com:80 pypi.org:443 security.ubuntu.com:443 + uploads.github.com:443 www.plantuml.com:80🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/docs.yml around lines 96 - 109, The allowed-endpoints list is missing the GitHub endpoints required when using inputs.release_id with softprops/action-gh-release; add api.github.com:443 and uploads.github.com:443 to the allowed-endpoints block so the release creation and PDF asset upload can reach GitHub when the workflow step using softprops/action-gh-release runs with inputs.release_id.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Around line 26-32: The egress list for the release workflow is missing
uploads.github.com:443 (required by the softprops/action-gh-release step when
attaching release assets) and includes unnecessary pypi.org and
files.pythonhosted.org entries; update the allowed-endpoints block used by the
release job to add uploads.github.com:443 and remove pypi.org:443 and
files.pythonhosted.org:443 so the softprops/action-gh-release action can upload
assets (refer to the allowed-endpoints block and the softprops/action-gh-release
step in the workflow to locate where to change).
In @.github/workflows/run.yml:
- Around line 22-27: The test-cygwin job's allowed-endpoints list is missing
Chocolatey hosts needed by its choco install steps; update the allowed-endpoints
block for the test-cygwin job to include community.chocolatey.org:443 and
packages.chocolatey.org:443 so the choco install commands (invoked in the
test-cygwin job) can reach Chocolatey when egress-policy: block is enabled.
- Around line 85-133: The egress allowlist currently in the
egress-policy/allowed-endpoints block grants all matrix runners access to every
platform's endpoints; split this per-platform by using matrix.include entries so
each matrix job receives only its required allowlist. Modify the workflow's
matrix (symbol: matrix or matrix.include) to add three include objects (one for
ubuntu, one for macos, one for windows) and move the allowed-endpoints list into
job-level egress-policy overrides for each included matrix entry so ubuntu-only
endpoints (archive.ubuntu.com, esm.ubuntu.com, security.ubuntu.com, etc.) go to
the ubuntu include, macOS-only endpoints (formulae.brew.sh, gdmf.apple.com,
mesu.apple.com, etc.) to the macos include, and Windows/Chocolatey endpoints
(packages.microsoft.com, community.chocolatey.org, etc.) to the windows include.
Ensure the job that references the matrix uses the job-level
egress-policy/allowed-endpoints from the matching include instead of the single
global list.
In @.github/workflows/test.yml:
- Around line 43-44: Add a brief comment clarifying that the entries
dfetch.invalid:443 and giiiiiidhub.com:443 are intentionally invalid test
domains used to verify network blocking/allowlist behavior; update the same
allowlist block in the workflow to include that comment (e.g., a YAML comment
above or inline with those entries) so future maintainers understand their
purpose.
- Around line 17-25: The workflow's allowed-endpoints block is missing the API
host required by actions/checkout; update the allowed-endpoints list (the
"allowed-endpoints" key in the workflow) to include api.github.com:443 alongside
github.com:443 so actions/checkout can reach the GitHub API during checkout and
avoid immediate failures.
---
Duplicate comments:
In @.github/workflows/build.yml:
- Around line 25-39: The harden-runner egress allowlist for the step using
step-security/harden-runner (egress-policy: block, allowed-endpoints) is missing
endpoints required by the Windows build; update the allowed-endpoints list used
in that step to include community.chocolatey.org:443 and chocolatey.org:443 for
choco install zig, api.nuget.org:443 for dotnet tool install (NuGet), and
uploads.github.com:443 for softprops/action-gh-release uploads so the Windows
job can reach those services.
In @.github/workflows/devcontainer.yml:
- Around line 22-24: The allowed-endpoints list is missing api.github.com:443
which causes the actions/checkout step to fail; update the allowed-endpoints
block (the >+ block containing github.com:443 and registry-1.docker.io:443) to
also include api.github.com:443 so the actions/checkout step can contact the
GitHub API.
In @.github/workflows/docs.yml:
- Around line 96-109: The allowed-endpoints list is missing the GitHub endpoints
required when using inputs.release_id with softprops/action-gh-release; add
api.github.com:443 and uploads.github.com:443 to the allowed-endpoints block so
the release creation and PDF asset upload can reach GitHub when the workflow
step using softprops/action-gh-release runs with inputs.release_id.
In @.github/workflows/scorecard.yml:
- Around line 29-34: The workflow currently sets step-security/harden-runner
with egress-policy: block but leaves allowed-endpoints empty
(allowed-endpoints), which will block actions/checkout and network-requiring
steps; fix by populating allowed-endpoints with the necessary hostnames used by
GitHub Actions and the scorecard/upload steps (at minimum include github.com,
api.github.com, raw.githubusercontent.com, codeload.github.com,
uploads.github.com, and any scorecard endpoints), ensuring the allowed-endpoints
block for the step-security/harden-runner action includes these hosts so
actions/checkout and ossf/scorecard-action can access required resources.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 5ee75de5-4054-4974-a160-fbea9d680815
📒 Files selected for processing (10)
.github/workflows/build.yml.github/workflows/codeql-analysis.yml.github/workflows/dependency-review.yml.github/workflows/devcontainer.yml.github/workflows/docs.yml.github/workflows/python-publish.yml.github/workflows/release.yml.github/workflows/run.yml.github/workflows/scorecard.yml.github/workflows/test.yml
spoorcc
force-pushed
the
feature/harden-runners
branch
from
e53db44 to
9f350ca
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
9f350ca to
c5a7a41
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
c5a7a41 to
3f2349e
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
3f2349e to
112cd4e
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
112cd4e to
fe09b54
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
spoorcc
force-pushed
the
feature/harden-runners
branch
from
fe09b54 to
e9dd9d6
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
e9dd9d6 to
14d86a4
Compare
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (2)
.github/workflows/test.yml (1)
20-41:⚠️ Potential issue | 🔴 Critical | ⚡ Quick win
api.github.com:443is missing from the allowlist (regression risk).With
egress-policy: block,actions/checkoutand other GitHub API-backed operations can be denied withoutapi.github.com:443.🐛 Proposed fix
allowed-endpoints: >+ @@ giiiiiidhub.com:443 github.com:22 github.com:443 + api.github.com:443 motd.ubuntu.com:443🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/test.yml around lines 20 - 41, The allowed-endpoints list under the allowed-endpoints key in .github/workflows/test.yml is missing api.github.com:443 which can block actions/checkout and other GitHub API calls when egress-policy: block is enabled; update the allowed-endpoints block to include "api.github.com:443" alongside the existing entries so GitHub API-backed operations are permitted..github/workflows/run.yml (1)
89-136:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftShared matrix allowlist still over-permits cross-platform egress.
Line 89 applies one broad allowlist to all matrix variants, so each platform can reach endpoints used only by other platforms. This weakens the hardening objective; split allowlists per platform via
matrix.includeand pass platform-specific endpoint sets.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/run.yml around lines 89 - 136, The shared allowed-endpoints block currently applied to all matrix jobs over-permits cross-platform egress; update the workflow to define platform-specific allowlists and assign them via matrix.include entries instead of the global allowed-endpoints used now: create distinct endpoint sets (e.g., linux_allowed_endpoints, windows_allowed_endpoints, macos_allowed_endpoints) and move relevant hosts from the current allowed-endpoints list into each set, then add matrix.include entries for each platform variant that inject the proper platform-specific allowlist into the job configuration (reference the allowed-endpoints key and the matrix.include mechanism in .github/workflows/run.yml to locate where to split and assign the lists).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/docs.yml:
- Around line 55-61: The publish step using peaceiris/actions-gh-pages with
deploy_key (the landing-page publish path) requires SSH to github.com:22 but the
harden-runner allowed-endpoints block only allows github.com:443; update the
allowed-endpoints list (the allowed-endpoints YAML key) to include github.com:22
so the deploy_key SSH egress is permitted (or alternatively switch the
landing-page job to use a PAT/token auth instead of deploy_key if you prefer
avoiding SSH).
In @.github/workflows/python-publish.yml:
- Around line 23-32: The harden-runner allowed-endpoints block is missing the
artifact storage endpoints required by actions/upload-artifact@v7.0.1, causing
artifact uploads in the build job to fail; update the allowed-endpoints for the
harden-runner step (the block under uses: step-security/harden-runner@...) to
include the upload-artifact endpoints such as uploads.github.com:443 and
storage.googleapis.com:443 (and any other provider endpoints your artifacts
use), so both artifact upload steps in the build job can reach their storage
backends.
In @.github/workflows/run.yml:
- Around line 22-30: Add mirrors.kernel.org:443 to the allowed-endpoints list
used by the workflow so the cygwin-install-action can reach
https://mirrors.kernel.org/sourceware/cygwin/ when egress-policy is block;
update the allowed-endpoints block (the multi-line value under the
allowed-endpoints key that lists github.com:443, api.github.com:443, etc.) to
include mirrors.kernel.org:443 alongside the existing entries so the
cygwin-install-action can download packages successfully.
In @.github/workflows/scorecard.yml:
- Around line 29-43: The harden-runner egress allowlist (the step using
step-security/harden-runner with egress-policy: block and allowed-endpoints) is
missing endpoints needed by actions/upload-artifact v7; add
results-receiver.actions.githubusercontent.com:443 and the Azure storage pattern
*.blob.core.windows.net:443 to the allowed-endpoints list so artifact uploads
from upload-artifact@v7.0.1 can reach the results receiver and blob storage.
---
Duplicate comments:
In @.github/workflows/run.yml:
- Around line 89-136: The shared allowed-endpoints block currently applied to
all matrix jobs over-permits cross-platform egress; update the workflow to
define platform-specific allowlists and assign them via matrix.include entries
instead of the global allowed-endpoints used now: create distinct endpoint sets
(e.g., linux_allowed_endpoints, windows_allowed_endpoints,
macos_allowed_endpoints) and move relevant hosts from the current
allowed-endpoints list into each set, then add matrix.include entries for each
platform variant that inject the proper platform-specific allowlist into the job
configuration (reference the allowed-endpoints key and the matrix.include
mechanism in .github/workflows/run.yml to locate where to split and assign the
lists).
In @.github/workflows/test.yml:
- Around line 20-41: The allowed-endpoints list under the allowed-endpoints key
in .github/workflows/test.yml is missing api.github.com:443 which can block
actions/checkout and other GitHub API calls when egress-policy: block is
enabled; update the allowed-endpoints block to include "api.github.com:443"
alongside the existing entries so GitHub API-backed operations are permitted.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b39d7bb3-5ac9-4648-8464-c2b54dc50b2a
📒 Files selected for processing (10)
.github/workflows/build.yml.github/workflows/codeql-analysis.yml.github/workflows/dependency-review.yml.github/workflows/devcontainer.yml.github/workflows/docs.yml.github/workflows/python-publish.yml.github/workflows/release.yml.github/workflows/run.yml.github/workflows/scorecard.yml.github/workflows/test.yml
| - name: "Harden the runner (Block egress traffic: Only allow calls to allowed endpoints)" | ||
| uses: step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40 # v2.19.0 | ||
| with: | ||
| egress-policy: audit | ||
| egress-policy: block | ||
| allowed-endpoints: >+ | ||
| github.com:443 | ||
| api.github.com:443 | ||
| release-assets.githubusercontent.com:443 | ||
| pypi.org:443 | ||
| files.pythonhosted.org:443 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/python-publish.ymlRepository: dfetch-org/dfetch
Length of output: 4899
🏁 Script executed:
web_search
actions/upload-artifact endpoint requirements v7 what endpoints neededRepository: dfetch-org/dfetch
Length of output: 182
🌐 Web query:
actions/upload-artifact v7 GitHub Actions endpoints required storage backend
💡 Result:
The actions/upload-artifact@v7 action, powered by the @actions/artifact package (v5+), does not directly use the standard public REST API endpoints listed in GitHub Docs (e.g., POST /repos/{owner}/{repo}/actions/artifacts). Instead, it interacts with GitHub's internal ArtifactService via gRPC/Twirp protocols, specifically methods like CreateArtifact, FinalizeArtifact, ListArtifacts, and GetSignedArtifactURL. These generate signed URLs for uploading/downloading artifact data to Azure Blob Storage, GitHub's required storage backend for artifacts. Key evidence: - upload-artifact source code imports and calls @actions/artifact's uploadArtifact function. - @actions/artifact v4+ (used by v7) uses protobuf-defined ArtifactService with internal endpoints (e.g., "github.actions.results.api.v1.ArtifactService/CreateArtifact"), not public REST. - Dependencies include @azure/storage-blob (^12+), confirming Azure Blob as the backend; recent updates fixed Node.js 24 compatibility in storage-blob. - Public REST endpoints (e.g., GET /repos/{owner}/{repo}/actions/artifacts/{artifact_id}) are for metadata management, not core upload/download. - Artifacts are stored with configurable retention (default repo/org settings, max 90 days), counted against GitHub's storage quota (calculated every 6-12 hours). For self-hosting or custom backends, v7 is not supported on GHES (use v3); no official support for alternative storage.
Citations:
- 1: https://docs.github.com/en/rest/actions/artifacts
- 2: https://github.com/actions/upload-artifact
- 3: https://github.com/actions/toolkit/blob/main/packages/artifact/README.md
- 4: https://www.npmjs.com/package/@actions/artifact
- 5: https://github.com/actions/upload-artifact/blob/ef09cdac3e2d3e60d8ccadda691f4f1cec5035cb/src/upload/upload-artifact.ts
- 6: actions/upload-artifact@83b889d
- 7: actions/upload-artifact@905a1ec
- 8: https://github.com/actions/toolkit/blob/main/packages/artifact/RELEASES.md
🌐 Web query:
harden-runner step-security wildcard domain pattern support allowed-endpoints
💡 Result:
Yes, StepSecurity's Harden-Runner supports wildcard domain patterns in the allowed-endpoints configuration for egress policy blocking. This feature allows allowing egress traffic to all subdomains of a domain with a single rule using the * prefix, such as *.data.mcr.microsoft.com:443. This support was added in response to user feedback for handling dynamic endpoints like container registries (e.g., region-specific mcr.microsoft.com subdomains). It works in block mode (egress-policy: block). Example from official StepSecurity blog: steps: - name: Harden Runner uses: step-security/harden-runner@v2 with: egress-policy: block allowed-endpoints: > mcr.microsoft.com:443 *.data.mcr.microsoft.com:443 - run: docker pull mcr.microsoft.com/azure-cli Wildcard patterns can also be used in suppression rules for anomalous endpoint alerts and likely in Policy Store allowed endpoints. The format is domain:port with * for subdomains (e.g., *.example.com:443). It matches subdomains but not the root domain unless explicitly allowed.
Citations:
- 1: https://www.stepsecurity.io/blog/stepsecurity-harden-runner-now-supports-wildcard-domains-in-block-mode
- 2: https://docs.stepsecurity.io/guides/how-should-i-reduce-the-number-of-harden-runner-anomalous-endpoint-alerts
🌐 Web query:
results-receiver.actions.githubusercontent.com GitHub Actions artifacts endpoint
💡 Result:
results-receiver.actions.githubusercontent.com is an internal GitHub Actions endpoint used by self-hosted runners to report progress, upload logs, step summaries, and job results during workflow execution. It is part of the "Results" service in the GitHub Actions runner infrastructure. It is not the public endpoint for workflow artifacts (which are managed via REST API at api.github.com/repos/{owner}/{repo}/actions/artifacts). Instead, it handles real-time runner-to-GitHub communication for job execution data, including step updates, logs, and summaries. Key usage from official sources: - Required network access for self-hosted runners: https://results-receiver.actions.githubusercontent.com/.../ for reporting progress and uploading logs (actions/runner docs). - Listed in GitHub Docs for GitHub-hosted runners firewall rules, alongside *.blob.core.windows.net for artifacts, logs, etc. - GitHub Changelog (2023): Required for job summaries and logs; self-hosted runners must allow access to this host. - Runner PRs confirm it receives step updates, powers logs, uploads step summaries. Health check: curl https://results-receiver.actions.githubusercontent.com/health For public artifact management, use the documented REST API endpoints, not this runner-specific service.
Citations:
- 1: https://docs.github.com/en/actions/reference/runners/github-hosted-runners
- 2: https://github.com/actions/runner/blob/main/docs/checks/actions.md
- 3: https://github.blog/changelog/2023-01-31-github-actions-job-summary-updates
- 4: Update Runner to send step updates to Results actions/runner#2510
- 5: Do not give up if Results is powering logs actions/runner#2893
- 6: Use results for uploading step summaries actions/runner#2301
🌐 Web query:
blob.core.windows.net GitHub Actions artifacts upload endpoint Azure storage
💡 Result:
The standard GitHub Actions upload-artifact action does not directly upload to Azure Blob Storage endpoints like *.blob.core.windows.net. Instead, it uploads files to GitHub's internal artifact service via the runner's connection to the GitHub server (using classes like FileContainerServer in the open-source runner code), which stores artifacts in GitHub's cloud storage (likely S3 or similar). Artifacts are accessible via GitHub REST API endpoints like /repos/{owner}/{repo}/actions/artifacts/{artifact_id}/zip, not direct blob URLs. However, blob.core.windows.net appears in two main contexts related to GitHub Actions and Azure: 1. GitHub Enterprise Server (GHES) configuration: For self-hosted GHES instances, admins can configure Azure Blob Storage as the backend for storing Actions artifacts, logs, and caches. The blob endpoint is https://{storage-account}.blob.core.windows.net, where {storage-account} is your Azure storage account name. Runners upload to this storage via GHES configuration (using OIDC or connection string). See official GHES docs for setup (e.g., provide storage account name and core.windows.net suffix). 2. Custom uploads from workflows: To upload build files/artifacts directly to your own Azure Blob Storage from GitHub Actions workflows (hosted or self-hosted runners), use Azure CLI or third-party actions. The endpoint is https://{storage-account}.blob.core.windows.net/{container}/{blob-path}. Official Microsoft-recommended example using Azure CLI (from learn.microsoft.com, updated 2025): - name: Upload to blob storage uses: azure/CLI@v1 with: inlineScript: | az storage blob upload-batch --account-name {STORAGE_ACCOUNT_NAME} --auth-mode key -d '$web' -s . Replace {STORAGE_ACCOUNT_NAME} with your account (e.g., mystorage.blob.core.windows.net). Other popular actions: - bacongobbler/azure-blob-storage-upload: Uses az storage blob upload-batch. - LanceMcCarthy/Action-AzureBlobUpload: Supports connection string or service principal. - fixpoint/azblob-upload-artifact: Mimics actions/upload-artifact syntax for easy migration. No public "upload endpoint" exists for direct PUT to blobs from runners without authentication (SAS token, key, etc.). Always use authenticated methods. For GHES backend storage, it's internal to the GHES setup, not a user-facing endpoint.
Citations:
- 1: https://github.com/github-developer/upload-azure-blob
- 2: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-static-site-github-actions
- 3: https://docs.github.com/en/enterprise-server@3.16/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-azure-blob-storage
- 4: https://github.com/bacongobbler/azure-blob-storage-upload
- 5: https://github.com/marketplace/actions/azure-blob-storage-upload
- 6: https://docs.github.com/en/enterprise-server%403.17/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-azure-blob-storage
- 7: https://docs.github.com/v3/actions/artifacts
- 8: https://github.com/marketplace/actions/upload-a-build-artifact-to-azure-blob-storage
- 9: https://github.com/fixpoint/azblob-upload-artifact
- 10: https://www.github.com/actions/upload-artifact
- 11: https://docs.github.com/en/actions/advanced-guides/storing-workflow-data-as-artifacts
- 12: https://docs.github.com/en/enterprise-server@3.19/admin/github-actions/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-azure-blob-storage
- 13: https://github.com/actions/runner/blob/7310ba0a0825d467f958ab027f0fd99918291721/src/Runner.Plugins/Artifact/PublishArtifact.cs
🌐 Web query:
upload-artifact GitHub hosted runners required endpoints firewall egress policy
💡 Result:
For GitHub-hosted runners, no special firewall egress configuration is required as they have full outbound internet access. The query likely refers to self-hosted runners, where firewall egress policies must allow specific GitHub endpoints over HTTPS (port 443) for the actions/upload-artifact to function. Required outbound HTTPS endpoints/domains for self-hosted runners on github.com (allow recursively for CNAMEs): Essential operations: - github.com - api.github.com - *.actions.githubusercontent.com Downloading actions: - codeload.github.com Uploading/downloading artifacts, logs, caches (critical for upload-artifact): - results-receiver.actions.githubusercontent.com - *.blob.core.windows.net (Azure Blob Storage used by upload-artifact) Runner updates: - objects.githubusercontent.com - objects-origin.githubusercontent.com - github-releases.githubusercontent.com OIDC tokens: - *.actions.githubusercontent.com (already covered) Packages (if used): - *.pkg.github.com - ghcr.io Additional for workflows (e.g., LFS): - github-cloud.githubusercontent.com To test connectivity from the runner machine: curl -v https://api.github.com/zen curl -v https://codeload.github.com/_ping curl -v https://vstoken.actions.githubusercontent.com/_apis/health curl -v https://pipelines.actions.githubusercontent.com/_apis/health curl -v https://results-receiver.actions.githubusercontent.com/health Use the runner config script: ./config.sh --check --url https://github.com/OWNER/REPO --pat ghp_XXX GitHub does not recommend IP allowlisting due to frequent changes; use domain allowlisting instead. Retrieve current IPs via https://api.github.com/meta but monitor regularly. upload-artifact failures (e.g., ETIMEDOUT) explicitly reference ensuring access to these endpoints.
Citations:
- 1: https://github.com/actions/runner/blob/main/docs/checks/actions.md
- 2: https://docs.github.com/en/actions/reference/runners/github-hosted-runners
- 3: https://docs.github.com/en/actions/concepts/runners/communicating-with-self-hosted-runners
- 4: Artifact uploads have suddenly stopped working actions/upload-artifact#786
- 5: Actions artifact upload stalls when using self hosted runners actions/upload-artifact#623
- 6: [bug] actions/upload-artifact@v4 fails on Windows self-hosted runner actions/upload-artifact#733
- 7: https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/monitor-and-troubleshoot
🌐 Web query:
GitHub Actions harden-runner artifact upload failure missing endpoints logs
💡 Result:
The artifact upload failure in GitHub Actions when using step-security/harden-runner is caused by the security agent's egress policy blocking outbound connections to GitHub's artifact storage endpoints. Harden-Runner restricts network traffic to only explicitly allowed endpoints when configured with egress-policy: block. Key points: - Harden-Runner monitors and can block outbound network calls to prevent data exfiltration. - Artifact uploads require access to specific GitHub/Azure endpoints like *.blob.core.windows.net (for blob storage), results-receiver.actions.githubusercontent.com, and pipelines.actions.githubusercontent.com. - If these are missing from the allowed-endpoints list in the Harden-Runner step, uploads fail with errors like "missing endpoints," timeouts, ETIMEDOUT, or "Unable to make request." - Common error patterns match upload-artifact issues on self-hosted runners, but here it's due to the agent's blocking. Solution: 1. Run Harden-Runner in egress-policy: audit mode first to log all outbound calls and generate insights/recommended policy. 2. Review the security insights (linked in job summary) for network events during artifact upload steps. 3. Add the required endpoints to allowed-endpoints in block mode, e.g.: - uses: step-security/harden-runner@v2 with: egress-policy: block allowed-endpoints: > github.com:443 api.github.com:443 *.actions.githubusercontent.com:443 *.blob.core.windows.net:443 results-receiver.actions.githubusercontent.com:443 4. Harden-Runner auto-detects some GitHub endpoints like cache blobs, but artifact endpoints must be explicitly allowed or baselined. 5. Use the Policy Store feature for dynamic management without workflow changes. 6. Verify runner connectivity to GitHub endpoints using the official docs checklist. For self-hosted runners, ensure base network access; for GitHub-hosted, the agent enforces the policy strictly.
Citations:
- 1: https://www.stepsecurity.io/blog/harden-runner-github-action-now-auto-detects-cache-endpoints
- 2: https://togithub.com/step-security/harden-runner
- 3: https://github.com/step-security/harden-runner/blob/main/action.yml
- 4: https://docs.github.com/en/actions/concepts/runners/communicating-with-self-hosted-runners
- 5: https://github.com/actions/runner/blob/main/docs/checks/actions.md
- 6: Failed to upload artifact actions/upload-artifact#270
- 7: Actions artifact upload stalls when using self hosted runners actions/upload-artifact#623
- 8: [bug] actions/upload-artifact@v4 fails on Windows self-hosted runner actions/upload-artifact#733
- 9: Artifact uploads have suddenly stopped working actions/upload-artifact#786
- 10: [bug] V4 - Upload progress stalled. actions/upload-artifact#740
- 11: https://docs.stepsecurity.io/getting-started/quickstart-community-tier/getting-started-with-harden-runner
Add missing artifact storage endpoints to harden-runner allowlist.
The build job uploads artifacts twice (lines 49 and 54), but the current allowed-endpoints list omits the endpoints required by actions/upload-artifact@v7.0.1. Without access to these endpoints, artifact uploads will fail with connection timeouts or ETIMEDOUT errors in block mode.
Proposed fix
allowed-endpoints: >+
github.com:443
api.github.com:443
release-assets.githubusercontent.com:443
+ results-receiver.actions.githubusercontent.com:443
+ *.blob.core.windows.net:443
pypi.org:443
files.pythonhosted.org:443🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/python-publish.yml around lines 23 - 32, The harden-runner
allowed-endpoints block is missing the artifact storage endpoints required by
actions/upload-artifact@v7.0.1, causing artifact uploads in the build job to
fail; update the allowed-endpoints for the harden-runner step (the block under
uses: step-security/harden-runner@...) to include the upload-artifact endpoints
such as uploads.github.com:443 and storage.googleapis.com:443 (and any other
provider endpoints your artifacts use), so both artifact upload steps in the
build job can reach their storage backends.
| allowed-endpoints: >+ | ||
| github.com:443 | ||
| api.github.com:443 | ||
| release-assets.githubusercontent.com:443 | ||
| pypi.org:443 | ||
| files.pythonhosted.org:443 | ||
| community.chocolatey.org:443 | ||
| community.chocolatey.org:80 | ||
| packages.chocolatey.org:443 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
SHA="4ef15ca7fd18a18f1000989fcfd968e06d146ce8"
# Verify which domains/endpoints the pinned action expects for downloads/mirrors.
curl -fsSL "https://raw.githubusercontent.com/cygwin/cygwin-install-action/${SHA}/README.md" | rg -n "mirror|cygwin|setup|download|site" -C2
curl -fsSL "https://raw.githubusercontent.com/cygwin/cygwin-install-action/${SHA}/action.yml"Repository: dfetch-org/dfetch
Length of output: 7316
🏁 Script executed:
cat -n .github/workflows/run.yml | sed -n '15,40p'Repository: dfetch-org/dfetch
Length of output: 1266
🏁 Script executed:
# Check for any custom site configuration in the cygwin job
rg -A 20 "cygwin-install-action" .github/workflows/run.ymlRepository: dfetch-org/dfetch
Length of output: 801
🏁 Script executed:
# Check what the actual allowed-endpoints block contains in full context
rg -B 5 -A 15 "allowed-endpoints" .github/workflows/run.yml | head -60Repository: dfetch-org/dfetch
Length of output: 1785
Add mirrors.kernel.org:443 to the allowed-endpoints list for cygwin-install-action.
The cygwin-install-action at line 34 downloads Cygwin packages from https://mirrors.kernel.org/sourceware/cygwin/ by default (since no custom site is configured), but mirrors.kernel.org:443 is not in the allowed-endpoints block. With egress-policy: block, this causes the download phase to fail immediately.
Add to allowed-endpoints
mirrors.kernel.org:443
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/run.yml around lines 22 - 30, Add mirrors.kernel.org:443
to the allowed-endpoints list used by the workflow so the cygwin-install-action
can reach https://mirrors.kernel.org/sourceware/cygwin/ when egress-policy is
block; update the allowed-endpoints block (the multi-line value under the
allowed-endpoints key that lists github.com:443, api.github.com:443, etc.) to
include mirrors.kernel.org:443 alongside the existing entries so the
cygwin-install-action can download packages successfully.
| - name: "Harden the runner (Block egress traffic: Only allow calls to allowed endpoints)" | ||
| uses: step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40 # v2.19.0 | ||
| with: | ||
| egress-policy: audit | ||
| egress-policy: block | ||
| allowed-endpoints: >+ | ||
| github.com:443 | ||
| api.github.com:443 | ||
| raw.githubusercontent.com:443 | ||
| codeload.github.com:443 | ||
| uploads.github.com:443 | ||
| api.osv.dev:443 | ||
| www.bestpractices.dev:443 | ||
| api.securityscorecards.dev:443 | ||
| rekor.sigstore.dev:443 | ||
| fulcio.sigstore.dev:443 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/scorecard.yml | head -80Repository: dfetch-org/dfetch
Length of output: 2970
🏁 Script executed:
grep -A 10 "upload-artifact" .github/workflows/scorecard.ymlRepository: dfetch-org/dfetch
Length of output: 438
🌐 Web query:
actions/upload-artifact network endpoints requirements azure blob storage
💡 Result:
The query appears to seek information on using GitHub Actions' actions/upload-artifact with Azure Blob Storage, specifically network endpoints and requirements for uploads. However, actions/upload-artifact uploads to GitHub's artifact storage service, not directly to Azure Blob Storage (sources 9-12,28-30). For Azure Blob Storage uploads from GitHub Actions, use third-party actions like azure-blob-storage-upload or azblob-upload-artifact, or Azure CLI commands (sources 1-5). Azure Blob Storage upload uses REST API endpoints primarily via PUT requests: - Primary endpoint: https://{account}.blob.core.windows.net/{container}/{blob} (HTTPS recommended) (sources 19,20,24). - Key operations: - Put Blob: Creates/updates block, page, or append blobs. Requires x-ms-blob-type header (BlockBlob, PageBlob, AppendBlob), Content-Length, x-ms-version (e.g., 2023-08-04 or later). For block blobs up to ~5 GiB (preview expansion); larger use Put Block + Put Block List (sources 19,21,24,26). - Put Block: https://{account}.blob.core.windows.net/{container}/{blob}?comp=block&blockid={base64id}. Block size <=4 MiB (sources 26). - Put Block List: Commits blocks. Network requirements for Azure Blob Storage (from GitHub Actions runners): - Public access: Outbound HTTPS (port 443) to *.blob.core.windows.net. GitHub-hosted runners have internet access by default. - Private endpoints: Use privatelink.blob.core.windows.net. Requires VNet configuration, DNS resolution to private IP. GitHub runners cannot directly access private endpoints without public IP allowlisting or Azure service endpoints (sources 14,15,17). - Firewall rules: Allow GitHub runner IPs or disable public network access and use authorized networks. IP rules don't block same-region Azure traffic (source 15). - Scalability: Default 20,000 req/s, ingress/egress up to 25-50 Gbps per account (source 16). - Auth: Shared Key, SAS, Microsoft Entra ID (RBAC roles like Storage Blob Data Contributor), connection string in secrets (sources 1-5,19,27). For GitHub Actions artifacts (not Azure): Uses internal GitHub endpoints like /repos/{owner}/{repo}/actions/artifacts/{id}/zip (sources 9,29). Self-hosted runners may need firewall rules for uploads (source 11). Examples: - Third-party action: uses: bacongobbler/azure-blob-storage-upload@main with connection_string secret (source 1). - CLI: az storage blob upload-batch --account-name --auth-mode key -d $web -s . (source 5).
Citations:
- 1: https://github.com/marketplace/actions/azure-blob-storage-upload
- 2: https://github.com/marketplace/actions/upload-a-build-artifact-to-azure-blob-storage
- 3: https://github.com/fixpoint/azblob-upload-artifact
- 4: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-static-site-github-actions
- 5: https://docs.github.com/en/rest/actions/artifacts
- 6: https://github.com/actions/upload-artifact
- 7: https://github.com/actions/upload-artifact/blob/v4/README.md
- 8: https://github.com/actions/upload-artifact/tree/v4.2.0
- 9: https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints
- 10: https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security-limitations
- 11: https://aka.ms/premium_blob_quota
- 12: https://learn.microsoft.com/en-us/azure/storage/blobs/network-file-system-protocol-support
- 13: https://learn.microsoft.com/en-us/rest/api/storageservices/put-blob?tabs=shared-access-signatures
- 14: https://learn.microsoft.com/en-us/rest/api/storageservices/put-blob-from-url?tabs=microsoft-entra-id
- 15: https://azure.github.io/Storage/docs/application-and-user-data/basics/azure-blob-storage-upload-apis/
- 16: https://docs.microsoft.com/en-us/rest/api/storageservices/put-blob
- 17: https://learn.microsoft.com/en-us/rest/api/storageservices/put-block
- 18: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-upload-python
- 19: https://www.github.com/actions/upload-artifact
- 20: https://help.github.com/en/rest/actions/artifacts
- 21: https://docs.github.com/en/actions/advanced-guides/storing-workflow-data-as-artifacts
🌐 Web query:
actions/upload-artifact v7 network endpoints requirements documentation
💡 Result:
actions/upload-artifact v7 uses the @actions/artifact library (ESM-updated in v7, corresponding to @actions/artifact v6+), which communicates with internal GitHub Actions backend services via Twirp RPC over HTTPS (e.g., /twirp/... endpoints) and uploads content to Azure Blob Storage (e.g., productionresultssa*.blob.core.windows.net). Key network endpoints: - results-receiver.actions.githubusercontent.com:443 (artifact API for create/finalize) - .blob.core.windows.net:443 (Azure Blob Storage for file uploads, e.g., productionresultssa15.blob.core.windows.net) Public REST API endpoints (for listing/downloading/deleting, not uploading): /repos/{owner}/{repo}/actions/artifacts Requirements: - Runs on Node.js 24, requires Actions Runner >=2.327.1 (self-hosted runners). - Supports http_proxy/https_proxy environment variables for proxy usage (added proxy integration tests in v7). - For self-hosted runners behind firewalls: Open outbound HTTPS (443) to actions.githubusercontent.com domains (check https://api.github.com/meta | jq .domains.actions for specifics) and *.blob.core.windows.net. - Not supported on GHES (use v3 for GHES). - New in v7: archive=false for direct single-file upload (no zip), compression-level 0-9. Upload flow: Create artifact container (POST), upload chunks (PUT to blob), finalize (PATCH). Uses runner's special token, not public GITHUB_TOKEN/PAT.
Citations:
- 1: https://github.com/actions/upload-artifact/releases/tag/v7.0.0
- 2: https://github.com/actions/upload-artifact
- 3: https://docs.github.com/en/rest/actions/artifacts?apiVersion=2026-03-10
- 4: https://docs.github.com/en/rest/actions/artifacts
- 5: Question: What API is used to upload artifacts? actions/upload-artifact#180
- 6: https://www.npmjs.com/package/@actions/artifact
- 7: https://github.com/actions/toolkit/blob/main/packages/artifact/README.md
- 8: [bug] V6 Upload progress stalled behind proxy while V5 works actions/upload-artifact#747
- 9: actions/upload-artifact@v6...v7.0.0
- 10: https://github.com/actions/toolkit/blob/main/packages/artifact/src/internal/client.ts
🌐 Web query:
results-receiver.actions.githubusercontent.com GitHub artifacts upload endpoint
💡 Result:
results-receiver.actions.githubusercontent.com is an internal GitHub endpoint used by GitHub Actions runners and the @actions/artifact library for communicating with the "Results Service". This service handles uploading step updates, step summaries, diagnostic logs, and likely artifacts during workflow execution. It is accessed via the ACTIONS_RESULTS_URL environment variable, which provides the base URL (e.g., https://results-receiver.actions.githubusercontent.com). The library constructs paths like /twirp/... for RPC calls using the runtime token (ACTIONS_RUNTIME_TOKEN) for authentication. It is not a public REST API for direct artifact uploads; public artifact management uses documented endpoints under /repos/{owner}/{repo}/actions/artifacts. These internal endpoints are undocumented, not intended for external use, and restricted to the workflow run context with special runner tokens.
Citations:
- 1: Question: What API is used to upload artifacts? actions/upload-artifact#180
- 2: https://github.com/actions/toolkit/blob/main/packages/artifact/src/internal/shared/artifact-twirp-client.ts
- 3: Update Runner to send step updates to Results actions/runner#2510
- 4: actions/download-artifact@9140050
- 5: https://github.com/actions/toolkit/blob/main/packages/artifact/src/internal/client.ts
- 6: https://github.com/actions/runner/blob/7310ba0a0825d467f958ab027f0fd99918291721/src/Runner.Plugins/Artifact/PublishArtifact.cs
🌐 Web query:
step-security harden-runner wildcard endpoints blob.core.windows.net support
💡 Result:
Yes, StepSecurity's Harden-Runner supports wildcard endpoints, including for blob.core.windows.net, since version 2.4.0. This feature allows using patterns like ".data.mcr.microsoft.com:443" or ".blob.core.windows.net:443" in the allowed-endpoints list when egress-policy is set to 'block'. For GitHub Actions cache/artifacts specifically, which use varying *.blob.core.windows.net subdomains, Harden-Runner auto-detects and allows the specific cache endpoint (since v1.5.0), eliminating the need for manual whitelisting or wildcards in most cases. However, wildcards can still be used explicitly if preferred, as users have requested and implemented in some workflows (e.g., Azure/karpenter-provider-azure PR). No security concerns are raised against using the wildcard for GitHub cache endpoints, though broad whitelisting is generally discouraged for non-essential traffic.
Citations:
- 1: Support wildcard domains step-security/harden-runner#236
- 2: https://www.stepsecurity.io/blog/stepsecurity-harden-runner-now-supports-wildcard-domains-in-block-mode
- 3: allow-endpoints should accept wildcards or better handle Github artifact hosts step-security/harden-runner#83
- 4: https://www.stepsecurity.io/blog/harden-runner-github-action-now-auto-detects-cache-endpoints
- 5: fix: harden harden-runner egress policy Azure/karpenter-provider-azure#477
Missing artifact upload endpoints in harden-runner allowlist will block artifact uploads.
This job uses actions/upload-artifact@v7.0.1 to upload results.sarif, but the harden-runner block mode allowlist is missing the required endpoints. Version 7 of upload-artifact communicates with GitHub's artifact service via results-receiver.actions.githubusercontent.com and uploads files to Azure Blob Storage at *.blob.core.windows.net domains. Without these endpoints, artifact uploads will be blocked.
🐛 Proposed fix
allowed-endpoints: >+
github.com:443
api.github.com:443
raw.githubusercontent.com:443
codeload.github.com:443
uploads.github.com:443
+ results-receiver.actions.githubusercontent.com:443
+ *.blob.core.windows.net:443
api.osv.dev:443
www.bestpractices.dev:443
api.securityscorecards.dev:443🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/scorecard.yml around lines 29 - 43, The harden-runner
egress allowlist (the step using step-security/harden-runner with egress-policy:
block and allowed-endpoints) is missing endpoints needed by
actions/upload-artifact v7; add
results-receiver.actions.githubusercontent.com:443 and the Azure storage pattern
*.blob.core.windows.net:443 to the allowed-endpoints list so artifact uploads
from upload-artifact@v7.0.1 can reach the results receiver and blob storage.
spoorcc
force-pushed
the
feature/harden-runners
branch
from
14d86a4 to
b7925bf
Compare
2 participants
Summary by CodeRabbit