search

openjs-foundation / cross-project-council

OpenJS Foundation Cross Project Council
https://openjsf.org/
MIT License
429 stars 149 forks source link

Add thelinuxfoundation User as an Admin to All OpenJS Projects #1327

Open bensternthal opened 1 week ago

bensternthal commented 1 week ago

Problem

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

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

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 commented 1 week ago

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

ctcpip commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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

mcollina commented 1 week ago

+1 to @ovflowd proposal

mhdawson commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 6 days ago

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 commented 5 days ago

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: https://github.com/openjs-foundation/cross-project-council/issues/1327#issuecomment-2206482430

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:

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 commented 5 days ago

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.

joesepi commented 1 day ago

Meeting notes: