Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add github management policies dir #155

Merged
merged 1 commit into from
May 31, 2023
Merged

add github management policies dir #155

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,9 @@ Official communications occur on the [TAC mailing list](https://lists.openssf.or
Informal discussions occur in the TAC channel of the [OpenSSF Slack](https://slack.openssf.org/).
To join, use the following [invite link](https://join.slack.com/t/openssf/shared_invite/zt-xoktwsef-VzM~b22G2gfT_~4woTTsQA).

Use [Github Issues](https://github.com/ossf/tac/issues) to request and discuss agenda items.
Use [GitHub Issues](https://github.com/ossf/tac/issues) to request and discuss agenda items.

If you need support any any part of the process please email [[email protected]](mailto:[email protected]?subject=[GitHub Membership]%20Source%20Github%20TAC).


## Meetings
Expand Down
6 changes: 3 additions & 3 deletions elections/tac-and-scir-election-process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,14 +6,14 @@ This document outlines the election process for the OpenSSF Technical Advisory C
## Voter Eligibility (Electorate) Self-Nomination Process

Any contributor to OpenSSF working groups, SIGs, or projects is eligible to participate in the election.
Valid contributions include: commits or submitted pull requests via Github; public edits or comments on Google docs or other work products associated with OpenSSF; consistent participation in working groups; posting messages to any mailing list or on Slack; and beyond that any other form of positive engagement with OpenSSF activities.
Valid contributions include: commits or submitted pull requests via GitHub; public edits or comments on Google docs or other work products associated with OpenSSF; consistent participation in working groups; posting messages to any mailing list or on Slack; and beyond that any other form of positive engagement with OpenSSF activities.
The voter eligibility form asks you for an example of your contributions; this is merely to make it easier for the Election Officials and OpenSSF staff to validate eligibility.
If you have in any way been involved in or care about OpenSSF, but are in doubt as to whether your contribution “counts”, please fill it out anyways, and we will follow up.

The Voter Eligibility Self-Nomination Form will be sent out via email along with the election announcement.
The Voter Eligibility Self-Nomination Form will be sent out via email along with the election announcement.
(Note: The form is only open during the nomination period)


## TAC Self-Nomination Process

The OpenSSF Technical Advisory Council (TAC) is composed of seven total individuals, four of whom are elected annually.
Expand Down
35 changes: 35 additions & 0 deletions policies/access.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
# GitHub Access Management Policy

## Teams, not Individuals
ljharb marked this conversation as resolved.
Show resolved Hide resolved

Access to repositories will be granted only to [GitHub teams](https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams#team-visibility), not to individuals. A repo may have any number of teams added to it, with the appropriate access levels.

## Team Structure

Teams will be nested, using parent/child relationships, as needed. A child team will implicitly have any privileges its parent team does, so the most deeply nested team should be the one with the most privileges.

### Top-level teams

Note: this list is intentionally not exhaustive.

- [TAC](https://github.com/orgs/ossf/teams/tac)
This team is for current TAC members. Individuals should be added or removed from this team to reflect current membership.
- [Staff](https://github.com/orgs/ossf/teams/staff)
This team is for OpenSSF staff members. Individuals on the top-level team are there as a catch-all, but may be moved to subteams as the need arises.
- [PMs](https://github.com/orgs/ossf/teams/pms)
This teams is for PMs, who often need Maintain or Admin access on repos.
- [Marketing](https://github.com/orgs/ossf/teams/marketing)
- [Working Groups](https://github.com/orgs/ossf/teams/working-groups)
This is the parent team for Working Groups. Every WG should have a subteam contained within this one. All WG subteams must start with `wg-` for consistency.
- [SIGs](https://github.com/orgs/ossf/teams/sigs)
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 (e.g. 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.
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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.


## Principle of Least Privilege

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

- There are few settings that justify Admin access over Maintain, so prefer Maintain.
- Explicit Read access has an advantage: users with Read can be assigned to issues and requested as PR reviewers even if they're not the author.