add github management policies dir #155

ljharb · 2023-04-18T17:40:19Z

Closes #153, assuming the tooling should live in a separate repo.

This is just an initial doc to get things started; happy to take any and all feedback.

Signed-off-by: Jordan Harband <[email protected]> Signed-off-by: ctcpip <[email protected]> Signed-off-by: Amanda L Martin <[email protected]> Co-authored-by: Jordan Harband <[email protected]> Co-authored-by: ctcpip <[email protected]> Co-authored-by: Amanda L Martin <[email protected]>

README.md

tpepper · 2023-04-20T08:24:51Z

policies/access.md

+
+## Github Org Membership
+
+ Membership in the Github org should be freely given - it inherently confers no permissions or privileges, only a badge on the user's profile if they enable it - and it _does_ allow for easier team management. Someone should only be removed from the org in extreme circumstances where their association with OpenSSF would be problematic, and people should be encouraged to remain in the org in perpetuity.


This feels different than many open source projects. Especially for a relatively new and also broad umbrella foundation, I worry that this freely given perpetual membership even if only a weak badging, might encourage confusion on what is or is not officially part, sponsored by, under consideration within the auspices of the foundation. That type of confusion and contention has already been a bit of a problem for the OpenSSF org.

I personally would prefer a simple and collaborative open membership. But I also want clarity of mission and propose and that to be easily discovered and difficult to confuse.

Perhaps this is less of an issue if leadership (ie: certain team memberships in the org?) roles are clearly marked. But GitHub team memberships tend to be opaque. I’m not sure if there is maybe an org setting which would allow team members be viewed by non org members. Or if not…alternatively if anybody can get org membership, I guess anybody could ask for org membership to be able to see team membership? Or GH team members defined by in repo yaml configs? Still not great UX though.

Except perhaps in orgs with a very small number of members, it's unlikely that anyone would interpret anything about an individual's org membership alone beyond baseline participation. (And if they did, that would be quite misguided.)

@tpepper OpenSSF is not itself an open source project, and this is how TC39 operates, which I think is more analogous.

I agree that it's not great UX that the only way to be on a team is to be in the org, but it seems a worthy tradeoff for me.

bobcallaway · 2023-04-25T11:23:15Z

off of a quick glance, no concerns from me; tagging @di @lehors @steiza who may not have gotten the original notification to review.

steiza

I love the proposal to use teams to manage access!

I have some questions about how to open up membership to the OpenSSF organization broadly, and how to manage the consequences of that.

policies/access.md

steiza

Minor: there's a bunch of places I'd like us to switch Github to the official GitHub.

Other than that, I'm a strong supporter of organizing permissions via teams, and I'm willing to give membership to github.com/ossf for anyone who asks a try.

ljharb · 2023-05-08T18:20:31Z

@steiza thanks, brand compliance now achieved 👍

policies/access.md

steiza

Looks good to me; thanks!

lehors

LGTM

ctcpip

minor grammar/punctuation issues

policies/access.md

AevaOnline

LGTM!

jeffmendoza · 2023-05-30T15:54:01Z

policies/access.md

+    This is the parent team for SIGs. Every SIG should have a subteam contained within this one. All SIG subteams must start with `sig-` for consistency.
+- [Projects](https://github.com/orgs/ossf/teams/projects)
+    This is the parent team for projects. Every project (eg scorecard, AO) should have a subteam contained within this one.
+    Teams for individual repositories go under here, which start with `repo-`, but team names may otherwise be unconstrained.


Following PLP(below) projects will need teams for each access level (eg scorecard-read, scorecard-traige, scorecard-write, scorecard-maintain)

In the extreme yes, but we'd only create these as needed, since most repos don't need this granularity atm.

I don't think this is just an extreme case. Take a look at the BP-WG group:
https://github.com/orgs/ossf/teams/wg-best-practices/members
https://github.com/orgs/ossf/teams/wg-best-practices/repositories

All those people who had some kind of access to any of the 6 repos now have write/maintain access to all of them. In an effort to reduce the manual configuration of groups. repos and access-levels will be consolidated and people will be getting access they don't need and/or shouldn't have.

Sure, that's a fair point. However, when I created that specific team i was told that all members should have Write. There's a tradeoff here balancing convenience and "least privilege", and since Write is a pretty non-dangerous privilege, it seemed like a worthy one.

If we end up needing to do this for the majority of repos, then we should absolutely document it as the default approach, but we're not there yet today.

There's a tradeoff here balancing convenience and "least privilege"

This is exactly my point. Without granular teams per repo and access level, we are reducing our security and going against PLP. Without some sort of automation or config-as-code way to manage the teams, convenience will undermine the goals of the teams mandate.

I think that is something we can iterate on as well - automation is worth considering but in practice is often overkill, and the goal here isn't strict PLP, but a safer balance.

jeffmendoza · 2023-05-30T15:55:09Z

policies/access.md

+
+## Teams, not Individuals
+
+Access to repositories will be granted only to GitHub teams, not to individuals. A repo may have any number of teams added to it, with the appropriate access levels.


How to we enforce this?

Allstar has a policy to nag if any individuals have write/admin access, we could use this.

We already have an auditing tool; see https://github.com/ossf/github-org-access-scraper.

jeffmendoza · 2023-05-30T15:56:07Z

policies/access.md

+
+ Permission levels should be as high as they need to be, and no higher.
+
+- There's few settings that justify Admin access over Maintain, so prefer Maintain.


Looks like Maintain doesn't allow setting up branch protection. A lot of or repos don't have this setup Will org admins set this up, if we don't have Admin access to our own repos?

Yes; org admins (the PM team, primarily) will be available to do any repo administration that repo owners lack access to do.

This doesn't seem like a tenable solution. If encouraging project owners to not have admin on the repos, they really need an easy way to read settings, and an automated way to apply changes.
https://gitlab.eclipse.org/eclipsefdn/security/otterdog is a tool we could use to do this, for example.

This is definitely something we can iterate on; in my experience managing large github orgs (or in my own 400+ single-maintainer projects), maintainers rarely need Admin more than a handful of times over the lifetime of a repo, and as long as the friction is minimal when it's needed, it's "fine".

Note also that the language here is "prefer"; if anyone feels strongly that they want admin over a repo, then imo they can have it.

ljharb · 2023-05-30T16:40:39Z

I believe all comments have been addressed and this seems to have sufficient approvals.

I'll land this later today if there's no further feedback/objections.

SecurityCRob

+1

policies/access.md

ljharb requested a review from a team April 18, 2023 17:40

ljharb force-pushed the policies branch from f9e54f0 to 43f1370 Compare April 18, 2023 17:45

ctcpip reviewed Apr 18, 2023

View reviewed changes

README.md Outdated Show resolved Hide resolved

ljharb force-pushed the policies branch 2 times, most recently from 8f40d6c to ad92748 Compare April 18, 2023 18:11

ljharb mentioned this pull request Apr 19, 2023

TAC question: where should ossf github org policies/tools live? #153

Closed

tpepper reviewed Apr 20, 2023

View reviewed changes

steiza reviewed May 2, 2023

View reviewed changes

policies/access.md Outdated Show resolved Hide resolved

policies/access.md Outdated Show resolved Hide resolved

policies/access.md Outdated Show resolved Hide resolved

steiza reviewed May 8, 2023

View reviewed changes

ljharb force-pushed the policies branch from d808f14 to d329668 Compare May 8, 2023 18:20

steiza mentioned this pull request May 15, 2023

Create access management policies for github.com/ossf #164

Closed

steiza reviewed May 17, 2023

View reviewed changes

policies/access.md Outdated Show resolved Hide resolved

ljharb force-pushed the policies branch from d329668 to 2503200 Compare May 23, 2023 17:33

steiza approved these changes May 24, 2023

View reviewed changes

bobcallaway approved these changes May 24, 2023

View reviewed changes

lehors approved these changes May 24, 2023

View reviewed changes

hythloda approved these changes May 30, 2023

View reviewed changes

hythloda requested review from tpepper and ctcpip May 30, 2023 13:53

ctcpip suggested changes May 30, 2023

View reviewed changes

policies/access.md Outdated Show resolved Hide resolved

policies/access.md Outdated Show resolved Hide resolved

policies/access.md Outdated Show resolved Hide resolved

di approved these changes May 30, 2023

View reviewed changes

AevaOnline requested review from AevaOnline and removed request for tpepper May 30, 2023 15:16

AevaOnline approved these changes May 30, 2023

View reviewed changes

jeffmendoza reviewed May 30, 2023

View reviewed changes

ljharb force-pushed the policies branch 2 times, most recently from be0cea8 to cb7c1a9 Compare May 30, 2023 16:38

ctcpip approved these changes May 30, 2023

View reviewed changes

SecurityCRob self-requested a review May 30, 2023 17:50

SecurityCRob approved these changes May 30, 2023

View reviewed changes

jsoref reviewed May 30, 2023

View reviewed changes

policies/access.md Outdated Show resolved Hide resolved

ljharb force-pushed the policies branch from cb7c1a9 to 765a64f Compare May 30, 2023 23:32

joshuagl reviewed May 31, 2023

View reviewed changes

policies/access.md Show resolved Hide resolved

ljharb force-pushed the policies branch from 765a64f to 97efc10 Compare May 31, 2023 17:56

ljharb merged commit 97efc10 into main May 31, 2023

ljharb deleted the policies branch May 31, 2023 17:57

ljharb mentioned this pull request May 31, 2023

policy: add github org membership section #171

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add github management policies dir #155

add github management policies dir #155

ljharb commented Apr 18, 2023

tpepper Apr 20, 2023

ctcpip Apr 20, 2023

ljharb Apr 20, 2023

bobcallaway commented Apr 25, 2023

steiza left a comment

steiza left a comment

ljharb commented May 8, 2023

steiza left a comment

lehors left a comment

ctcpip left a comment

AevaOnline left a comment

jeffmendoza May 30, 2023

ljharb May 30, 2023

jeffmendoza May 30, 2023

ljharb May 30, 2023

jeffmendoza May 30, 2023

ljharb May 30, 2023

jeffmendoza May 30, 2023

ljharb May 30, 2023

jeffmendoza May 30, 2023

ljharb May 30, 2023

jeffmendoza May 30, 2023

ljharb May 30, 2023 •

edited

Loading

ljharb commented May 30, 2023

SecurityCRob left a comment


		## Github Org Membership

		Membership in the Github org should be freely given - it inherently confers no permissions or privileges, only a badge on the user's profile if they enable it - and it _does_ allow for easier team management. Someone should only be removed from the org in extreme circumstances where their association with OpenSSF would be problematic, and people should be encouraged to remain in the org in perpetuity.


		## Teams, not Individuals

		Access to repositories will be granted only to GitHub teams, not to individuals. A repo may have any number of teams added to it, with the appropriate access levels.


		Permission levels should be as high as they need to be, and no higher.

		- There's few settings that justify Admin access over Maintain, so prefer Maintain.

add github management policies dir #155

add github management policies dir #155

Conversation

ljharb commented Apr 18, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bobcallaway commented Apr 25, 2023

steiza left a comment

Choose a reason for hiding this comment

steiza left a comment

Choose a reason for hiding this comment

ljharb commented May 8, 2023

steiza left a comment

Choose a reason for hiding this comment

lehors left a comment

Choose a reason for hiding this comment

ctcpip left a comment

Choose a reason for hiding this comment

AevaOnline left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ljharb May 30, 2023 • edited Loading

Choose a reason for hiding this comment

ljharb commented May 30, 2023

SecurityCRob left a comment

Choose a reason for hiding this comment

ljharb May 30, 2023 •

edited

Loading