Closed Bug 1795988 Opened 3 years ago Closed 3 years ago

new github organization for the innovation org

Categories

(mozilla.org :: Github: Administration, enhancement)

Product:
mozilla.org
Component:
Github: Administration
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mheavers, Assigned: cknowles)

Details

Attachments

(1 file)

Github Logo for Org
6.74 KB, image/png
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:105.0) Gecko/20100101 Firefox/105.0

Steps to reproduce:

The Innovation Org, under Imo Udom, would like to establish its own Github organization with the ability to administer its own repositories (create, delete, set private, add members, etc).

The Innovation org plans to spin up quite a number of prototypes and repos, often non-consumer facing, which might frequently need to be deleted or changed. Speed of experimentation / iteration is a primary focus here.

We'd like to know what our options are. I will file this bug and let Imo fill in any additional detail.

Thank you Mike. Yes, our Innovation Ecosystems Org needs the speed and flexibility to experiment quickly. This will often mean creating prototypes in repos that will need to be changed or deleted often. The expectations that we have on our teams to move quickly will be significantly hampered by the current Mozilla org GitHub restrictions. A separate org gives us the flexibility we need while reducing the overhead burden from all parties.

Alright, so let me restate somethings, ask a question or two, and enlist secops for their opinions.

So, you'd like your own org - Do you have a proposed name for it? Mozilla-Innovation? (not wedded to it, merely stringing words together)

Generally we do keep private repo creation closed to members as it usually goes against the ability to know what things are for, as private repos go orphaned easily, which leads to questions and concerns particularly if there are any security incidents.

But, if the org in question is relatively small, and relatively task focused, these concerns can be alleviated. So I don't think there's a concern with giving members of the new org private repo creation rights.

Unfortunately, the other two main asks are more of a sticking point. Sadly there's no granular way to give you repo deletion rights - it also conveys repo transfer rights, which is an ongoing legal concern (related to licensing in particular), hence the policy to not allow that access to members of the orgs. I'd recommend either archiving repos, or filing bugs here for deletion if you deem that more appropriate. Noting that deletions are unlikely to be super high-priority, and thus unlikely to block you, like the inability to create private repos would.

Finally - there's the "add members to the org" - this probably isn't something you need to do on a regular basis - once the initial bolus of users is added (which I'll ask later as we get closer to creating things). Note that repo admins still have total control over the access to their repos, and can add (and remove) outside collaborators at any time. This does NOT need any advanced rights to the org. And since this org will be in GitHub Enterprise from the beginning, you'll still need GHE admins involved to enable users to sign in initially to the org.

Members of the org can create their own teams, create repos, manage all of those.

I think that covers most of what I saw - I'm happy to have further conversations around this if you'd like - my google calendar is as up to date as I can make it.

At this point, per our runbooks, I hand the bug to secops to get their opinions, and see what I missed. Austin - let me know if you have any concerns.

Flags: needinfo?(asargent)

I think Chris is asking the right questions so we can get a better idea on how to assist. I don't have any further questions at this time, but as the conversation continues the SecOps team is happy to help where applicable.

Flags: needinfo?(asargent)

Thank you - so just to make sure I understand - if we have this org:

  • you will handle the assignment of admins via ticket requests from us.
  • We cannot delete repos, but we can create them, archive them, and switch them between private and public.

Are there any other limitations we should be aware of that would differ from what you might expect from setting up a github account completely independent of Mozilla that you might anticipate affecting us? I'm thinking of things like managing secrets, hooks, actions, integrations, access, as well as the implementation of common systems like CI / deploying to a variety of cloud hosts, monitoring, etc.?

Your understanding is largely correct as to the spelled out elements from comment 2 - only change would be "assignment of admins" - we as owners would handle bringing people into the org as members, existing members with repo permissions can assign rights to the repos they admin. Teams can be created and maintained by members, and assigned to repos by people that have the admin rights.

The only things that are definitely reserved to the owners are things that affect the entire org. Installation of most apps & actions is an owner level thing - and normally secops has us keep the adding of apps to new repos as owner level - but we could make the apps and or actions able to be available to ALL repos once they're installed - so the blockage would be only on initial induction of the app/action into the org. But that would require secops signoff, and they'll likely have specific questions.

Secrets - if they're at the repo level, then they are managed by the repo admins - it's only if you want org level secrets that we get involved. Entirely depends on your workflow. And it's likely less onerous than you're thinking - but we'd need to discuss specifics to be sure.

Most CI and the like is handled via github apps or actions - so they would be in the "initial install at least" level of owner involvement.

As to access, repo access is managed by the repo admins - owners are happy to advise, and execute changes if needed, you know better than we do what's needed at that level, so policy says we don't make repo changes until we've talked to the people with the highest existing permissions for that repo. (lots of our procedures are around old/abandoned/unknown things ... thankfully not the case here.)

A mostly correct list of management right comparisons from github is here - though there's some nuances that aren't covered in that sheet. (several of the things are configurable beyond what that sheet has - ask and we can talk about it)

At this point, I'm thinking a meeting where we can go over specifics and figure out how we're all going to work this out would probably be the best use of our time. Myself and Austin Sargent would (I think) be the minimum. Hal Wine and Andrew Erickson would be optional if you like.

Discussed further in a meeting - The concerns around adding people to repos has been addressed.

The main thing that remained was the desire, in addition to creating Private repos, would be to allow arbitrary actions across the new org. Setting this to NI Austin again so he can look in and ask questions about this, or approve it.

As we continue into this creation - I need some information:

  1. Proposed name
  2. list of users that you'll want as members of the org

Thanks.

Flags: needinfo?(asargent)

This type of format is certainly against the norm, however we do have an exception process in place for scenarios like this. Due to the nature of the Innovation org, we'll approve of the usage to bring in actions on a per-repo basis. We feel this strikes a fair balance between usability and security while allowing the Innovation team to have the free will to move quickly.

I'll note this approval of an exception in the appropriate locations once a name of the org has been resolved.

Flags: needinfo?(asargent)

Following up on this, after chatting with some folks with the nature of the innovation org, we'll allow actions to be used globally within the organization to be created in GitHub. This does come with risk carried with it for the Innovation team however. We can help out in incidents or issues should they occur, but because we are removing ourselves from the vetting process of the actions, we cannot guarantee or confirm that that they are not without malicious intent is all.

After the name of the org has been decided, as stated above I will be sure to note the approval of exception.

This all sounds good, thank you @asargent.

As for the name, we'll go with mozilla-ocho (Mozilla Ocho).

The initial list of contributors (Github usernames) are:

heaversm
jwhiting
stlhood
imo8
ajbouh
kwellingtonmoz
javaun

Let me know if you need more info than that. Provided I have the ability to add additional members and change permissions, I'm the only one that needs to be set up with admin rights at this time.

So, adding members to the org entire is an owner thing that requires approvals and special list access in phonebook - so it's going to be a bug to us here to add members.

However, note that to add users to repos (NOT the entire org) is something that any repo admins can do.

If that changes the list of users you want, or if you want to have a deeper conversation about ownership of the org, please let me know. But before I start making the org, I'd like to make sure you're cool with it.

To sum up - you'll be able to create private/public repos, you can use any action across the org. for org level operations you'll file a bug here, so we can get the right approval processes, and make sure that there aren't any foot-guns in play.

Please confirm we're in alignment - and I'll get the ball rolling, else, probably a quick catchup meeting to align would help.

Flags: needinfo?(mheavers)

Confirmed. Thank you. Happy to hop on a call though if it is helpful to walk through anything on your end.

Flags: needinfo?(mheavers)

Alright, I'll start the ball rolling. I'll need other teams in IAM to help setup the Auth0 setup. I'll ping here when I have things ready for you.

As I create - I have some more asks - it's fine if the answer is "Later, I'll let you know" but I'm in there right now, so it's quick to change.

  1. Is there a short form description for the org?
  2. Is there a URL that people could go to for more info?
  3. is there a public email (perhaps a google group?) for the org?
  4. is there an image you'd like for the org?
Flags: needinfo?(mheavers)

Did initial setups, and filed the issue for SAML integration - https://mozilla-hub.atlassian.net/browse/SE-3367

Thanks :cknowles - will get you some answers to those questions, and appreciate the update on SAML.

Flags: needinfo?(mheavers)

[:cknowles] - here's what we'll go with for now:

  1. Short Form Description:

Innovation and Experiments @ Mozilla

  1. URL:

Nothing yet - working with marketing on this.

  1. Public Email:

hello@mozillaocho.com

  1. Image:

Attached to this ticket.

Attached image Github Logo for Org —

Alright, initial values applied to the org, initial security settings applied. The previously noted exceptions of allowing private repo creation, and allowing any/all actions has been set.

Now we're just waiting for the IAM folk to get the Auth0 setup done, and we'll invite people and this should be ready for handover.

Alright, IAM folk came through, SAML is enabled and tested, and I've sent out an intro email and the needed invites to the list of members from comment 9

At this point, this bug is pretty close to done - just leaving it open for any immediate setup related questions that occur.
https://github.com/Mozilla-Ocho

Going forward the right place for help would be filing a bug to this component.
Information around general process can be found on the wiki : https://wiki.mozilla.org/GitHub
The main item usually used is the request to add new members - template can be found in the wiki - as of the writing this link is the template.

Email to ghe-admins@m.c will reach us, as will chat to matrix in the github-admin channel

Please take a look around and let me know if there are any questions.

Thank you so much Chris! Will keep you posted if anything comes up but everything looks great so far. Appreciate your quick attention to all of this and thorough explanations.

Alright - with the lack of screaming I'm going to close this out - if you need anything, please reach out.

Assignee: nobody → cknowles
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED

(In reply to Chris Knowles [:cknowles] from comment #21)

Alright - with the lack of screaming I'm going to close this out - if you need anything, please reach out.

Thank you all for your help!

Hi Chris - we added a new Design Technologist to the team and I'd like to get him added as a member of the org (https://github.com/orgs/Mozilla-Ocho) - his github username is rupertparry (https://github.com/rupertparry). Do we need a separate ticket for that?

Yes, please. there's a template for the bug requests in the wiki documentation here for that access. If there isn't a team, just mention that there's no team to be added to.

You can close this request - Rupert is no longer with us.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: