[actions] add step security runner by varunsh-coder · Pull Request #2659 · nvm-sh/nvm

varunsh-coder · 2021-11-22T15:47:58Z

This PR adds the step-security/harden-runner GitHub Action to the lint.yml workflow to restrict outbound calls. This is a new GitHub Action that provides runtime security for GitHub hosted runner. As of now, it can be used to set allowed outbound traffic for workflow runs to prevent credential exfiltration. You can see the results of running this on a fork here.

@ljharb would love to pilot step-security/harden-runner on this workflow to get feedback and improve the experience. Do let me know if you have any questions. Thanks!

ljharb · 2021-11-23T00:25:19Z

.github/workflows/lint.yml

+          allowed-endpoints:
+            agent.api.stepsecurity.io:443
+            github.com:443
+            nodejs.org:443
+            registry.npmjs.org:443


is there any way an individual step could be annotated rather than broadly allowing every step to access these endpoints?

Hi @ljharb , individual steps are annotated in the web UI/ API (thanks for that idea BTW) and I can detect and alert that a step has called an endpoint it was not supposed to, but technically I cannot stop it from doing so. Configuring the firewall per step would be hard. Let me know if it would be better to just detect and alert at a step level v.s. restricting at a job level.

What if i use the runner multiple times, and each time, I define a brand new set of allowed endpoints, that only apply to further steps?

Thats an interesting idea. I can experiment with it. It might lead to lot of steps that call harden-runner which may make the workflow file look cluttered. It would be ideal if this could be done without the additional steps. Let me think about it.

ljharb · 2021-11-23T00:25:49Z

.github/workflows/lint.yml

+        with:
+          allowed-endpoints:
+            agent.api.stepsecurity.io:443
+            github.com:443


for example, the actions/checkout action both always should be able to access github.com, and also, is the only part of the action that needs to

Yes, I understand what you are saying, and that would be ideal. I wrote about this in the comment above.

.github/workflows/lint.yml

ljharb

This looks good; linking it to main means you can't ever make breaking changes; should it be pointed to a branch or tag?

Any update about per-step allowances?

varunsh-coder · 2021-12-01T00:00:05Z

This looks good; linking it to main means you can't ever make breaking changes; should it be pointed to a branch or tag?

Any update about per-step allowances?

Pointed it to the latest tag.

No update on per-step restriction. Will take more time to address it...

varunsh-coder · 2021-12-06T22:07:36Z

Hi @ljharb made few updates to the PR.

Updated tag to v1 (now managing it in same way as actions/ checkout)
Added egress-policy as an input in the action with default of block. One of the jobs has it as audit just to pilot it.
The web UI now has annotations (tooltip/ dialog) about why certain calls are made by an Action based on KB.
Thanks for the feedback!

ljharb · 2021-12-07T07:17:37Z

Could we add this to all the other workflows as well?

varunsh-coder · 2021-12-07T18:16:11Z

Could we add this to all the other workflows as well?

Hi @ljharb would love to add to other workflows.

That is also a great opportunity to pilot the automation to add it to workflows.

Secure workflows is an open source API to make it easy to add harden-runner (and token permissions) to workflows, but as of now it is only available via a web UI. Instead it would be better to have the automation create PRs. One of the challenges here is that the first PR would be to add egress-policy: audit and after a couple of runs another PR will add the allowed-endpoints.

To create PRs via automation, I could write a GitHub App or an OAuth App (or both). I believe that in an OAuth App the access is granted to all repos for a given user. So, I think GitHub App would be preferred for this scenario. Would you be ok to pilot a GitHub app for this? It would need write access to code, workflows, and PRs. It will be open source (part of secure workflows).

Please let me know. Thanks!

ljharb · 2021-12-07T19:16:58Z

I'm a bit confused; can't the PR here just start out setting allowed endpoints to "nothing", and then it would fail, and i could update the list to get the PR to pass?

varunsh-coder · 2021-12-07T23:45:08Z

I'm a bit confused; can't the PR here just start out setting allowed endpoints to "nothing", and then it would fail, and i could update the list to get the PR to pass?

I added harden-runner to all workflows except the windows-npm.yml since it only works on Linux.
For couple of jobs, there were no outbound calls (just a single statement - run: 'echo tests completed'), so set egress-policy: block.
The automation rebase workflow is failing because GitHub API is returning the PRs rebaseable attribute as false. Not sure why that is the case...

ljharb · 2021-12-07T23:49:00Z

I'm not sure either, don't worry about it tho.

varunsh-coder · 2021-12-08T00:54:44Z

Hi @ljharb based on the outbound traffic in shellcheck.yml workflow, I realized that homebrew sends data to Google Analytics. It can be opted-out of and removing www.google-analytics.com from the allowed list also works - the call is dropped and the workflow still works (tried on a fork). Do let me know if you want me to remove www.google-analytics.com from the allowed list for shellcheck.yml workflow in PR.

