OpenJS Github Continuity Policy

[bensternthal]

Problem

The OpenJS Foundation currently lacks admin access to most projects under its umbrella. This limitation prevents the foundation from:

• Archiving projects without reachable maintainers
• Managing projects and users when maintainers are inactive or unreachable
• Adding or removing admins in emergency situations

These are not hypotheticals, and we have experienced all three of them this year.

Proposed Solution

We propose granting the "thelinuxfoundation" user admin rights to all OpenJS projects and establishing this as a requirement for new projects. This practice is now standard for most Linux Foundation organizations.

The OpenJS Foundation is hosted by the Linux Foundation (LF) and contracts with LF IT to provide staffing and various technical services for its projects.

About thelinuxfoundation User

• OpenJS staff do not have access to this user
• Access to "thelinuxfoundation" is restricted to LF IT administrators
• All access to this account is logged via 1Password
• Hardware tokens are required for access
• The account is governed by established IT rules for handling admin service accounts

Next Steps

1. Discuss with CPC and seek approval
2. If approved:
   a. Update project progression docs.
   b. File an issue in each project to have the user added
3. If not approved:
   a. Discuss alternatives that achieve the same outcome

[ljharb]

Instead of granting a user account admin privileges, could this be done with Github Enterprise features?

[ctcpip]

I am opposed to any shared account or similar mechanisms that obfuscate the identity of the individual performing an action -- especially when that action requires elevated privileges.

Use of a shared account is also a violation of GitHub's ToS both for individuals and corporations.

The alternative is to add individuals as organization administrators where necessary, but that option also has its downsides. The big question is whether solving for the problem is worth the added risk. If we were going to proceed, I'm also not sure that LF IT administrators would be the best individuals to be granted admin privileges on project organizations.

[PaulaPaul]

We discussed this on the Ecosystem call today - when projects want to opt in for LFX Insights, doesn't that also require a service account of some sort? @edsadr was going to discuss this with @UlisesGascon.
Service accounts are slightly different than a shared administrative account - having a service account that enables metrics capture may also support 'emergency access' needs. Service account credentials are not shared; any access to a service account would need to be managed just like access to any other credential but the account itself would be known and the process for elevated access could be defined. (also tagging @rginn here)

[ctcpip]

That option wouldn't resolve the concerns above, and introduces new risks.

A service account (or a machine account in GH parlance), must still be associated with a single individual who is responsible for that account and anything the account does. Such an account must only be "used exclusively for performing automated tasks". These types of accounts must only be granted the privileges they absolutely need for automation. Granting them administrator privileges adds a number of risks, and this option would obfuscate user identity even further.

[ovflowd]

Welp, it feels like the solution is requesting to GitHub to set all our projects (orgs on GitHub) on Enterprise mode, then they should add them under a "corporation" namely OpenJS Foundation. That's a GitHub Enterprise feature and it is something invisible to regular users, just visible to the "Enterprise" and allows advanced user management, etc...

But Im not familiar of Open Source foundations doing this. My employer HubSpot does it tho

[bensternthal]

@ovflowd yep seems like I need to look into that as a possible option.

[mcollina]

+1 to @ovflowd proposal

[mhdawson]

I think we should be a bit careful with respect to the Node.js orgs as we have credits/stuff from GitHub that we need to make sure we don't mess up.

It would be much easier/lighter touch to just add some admins from the Linux Foundation.

[bensternthal]

I am happy so support more than one approach here. Let me poke around on github orgs a bit more and propose two paths for projects.

[ctcpip]

Michael is right. The path of least resistance is definitely just adding the necessary individual(s) as owners directly to the orgs.

Embracing the Enterprise functionality, if possible, is probably the best long-term solution. But it's non-trivial to implement (as Michael pointed out) and adds additional administrative overhead. It's effectively a project -- which is fine, but that will block us resolving the problems mentioned in the OP if we don't also proceed with the short-term solution of adding individual(s) as owners directly.

I would suggest that any new policy for adding non-organization contributors as organization owners stipulate that this is optional, at least for larger or very active projects where there is clearly sufficient redundancy/availability in administration. For example, I am not convinced that the Node organization would benefit from adding additional non-Node contributors as organization owners and thereby increasing the security risk footprint for no added value.

[WaleedAshraf]

Don't openjsf do regular checks that projects always have reachable maintainers and when/if that fails it automatically removes the project from openjsf umbrella?

I think projects should clearly define the on-call/emergency process before they join, and which should be regularly checked by openjsf.

[erickzhao]

Electron is a strong -1 on this for our project, as we don’t think the current proposals would work for us.

As stated by @ctcpip, a shared admin service account is a violation of the GitHub Terms of Service and adds an added security risk for us as an organization—we’ve already been reducing our usage of bot accounts and following the principle of least privilege for years.

We also enforce SAML authentication for the Electron organization at the enterprise level, and we don’t want to add any non-governance members into our SAML provider as that would weaken our identity systems.

Note

To @ovflowd's point, we wouldn’t be able to join an OpenJS Foundation enterprise organization since we already have a multi-organization enterprise account configured.

To also echo @ctcpip’s thoughts on large organizations: #1327 (comment)

I would suggest that any new policy for adding non-organization contributors as organization owners stipulate that this is optional, at least for larger or very active projects where there is clearly sufficient redundancy/availability in administration. For example, I am not convinced that the Node organization would benefit from adding additional non-Node contributors as organization owners and thereby increasing the security risk footprint for no added value.

We believe we already have a solid governance model in place to mitigate the need for external admin intervention.

Here’s what we do as an org:

• We wrote and open-sourced our own Permissions as Code infrastructure (electron/sheriff) that handles GitHub permissions across all of our organization’s repositories.
  • Organization members can be added and removed from teams and repositories by editing a YAML configuration and submitting a pull request.
  • This system also provides alerting for suspicious repository activity on GitHub (e.g. deleting releases, pushing to main, etc.)
• Our governance charter defines that the Infrastructure Working Group has GitHub admin permissions and can already handle mitigation processes with more context than an external IT administrator. All current members of the Infra WG are working full-time on Electron.

Overall, we think this might be a good solution for smaller projects with fewer maintainers, but would cause a lot of overhead and risk for our use-case with limited upside. +1 from us on making any policy optional.

cc @mlaurencin

[tobie]

As a sidenote, and to @erickzhao's point above, we could make a distinction between at large and impact projects here; given the additional requirements around governance that we have for impact projects.