Discussion - OpenSSF GitHub Enterprise Account Structure and Shared Responsibility Model
Closed this issue · 13 comments
The OpenSSF staff members have been administering various repo-level configurations. Now all the projects are under the newly acquired enterprise account, we'd like TAC to advise on how to best use the enterprise account, and the shared responsibility model ( who does what).
The motivation for this issue is a post mortem we conducted. The prepared documents have sensitive information. We'd like to have this issue discussed without recording and invitation only.
I think there are some high level things that I can talk about with experience on GUAC and what we would be looking for. For now I'll just highlight the main goals I can see OSSF staff helping with on the enterprise account front:
- Protect the org from bad things (bad actors or mistakes made by benign actors), e.g. bad actor attempting to delete all repos, benign actor clicking the wrong permission.
- Enforce the toolbelt and/or secure architecture with minimal impact to development workflows.
- Give access to LF/OSSF github apps
Versus a full post mortem with sensitive information, are there high level recommendations the staff has for best practices in the OpenSSF github? The TAC can then review the go-forward recommendations and have a dialog to round-table the recommendations are inclusive of the OSS community and TAC operating processes supporting TI needs.
I'm just going to leave this here 😊
Versus a full post mortem with sensitive information, are there high level recommendations the staff has for best practices in the OpenSSF github? The TAC can then review the go-forward recommendations and have a dialog to round-table the recommendations are inclusive of the OSS community and TAC operating processes supporting TI needs.
I think we need to separate the concerns. This issue is focusing on the account structure, and the shared responsibilities. Once we have consensus on these higher level boundaries, then we can focus on project level best practices which have been set and followed by some projects.
Versus a full post mortem with sensitive information, are there high level recommendations the staff has for best practices in the OpenSSF github? The TAC can then review the go-forward recommendations and have a dialog to round-table the recommendations are inclusive of the OSS community and TAC operating processes supporting TI needs.
I think we need to separate the concerns. This issue is focusing on the account structure, and the shared responsibilities.
Once we have consensus on these higher level boundaries, then we can focus on project level best practices which have been set and followed by some projects.
@ossf/tac
Please express your vote and comments on the following:
1.) GitHub Enterprise Account Structure
Review the table on ~page 7 of the gdoc - do you prefer the Hybrid or Federated model? In the option to FOr pull request workflows from outside collaborators, the option is currently set to "Require approval for first time contributors", but should it be changed to "require approval for all outside collaborators"?
2.) Shared Responsibility Model
Review the table on ~page 9 of the gdoc - do you have any feedback on the TODOs and/or next steps listed there?
3.) “ossf” GitHub Tasks and Permissions
Review the table on ~page11 of the gdoc - do you have any feedback on the tasks/permissions assignments?
4.) Access Management
Review the table on ~page 12 in the godc - do you have any feedback on the two privileged roles detailed in the table?
5.) Namespace
Review the paragraph in ~page 12 in the godc - do you have any feedback on a mandate for all TIs to move, or making it optional?
6.) Audit events
Review the three audit events on ~page 17 in the godc - should these three events be monitored?
Please express your vote and comments on the following:
1.) GitHub Enterprise Account Structure
Review the table on ~page 7 of the gdoc - do you prefer the Hybrid or Federated model? In the option to For pull request workflows from outside collaborators, the option is currently set to "Require approval for first time contributors", but should it be changed to "require approval for all outside collaborators"?
I believe all projects and SIGs should report to a WG, and use the Hybrid model. I would support legacy Sigstore still report to the TAC (vs a WG), but recommend Sigstore to roadmap using change management to the OpenSSF hybrid model. Over time, there may be projects under their own organization that become OpenSSF members. We will also need a process for them to come under hybrid management if we do this.
After reading https://www.csoonline.com/article/1290656/researchers-demo-new-ci-cd-attack-techniques-in-pytorch-supply-chain-attack.html, I believe it makes sense to change the setting. Can someone who manages an enterprise Github account speak to the additional effort that might be involved with this change? I would be curious to hear from SigStore on this, including the creation from approval permissions RSTUF noticed?
2.) Shared Responsibility Model
Review the table on ~page 9 of the gdoc - do you have any feedback on the TODOs and/or next steps listed there?
I like the proposed shared responsibility model. I think we will need to do roadmapped change management to get to this point. Being part of a foundation with an enterprise policy creates brand consistency, operational consistency, and should be a value for projects being a part of foundation support in that some of the responsibilities are shared. It's a shift, so we'll have to have some grace as we mature
3.) “ossf” GitHub Tasks and Permissions
Review the table on ~page11 of the gdoc - do you have any feedback on the tasks/permissions assignments?
Resolve https://github.com/ossf/tac/issues/235 and https://github.com/ossf/tac/issues/237 and update this table as needed for the "Review contributions to ensure TAC/SCIR electorate"
4.) Access Management
Review the table on ~page 12 in the godc - do you have any feedback on the two privileged roles detailed in the table?
No feedback.
5.) Namespace
Review the paragraph in ~page 12 in the godc - do you have any feedback on a mandate for all TIs to move, or making it optional?
My recommendation would be to use https://best.openssf.org/SCM-BestPractices/#recommendations in 4.2, and to use change management to slowly align the org with top level namespace. Go in small increments, and prior to the change document where URLs might need updated. Keep the WG and stakeholders closely involved in the migration.
6). Audit events
Review the three audit events on ~page 17 in the godc - should these three events be monitored?
--Protected branch destroy: what is the impact of this happening and the likelihood of happening? For the Sigstore example, I think this could be a high enough concern we would want to implement it. Can this be scoped to graduated TIs?
--Repo Access: See above.
--org.update_member_respoitory_creation_permission. What is the liklihood and impact of this happening? What does it take to be an organization member? It may be that once this role is reached, they can create repos in their role.
Please express your vote and comments on the following: 1.) GitHub Enterprise Account Structure Review the table on ~page 7 of the gdoc - do you prefer the Hybrid or Federated model? In the option to For pull request workflows from outside collaborators, the option is currently set to "Require approval for first time contributors", but should it be changed to "require approval for all outside collaborators"?
I believe all projects and SIGs should report to a WG, and use the Hybrid model. I would support legacy Sigstore still report to the TAC (vs a WG), but recommend Sigstore to roadmap using change management to the OpenSSF hybrid model. Over time, there may be projects under their own organization that become OpenSSF members. We will also need a process for them to come under hybrid management if we do this.
After reading https://www.csoonline.com/article/1290656/researchers-demo-new-ci-cd-attack-techniques-in-pytorch-supply-chain-attack.html, I believe it makes sense to change the setting. Can someone who manages an enterprise Github account speak to the additional effort that might be involved with this change? I would be curious to hear from SigStore on this, including the creation from approval permissions RSTUF noticed?
2.) Shared Responsibility Model Review the table on ~page 9 of the gdoc - do you have any feedback on the TODOs and/or next steps listed there?
I like the proposed shared responsibility model. I think we will need to do roadmapped change management to get to this point. Being part of a foundation with an enterprise policy creates brand consistency, operational consistency, and should be a value for projects being a part of foundation support in that some of the responsibilities are shared. It's a shift, so we'll have to have some grace as we mature
3.) “ossf” GitHub Tasks and Permissions Review the table on ~page11 of the gdoc - do you have any feedback on the tasks/permissions assignments?
Resolve https://github.com/ossf/tac/issues/235 and https://github.com/ossf/tac/issues/237 and update this table as needed for the "Review contributions to ensure TAC/SCIR electorate"
4.) Access Management Review the table on ~page 12 in the godc - do you have any feedback on the two privileged roles detailed in the table?
No feedback.
5.) Namespace Review the paragraph in ~page 12 in the godc - do you have any feedback on a mandate for all TIs to move, or making it optional?
My recommendation would be to use https://best.openssf.org/SCM-BestPractices/#recommendations in 4.2, and to use change management to slowly align the org with top level namespace. Go in small increments, and prior to the change document where URLs might need updated. Keep the WG and stakeholders closely involved in the migration.
6). Audit events Review the three audit events on ~page 17 in the godc - should these three events be monitored? --Protected branch destroy: what is the impact of this happening and the likelihood of happening? For the Sigstore example, I think this could be a high enough concern we would want to implement it. Can this be scoped to graduated TIs? --Repo Access: See above. --org.update_member_respoitory_creation_permission. What is the liklihood and impact of this happening? What does it take to be an organization member? It may be that once this role is reached, they can create repos in their role.
@sevansdell Thank you for investing time in this, really appreciate the support.....can we leave resolving issue 235 and 237 outside of the account structure and shared responsibility model discussion? Those two issues are around operational procedures and processes, they are outside of the scope of this discussion?
Please express your vote and comments on the following: 1.) GitHub Enterprise Account Structure Review the table on ~page 7 of the gdoc - do you prefer the Hybrid or Federated model? In the option to For pull request workflows from outside collaborators, the option is currently set to "Require approval for first time contributors", but should it be changed to "require approval for all outside collaborators"?
I believe all projects and SIGs should report to a WG, and use the Hybrid model. I would support legacy Sigstore still report to the TAC (vs a WG), but recommend Sigstore to roadmap using change management to the OpenSSF hybrid model.
I don't know what this actually means in practice. The Sigstore GitHub organization is already part of the OpenSSF enterprise and thus is already "hybrid"?
Over time, there may be projects under their own organization that become OpenSSF members. We will also need a process for them to come under hybrid management if we do this.
After reading https://www.csoonline.com/article/1290656/researchers-demo-new-ci-cd-attack-techniques-in-pytorch-supply-chain-attack.html, I believe it makes sense to change the setting. Can someone who manages an enterprise Github account speak to the additional effort that might be involved with this change? I would be curious to hear from SigStore on this, including the creation from approval permissions RSTUF noticed?
The threat in that case was around the use of self-hosted runners - which Sigstore doesn't use (and I would be surprised if any project in the OpenSSF used).
2.) Shared Responsibility Model Review the table on ~page 9 of the gdoc - do you have any feedback on the TODOs and/or next steps listed there?
I like the proposed shared responsibility model. I think we will need to do roadmapped change management to get to this point. Being part of a foundation with an enterprise policy creates brand consistency, operational consistency, and should be a value for projects being a part of foundation support in that some of the responsibilities are shared. It's a shift, so we'll have to have some grace as we mature
3.) “ossf” GitHub Tasks and Permissions Review the table on ~page11 of the gdoc - do you have any feedback on the tasks/permissions assignments?
Resolve https://github.com/ossf/tac/issues/235 and https://github.com/ossf/tac/issues/237 and update this table as needed for the "Review contributions to ensure TAC/SCIR electorate"
4.) Access Management Review the table on ~page 12 in the godc - do you have any feedback on the two privileged roles detailed in the table?
No feedback.
5.) Namespace Review the paragraph in ~page 12 in the godc - do you have any feedback on a mandate for all TIs to move, or making it optional?
My recommendation would be to use https://best.openssf.org/SCM-BestPractices/#recommendations in 4.2, and to use change management to slowly align the org with top level namespace. Go in small increments, and prior to the change document where URLs might need updated. Keep the WG and stakeholders closely involved in the migration.
We should be sure that these changes only impact things currently in ossf namespace.
6). Audit events Review the three audit events on ~page 17 in the godc - should these three events be monitored? --Protected branch destroy: what is the impact of this happening and the likelihood of happening? For the Sigstore example, I think this could be a high enough concern we would want to implement it. Can this be scoped to graduated TIs? --Repo Access: See above. --org.update_member_respoitory_creation_permission. What is the liklihood and impact of this happening? What does it take to be an organization member? It may be that once this role is reached, they can create repos in their role.
Please express your vote and comments on the following: 1.) GitHub Enterprise Account Structure Review the table on ~page 7 of the gdoc - do you prefer the Hybrid or Federated model? In the option to For pull request workflows from outside collaborators, the option is currently set to "Require approval for first time contributors", but should it be changed to "require approval for all outside collaborators"?
I believe all projects and SIGs should report to a WG, and use the Hybrid model. I would support legacy Sigstore still report to the TAC (vs a WG), but recommend Sigstore to roadmap using change management to the OpenSSF hybrid model.I don't know what this actually means in practice. The Sigstore GitHub organization is already part of the OpenSSF enterprise and thus is already "hybrid"?
Over time, there may be projects under their own organization that become OpenSSF members. We will also need a process for them to come under hybrid management if we do this.
After reading https://www.csoonline.com/article/1290656/researchers-demo-new-ci-cd-attack-techniques-in-pytorch-supply-chain-attack.html, I believe it makes sense to change the setting. Can someone who manages an enterprise Github account speak to the additional effort that might be involved with this change? I would be curious to hear from SigStore on this, including the creation from approval permissions RSTUF noticed?The threat in that case was around the use of self-hosted runners - which Sigstore doesn't use (and I would be surprised if any project in the OpenSSF used).
2.) Shared Responsibility Model Review the table on ~page 9 of the gdoc - do you have any feedback on the TODOs and/or next steps listed there?
I like the proposed shared responsibility model. I think we will need to do roadmapped change management to get to this point. Being part of a foundation with an enterprise policy creates brand consistency, operational consistency, and should be a value for projects being a part of foundation support in that some of the responsibilities are shared. It's a shift, so we'll have to have some grace as we mature
3.) “ossf” GitHub Tasks and Permissions Review the table on ~page11 of the gdoc - do you have any feedback on the tasks/permissions assignments?
Resolve https://github.com/ossf/tac/issues/235 and https://github.com/ossf/tac/issues/237 and update this table as needed for the "Review contributions to ensure TAC/SCIR electorate"
4.) Access Management Review the table on ~page 12 in the godc - do you have any feedback on the two privileged roles detailed in the table?
No feedback.
5.) Namespace Review the paragraph in ~page 12 in the godc - do you have any feedback on a mandate for all TIs to move, or making it optional?
My recommendation would be to use https://best.openssf.org/SCM-BestPractices/#recommendations in 4.2, and to use change management to slowly align the org with top level namespace. Go in small increments, and prior to the change document where URLs might need updated. Keep the WG and stakeholders closely involved in the migration.We should be sure that these changes only impact things currently in
ossfnamespace.6). Audit events Review the three audit events on ~page 17 in the godc - should these three events be monitored? --Protected branch destroy: what is the impact of this happening and the likelihood of happening? For the Sigstore example, I think this could be a high enough concern we would want to implement it. Can this be scoped to graduated TIs? --Repo Access: See above. --org.update_member_respoitory_creation_permission. What is the liklihood and impact of this happening? What does it take to be an organization member? It may be that once this role is reached, they can create repos in their role.
Thanks a lot for taking the time @bobcallaway ..... Agree with all the points you made.
@Danajoyluck did you get everythuing you needed here? If not, what else do you need? I know you are working hard to close out #322. Does this support that or is it separate? ( I thought they were connected).
@SecurityCRob , @bobcallaway @torgo , @marcelamelara , @lehors , @camaleon2016 @mlieberman85 , @omkhar
@sevansdell I got everything from @bobcallaway and @SecurityCRob
@SecurityCRob , @bobcallaway @torgo , @marcelamelara , @lehors , @camaleon2016 @mlieberman85 ,
@torgo , @marcelamelara , @lehors , @camaleon2016, @mlieberman85 , sounds like @Danajoyluck still needs your input on this issue for her work product discussed on TAC call today. Thanks!
This was a "feedback-only" issue on https://docs.google.com/document/d/1E5RAj0EvOQp-bF8B3gf09Bp0NiZEcqMtZ5Sa__QXbDQ/edit. No votes needed. All "feedback" has been documented in https://docs.google.com/document/d/1E5RAj0EvOQp-bF8B3gf09Bp0NiZEcqMtZ5Sa__QXbDQ/edit,
Closing out.