ljharb · 2021-12-08T01:53:49Z

Let's both remove it and set HOMEBREW_NO_ANALYTICS=1 in the env.

varunsh-coder · 2021-12-08T03:48:17Z

Let's both remove it and set HOMEBREW_NO_ANALYTICS=1 in the env.

Done

.github/workflows/lint.yml

ljharb · 2021-12-10T23:00:46Z

ha, i couldn't figure out why the dockerfile_lint job was failing, but turns out it's the harden runner doing its job: https://github.com/nvm-sh/nvm/compare/4aa8f97c9d9a9df72ab7845e859184c7c932d6d6..6cc90a4b8daa44ad3050828c2bf98fa77a16bf90

ljharb · 2021-12-10T23:01:15Z

@varunsh-coder this is another reason why a separate PR status would be super helpful, because then it would be very obvious when a workflow had requests blocked by the harden runner.

varunsh-coder · 2021-12-10T23:05:18Z

@varunsh-coder this is another reason why a separate PR status would be super helpful, because then it would be very obvious when a workflow had requests blocked by the harden runner.

I will work on this. Will also show in annotation in the workflow when a request is blocked.

Don't know how I missed those endpoints in the dockerfile_lint job. May be it was using cached tools/ dependencies earlier, so those endpoints were not called...

jen801

#2659

jen801 · 2022-01-03T21:17:19Z

.github/workflows/lint.yml

+        with:
+          allowed-endpoints:
+            agent.api.stepsecurity.io:443
+            github.com:443


jen801

Duplicate of #
Duplicate of #

jen801 · 2022-01-03T21:21:18Z

.github/workflows/latest-npm.yml

+        with:
+          allowed-endpoints:
+            iojs.org:443
+            nodejs.org:443


.github/workflows/toc.yml

[actions] add step security runner

6cc90a4

ljharb reviewed Nov 23, 2021

View reviewed changes

This was referenced Nov 25, 2021

Restrict traffic per step step-security/agent#54

Open

Decide whether agent API URL should be explicitly listed step-security/agent#55

Closed

ljharb approved these changes Nov 30, 2021

View reviewed changes

varunsh-coder force-pushed the varunsh-coder-patch-1 branch from 9685ee8 to 399600a Compare December 6, 2021 23:47

ljharb force-pushed the varunsh-coder-patch-1 branch from 399600a to e609a39 Compare December 7, 2021 07:17

ljharb reviewed Dec 8, 2021

View reviewed changes

.github/workflows/lint.yml Outdated Show resolved Hide resolved

ljharb force-pushed the varunsh-coder-patch-1 branch from 23691c8 to 4aa8f97 Compare December 10, 2021 22:30

ljharb changed the title ~~Secure workflow lint.yml~~ [actions] add step security runner Dec 10, 2021

ljharb added the testing Stuff related to testing nvm itself. label Dec 10, 2021

ljharb force-pushed the varunsh-coder-patch-1 branch from 4aa8f97 to 6cc90a4 Compare December 10, 2021 22:51

ljharb merged commit 6cc90a4 into nvm-sh:master Dec 10, 2021

varunsh-coder deleted the varunsh-coder-patch-1 branch December 18, 2021 00:55

jen801 reviewed Jan 3, 2022

View reviewed changes

.github/workflows/lint.yml

with:

allowed-endpoints:

agent.api.stepsecurity.io:443

github.com:443

Copy link

jen801 Jan 3, 2022

Choose a reason for hiding this comment

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

**

jen801 reviewed Jan 3, 2022

View reviewed changes

.github/workflows/latest-npm.yml

with:

allowed-endpoints:

iojs.org:443

nodejs.org:443

Copy link

jen801 Jan 3, 2022

Choose a reason for hiding this comment

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

.github/workflows/toc.yml

Uh oh!

Conversation

varunsh-coder commented Nov 22, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ljharb left a comment

Choose a reason for hiding this comment

Uh oh!

varunsh-coder commented Dec 1, 2021

Uh oh!

varunsh-coder commented Dec 6, 2021

Uh oh!

ljharb commented Dec 7, 2021

Uh oh!

varunsh-coder commented Dec 7, 2021

Uh oh!

ljharb commented Dec 7, 2021

Uh oh!

varunsh-coder commented Dec 7, 2021

Uh oh!

ljharb commented Dec 7, 2021

Uh oh!

varunsh-coder commented Dec 8, 2021

Uh oh!

ljharb commented Dec 8, 2021

Uh oh!

varunsh-coder commented Dec 8, 2021

Uh oh!

Uh oh!

ljharb commented Dec 10, 2021

Uh oh!

ljharb commented Dec 10, 2021

Uh oh!

varunsh-coder commented Dec 10, 2021

Uh oh!

jen801 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jen801 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants