Repository navigation
Node.js Maintainers Threat Model: Access per Group table #1618
Description
Hi folks, as part of Node.js Security initiative we have created a table of access per group based on available roles under Node.js org. We'd like to get some feedback/review. Feel free to edit the table if you think something is wrong (I can read the history and update our hackmd table).
The idea is to have a table of permissions and then look at the threats each role has and its impact on the nodejs organization.
Access per Group
Levels: (-) none, (r) read, (w) write, (a) admin/owner (inspiration from https://mason.gmu.edu/~montecin/UNIXpermiss.htm)
Additional notes:
- While some teams can have access to a resource, like the
secrets, they might have different access level internally based on sub-groups. - Some individuals and team have access such write in different GitHub repositories in the org, like Working groups or subteams.
Note
¹ - All repositories with code that get published or has some impact on nodejs/core
² - Releasers has access to run CI during CI Embargo (Security Release)
| Resource | External people | Contributors - Core/Triagers/WG | Build - Test/Infra/Admin | Admin - TSC/Releasers/Moderation | Security Stewards/Triagers/External | GitHub - Actions/Plugins |
|---|---|---|---|---|---|---|
| HackerOne | - | --- | --- | aw- | www | -- |
| MITRE | - | --- | --- | a-- | w-- | -- |
| private/node-private | - | --- | www | aw- | w-w | -- |
| private/security-release | - | --- | --- | a-- | ww- | -- |
| private/secrets | - | --- | www | a-- | --- | -- |
| nodejs/node | r | wrr | rrw | awa | rrr | wr |
| nodejs/deps¹ | r | rrr | rrw | arr | rrr | wr |
| nodejs/build (GH) | r | rrr | rrw | awa | rrr | wr |
| nodejs/node-core-utils | r | rrr | rrw | awa | rrr | wr |
| npm account | - | - | -a- | a-- | --- | -- |
| Jenkins CI - test | r | ww- | wwa | -w²- | --- | ww |
| Jenkins CI - release | - | --- | -ww | -w- | --- | -- |
| Infra - test | - | w-- | aaa | ww- | -w- | ww |
| Infra - release | - | --- | -ww | -w- | --- | -- |
| Build infra | - | --- | -a- | --- | --- | -- |
| Website Infra | - | --- | -a- | a-- | --- | -- |
| Youtube | - | --w | --- | a-- | --- | -- |
| Zoom | r | rrw | --- | a-- | --- | -- |
| 1Password | - | --r | --- | a-- | --- | -- |
| Social media accounts | - | --- | --- | --- | --- | -- |
| Email (nodejs-sec) | r | rrr | rrr | awr | wrr | rr |
| Email (io.js aliases) | r | --- | -a- | w-- | --- | -- |
Repos under nodejs which do not include code, are not covered as they cannot lead to the threats listed.
pkgjs.org is excluded as it does not include code/repos that make it into Node.js binaries
Activity
RafaelGSS commentedon Sep 12, 2024
ping @nodejs/build @nodejs/releasers for visibility
richardlau commentedon Sep 12, 2024
What is the difference between infra/admin in "Build - Test/Infra/Admin"?
richardlau commentedon Sep 12, 2024
Perhaps "Admin" is supposed to encompass the two Jenkins admins groups (one for the test CI and one for the release CI)? But in that case it would only apply to the CI servers (and not the test/release machines themselves or any other resource on the list).
richardlau commentedon Sep 12, 2024
"Website Infra" needs to be clarified, or probably split. The Build WG in general doesn't have access to the Vercel set up.
richardlau commentedon Sep 12, 2024
Re.
² - Releasers has access to run CI during CI Embargo (Security Release)the whole "Jenkins CI - test" row is different for CI Embargo (e.g. external and collaborators lose read access during the Embargo (but TSC and security triage retain read access)).RafaelGSS commentedon Sep 12, 2024
Yes, that's my understanding. cc: @UlisesGascon
Right, when we were discussing it we weren't aware of the roles and resources for nodejs.org, so we put Website Infra. Maybe @nodejs/web-infra can help us splitting it.
Would make sense to add an additional row for Embargo CI?
mhdawson commentedon Sep 12, 2024
We actually have
I can't quite remember but I think as a simplification we grouped all of the non-infra admins together. It might make more sense to have
test admins (test, github bot admins, test jenkins admins)
infra admins
release admins (release jenkins, release admins)
which I would shorten to test/release/infra
@richardlau what do you think?
richardlau commentedon Sep 12, 2024
If it makes it easier to summarise, sure. But e.g. test, github bot admins, test jenkins admins are three separate groups and being in one of those groups does not imply being in one of the others.
test/release/infra definitely makes more sense than test/infra/admin.
mhdawson commentedon Sep 13, 2024
@richardlau understood about them being different groups, in a number of cases we've combined to make the table/assessment feasible.
That means that we may estimate the risk. If that leads to risks that are highlighted as the top risk being not quite right we might adjust but if the results are risks that even with the overestimate are acceptable the simplication is worth it and we'll leave as is.
flakey5 commentedon Sep 13, 2024
@RafaelGSS
Access for Website Teams
1 The release worker isn't deployed yet (nodejs/build#3461)
2 Not being used yet (nodejs/node#52343)
3 Some have read access to parts of the Cloudflare account. Members of web-infra can deploy the release-cloudflare-worker via Github actions which writes to the Cloudflare account.
Blank for ones already included in the table above. Omitted archived repositories (nodejs/nodejs.org-archive, nodejs/node.js.org, nodejs/nodejs.dev)
Threats
Can't get the table to format but,
1 When the release worker gets deployed
2 No packages are being published yet but will be in the future (nodejs/doc-kit#10)
@ovflowd can you comment on access to Vercel?
RafaelGSS commentedon Dec 9, 2024
Closing it in favour of nodejs/security-wg#1414.
Feel free to review and suggest changes. @flakey5 we'll include this table in a separate document as the threat might be slightly different.