Hi, The opendev team reached out to me about handing off administrative access of the "openstack" and related organizations on GitHub. They think it would be best if the TC took control of that, or at least took control of delegating that access. In general, the goal here is to support OpenStack's presence and visibility on GitHub. Per Jim Blair:
In the long run, this shouldn't entail a lot of work, generally creating new repos on GitHub to accept mirroring from opendev systems, performing renames, handling transfer requests when repos move out of the openstack namespace, setting and updating descriptions, and curating the list of pinned repositories.
In the short term, we have some archiving and moving to do.[0] Do TC members want to manage this, or should we delegate? One thing to figure out is how to grant that access. The opendev team uses a shared account with two-factor authentication provided by a shared shell account. This mitigates accidental pushes or settings changes when an admin is using their usual GitHub account. The TC (or its delegates) probably doesn't have a shared shell account to do this with. Some options: * each admin creates a second GitHub account for this purpose use a shared * account without 2FA use a shared account with 2FA, share the one time secret * with everyone to configure their own token generator use personal accounts * but be very careful Thoughts on these options? [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006829.html // jim
My personal take on this is that it would be safer to use personal account with 2FA to manage these and also to make mandatory 2FA for all org members. Use of shared accounts is more risky as they are not as traceable as personal ones. Overall I salute the idea as I think that there are few projects that would love to be able to use github issue tracker. -- sorin On 26 Jun 2019, 19:41 +0100, Jim Rollenhagen <jim@jimrollenhagen.com>, wrote:
Hi,
The opendev team reached out to me about handing off administrative access of the "openstack" and related organizations on GitHub. They think it would be best if the TC took control of that, or at least took control of delegating that access. In general, the goal here is to support OpenStack's presence and visibility on GitHub.
Per Jim Blair:
In the long run, this shouldn't entail a lot of work, generally creating new repos on GitHub to accept mirroring from opendev systems, performing renames, handling transfer requests when repos move out of the openstack namespace, setting and updating descriptions, and curating the list of pinned repositories.
In the short term, we have some archiving and moving to do.[0]
Do TC members want to manage this, or should we delegate?
One thing to figure out is how to grant that access. The opendev team uses a shared account with two-factor authentication provided by a shared shell account. This mitigates accidental pushes or settings changes when an admin is using their usual GitHub account. The TC (or its delegates) probably doesn't have a shared shell account to do this with. Some options:
* each admin creates a second GitHub account for this purpose use a shared * account without 2FA use a shared account with 2FA, share the one time secret * with everyone to configure their own token generator use personal accounts * but be very careful
Thoughts on these options?
[0] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006829.html
// jim
Jim Rollenhagen wrote:
The opendev team reached out to me about handing off administrative access of the "openstack" and related organizations on GitHub. They think it would be best if the TC took control of that, or at least took control of delegating that access. In general, the goal here is to support OpenStack's presence and visibility on GitHub. [...]
Do TC members want to manage this, or should we delegate?
I have been considering our GitHub presence as a downstream "code marketing" property, a sort of front-end or entry point into the OpenStack universe for outsiders. As such, I'd consider it much closer to openstack.org/software than to opendev.org/openstack. So one way to do this would be to ask Foundation staff to maintain this code marketing property, taking care of aligning message with the content at openstack.org/software (which is driven from the osf/openstack-map repository). If we handle it at TC-level my fear is that we would duplicate work around things like project descriptions and what is pinned, and end up with slightly different messages.
One thing to figure out is how to grant that access. The opendev team uses a shared account with two-factor authentication provided by a shared shell account. This mitigates accidental pushes or settings changes when an admin is using their usual GitHub account. The TC (or its delegates) probably doesn't have a shared shell account to do this with. Some options:
* each admin creates a second GitHub account for this purpose use a shared * account without 2FA use a shared account with 2FA, share the one time secret * with everyone to configure their own token generator use personal accounts * but be very careful
Thoughts on these options?
I'd do a limited number of personal accounts, all with 2FA. -- Thierry Carrez (ttx)
On 27/06/2019 09:55, Thierry Carrez wrote:
Jim Rollenhagen wrote:
The opendev team reached out to me about handing off administrative access of the "openstack" and related organizations on GitHub. They think it would be best if the TC took control of that, or at least took control of delegating that access. In general, the goal here is to support OpenStack's presence and visibility on GitHub. [...]
Do TC members want to manage this, or should we delegate?
I think we should manage it, but possibly allow the foundation to manage parts of it (pinning, descriptions, etc). For setting up syncing / creation of projects we should look at keeping that under the TC (that could be the TC or other group of people that step up)
I have been considering our GitHub presence as a downstream "code marketing" property, a sort of front-end or entry point into the OpenStack universe for outsiders. As such, I'd consider it much closer to openstack.org/software than to opendev.org/openstack.
So one way to do this would be to ask Foundation staff to maintain this code marketing property, taking care of aligning message with the content at openstack.org/software (which is driven from the osf/openstack-map repository).
If we handle it at TC-level my fear is that we would duplicate work around things like project descriptions and what is pinned, and end up with slightly different messages.
I am not as concerned about this, the TC should be setting out our viewpoint for the project, and if this is in conflict with the message from the foundation, we have plenty of avenues to raise it.
One thing to figure out is how to grant that access. The opendev team uses a shared account with two-factor authentication provided by a shared shell account. This mitigates accidental pushes or settings changes when an admin is using their usual GitHub account. The TC (or its delegates) probably doesn't have a shared shell account to do this with. Some options:
* each admin creates a second GitHub account for this purpose use a shared * account without 2FA use a shared account with 2FA, share the one time secret * with everyone to configure their own token generator use personal accounts * but be very careful
Thoughts on these options?
I'd do a limited number of personal accounts, all with 2FA.
I would do it with personal accounts, but require 2FA, and explicit opt-in from TC / SIG / $group managing it. We should look at automating as much as possible of course, and have it ran by shared account that can be held in trust* as a break glass account if the needs arise in the future, but that is a longer term project. * trustee tbc
Graham Hayes wrote:
On 27/06/2019 09:55, Thierry Carrez wrote:
Jim Rollenhagen wrote:
The opendev team reached out to me about handing off administrative access of the "openstack" and related organizations on GitHub. They think it would be best if the TC took control of that, or at least took control of delegating that access. In general, the goal here is to support OpenStack's presence and visibility on GitHub. [...]
Do TC members want to manage this, or should we delegate?
I think we should manage it, but possibly allow the foundation to manage parts of it (pinning, descriptions, etc).
For setting up syncing / creation of projects we should look at keeping that under the TC (that could be the TC or other group of people that step up)
I would be fine with that -- import descriptions from openstack-map to avoid having to keep two separate sets up to date. In all cases the TC should set the rules defining how "OpenStack" should look like there. I offered Foundation resources because we may have trouble finding volunteers to follow those rules and keep that publication clean over time. That involves, for each new repo created in OpenStack, deciding if it's one we would replicate or pin, and create a GitHub-side repo. For each rename or deprecation, push the corresponding change. Not sure how much of that boring job can be automated ? -- Thierry Carrez (ttx)
Graham Hayes wrote:
On 27/06/2019 09:55, Thierry Carrez wrote:
I have been considering our GitHub presence as a downstream "code marketing" property, a sort of front-end or entry point into the OpenStack universe for outsiders. As such, I'd consider it much closer to openstack.org/software than to opendev.org/openstack.
So one way to do this would be to ask Foundation staff to maintain this code marketing property, taking care of aligning message with the content at openstack.org/software (which is driven from the osf/openstack-map repository).
If we handle it at TC-level my fear is that we would duplicate work around things like project descriptions and what is pinned, and end up with slightly different messages.
I am not as concerned about this, the TC should be setting out our viewpoint for the project, and if this is in conflict with the message from the foundation, we have plenty of avenues to raise it.
How about the TC controls which repo is replicated where (and which ones are pinned etc), but we import the descriptions from the openstack-map repo? That would keep control on the TC side but avoid duplication of effort. In my experience it's already difficult to get projects to update descriptions in one place, so two... Also, who is volunteering for setting up the replication, and then keeping track of things as they evolve ? -- Thierry Carrez (ttx)
Thierry Carrez wrote:
Graham Hayes wrote:
On 27/06/2019 09:55, Thierry Carrez wrote:
I have been considering our GitHub presence as a downstream "code marketing" property, a sort of front-end or entry point into the OpenStack universe for outsiders. As such, I'd consider it much closer to openstack.org/software than to opendev.org/openstack.
So one way to do this would be to ask Foundation staff to maintain this code marketing property, taking care of aligning message with the content at openstack.org/software (which is driven from the osf/openstack-map repository).
If we handle it at TC-level my fear is that we would duplicate work around things like project descriptions and what is pinned, and end up with slightly different messages.
I am not as concerned about this, the TC should be setting out our viewpoint for the project, and if this is in conflict with the message from the foundation, we have plenty of avenues to raise it.
How about the TC controls which repo is replicated where (and which ones are pinned etc), but we import the descriptions from the openstack-map repo?
That would keep control on the TC side but avoid duplication of effort. In my experience it's already difficult to get projects to update descriptions in one place, so two...
Also, who is volunteering for setting up the replication, and then keeping track of things as they evolve ?
Oops, duplicate send. Ignore me. -- Thierry Carrez (ttx)
On Thu, Jun 27, 2019 at 8:55 AM Thierry Carrez <thierry@openstack.org> wrote:
Graham Hayes wrote:
On 27/06/2019 09:55, Thierry Carrez wrote:
I have been considering our GitHub presence as a downstream "code marketing" property, a sort of front-end or entry point into the OpenStack universe for outsiders. As such, I'd consider it much closer to openstack.org/software than to opendev.org/openstack.
So one way to do this would be to ask Foundation staff to maintain this code marketing property, taking care of aligning message with the content at openstack.org/software (which is driven from the osf/openstack-map repository).
If we handle it at TC-level my fear is that we would duplicate work around things like project descriptions and what is pinned, and end up with slightly different messages.
I am not as concerned about this, the TC should be setting out our viewpoint for the project, and if this is in conflict with the message from the foundation, we have plenty of avenues to raise it.
How about the TC controls which repo is replicated where (and which ones are pinned etc), but we import the descriptions from the openstack-map repo?
That would keep control on the TC side but avoid duplication of effort. In my experience it's already difficult to get projects to update descriptions in one place, so two...
This seems reasonable to me.
Also, who is volunteering for setting up the replication, and then keeping track of things as they evolve ?
I'm up for it, can we get a couple more? I'd like to get this going soon. // jim
-- Thierry Carrez (ttx)
Jim Rollenhagen wrote:
On Thu, Jun 27, 2019 at 8:55 AM Thierry Carrez <thierry@openstack.org <mailto:thierry@openstack.org>> wrote:
How about the TC controls which repo is replicated where (and which ones are pinned etc), but we import the descriptions from the openstack-map repo?
That would keep control on the TC side but avoid duplication of effort. In my experience it's already difficult to get projects to update descriptions in one place, so two...
This seems reasonable to me.
Also, who is volunteering for setting up the replication, and then keeping track of things as they evolve ?
I'm up for it, can we get a couple more? I'd like to get this going soon.
Count me in. -- Thierry Carrez (ttx)
Thierry Carrez <thierry@openstack.org> writes:
I'd do a limited number of personal accounts, all with 2FA.
One thing I would encourage folks to consider is that GitHub makes it remarkably easy to do something "administrative" accidentally. Any of these accounts can easily accidentally push a commit, tag, etc., to the mirrored repos. It's not going to be destructive to the project in the long term, since it's merely a mirror of the authoritative code in Gerrit, but if we think it's important to protect the accounts with 2FA to reduce the chance of a malicious actor pushing a commit to a widely-used mirror, then we should similarly consider preventing an accidental push from a good actor. This is the principal reason that the Infra team developed its secondary-or-shared account policy. Especially if the folks who manage this are also folks who work on these repos, we're one "git push" away from having egg on our collective face. If the folks managing the GitHub presence are also developers, I would encourage the use of a shared or secondary account. -Jim
James E. Blair wrote:
Thierry Carrez <thierry@openstack.org> writes:
I'd do a limited number of personal accounts, all with 2FA.
One thing I would encourage folks to consider is that GitHub makes it remarkably easy to do something "administrative" accidentally. Any of these accounts can easily accidentally push a commit, tag, etc., to the mirrored repos. It's not going to be destructive to the project in the long term, since it's merely a mirror of the authoritative code in Gerrit, but if we think it's important to protect the accounts with 2FA to reduce the chance of a malicious actor pushing a commit to a widely-used mirror, then we should similarly consider preventing an accidental push from a good actor. This is the principal reason that the Infra team developed its secondary-or-shared account policy.
Especially if the folks who manage this are also folks who work on these repos, we're one "git push" away from having egg on our collective face.
If the folks managing the GitHub presence are also developers, I would encourage the use of a shared or secondary account.
That is a fair point that I had not considered. That said, wouldn't the risk be relatively limited if the "admins" never checkout or clone from GitHub itself ? -- Thierry Carrez (ttx)
I think I could write a script that loops over all repos and activates branch restrictions to allow only our sync-bot to push. Running this daily should avoid the case where a new repo is added and someone forgets to add the restriction. In the future we can use the same bot for other maintenance tasks. * in python, obviously.
On 28 Jun 2019, at 09:43, Thierry Carrez <thierry@openstack.org> wrote:
James E. Blair wrote:
I'd do a limited number of personal accounts, all with 2FA. One thing I would encourage folks to consider is that GitHub makes it remarkably easy to do something "administrative" accidentally. Any of
Thierry Carrez <thierry@openstack.org> writes: these accounts can easily accidentally push a commit, tag, etc., to the mirrored repos. It's not going to be destructive to the project in the long term, since it's merely a mirror of the authoritative code in Gerrit, but if we think it's important to protect the accounts with 2FA to reduce the chance of a malicious actor pushing a commit to a widely-used mirror, then we should similarly consider preventing an accidental push from a good actor. This is the principal reason that the Infra team developed its secondary-or-shared account policy. Especially if the folks who manage this are also folks who work on these repos, we're one "git push" away from having egg on our collective face. If the folks managing the GitHub presence are also developers, I would encourage the use of a shared or secondary account.
That is a fair point that I had not considered.
That said, wouldn't the risk be relatively limited if the "admins" never checkout or clone from GitHub itself ?
-- Thierry Carrez (ttx)
Thierry Carrez <thierry@openstack.org> writes:
James E. Blair wrote:
Especially if the folks who manage this are also folks who work on these repos, we're one "git push" away from having egg on our collective face.
If the folks managing the GitHub presence are also developers, I would encourage the use of a shared or secondary account.
That is a fair point that I had not considered.
That said, wouldn't the risk be relatively limited if the "admins" never checkout or clone from GitHub itself ?
Yes, the biggest risk is if one of the admins is a regular user of GitHub. If they don't have their own GitHub-forks of the OpenStack repos, and they only ever clone their local copies from OpenDev (or, they are not developers at all), then I think the risk of accidents on a personal account is fairly low. -Jim
On Fri, Jun 28, 2019 at 07:49:10AM -0700, James E. Blair wrote:
Thierry Carrez <thierry@openstack.org> writes:
James E. Blair wrote:
Especially if the folks who manage this are also folks who work on these repos, we're one "git push" away from having egg on our collective face.
If the folks managing the GitHub presence are also developers, I would encourage the use of a shared or secondary account.
That is a fair point that I had not considered.
That said, wouldn't the risk be relatively limited if the "admins" never checkout or clone from GitHub itself ?
Yes, the biggest risk is if one of the admins is a regular user of GitHub. If they don't have their own GitHub-forks of the OpenStack repos, and they only ever clone their local copies from OpenDev (or, they are not developers at all), then I think the risk of accidents on a personal account is fairly low.
-Jim
There are some tools out there that have been created to help mitigate these kinds of things. One I recently came across is described here: https://www.jeff.wilcox.name/2015/11/azure-on-github/ I'm not advocating for trying to adapt that tool, but I think it shows that something can be stood up relatively easily that would provide a separation of control to prevent accidental admin access modifications while still making it easy to see and manage a large number of repos. Seems fairly easy enough to even just create a githubadmin@openstack.org account and control access via that. Sean
On 2019-06-29 07:04:00 -0500 (-0500), Sean McGinnis wrote: [...]
Seems fairly easy enough to even just create a githubadmin@openstack.org account and control access via that.
Which brings us all the way back around to what the Infra team ended up doing... create a shared account backed by a second auth factor of an OTP generator on its own access-controlled system with audit logging. You could leverage it the same way to authorize and deauthorize other accounts for short-term administrative access. But at the end of the day, solutions like that are probably more of a pain than if the handful of admins who want to have GH accounts and also use GH for other reasons could just have two separate accounts. (Not that I particularly have a horse in this race either way, I'm just happy I can stop touching GH nearly so often.) -- Jeremy Stanley
participants (8)
-
corvus＠inaugust.com
-
Graham Hayes
-
Jean-Philippe Evrard
-
Jeremy Stanley
-
Jim Rollenhagen
-
Sean McGinnis
-
Sorin Sbarnea
-
Thierry Carrez