Re: debian.org organisation on GCP [was: Re: Vagrant box CI/CD]
On Fri, Jun 29, 2018 at 12:47:12PM +0200, Bastian Blank wrote:
> On Fri, Jun 29, 2018 at 01:26:39AM -0400, Jimmy Kaplowitz wrote:
> > There are other constraints: You can't create your own organization
> > without a G Suite account, which can't be free without SPI's 501(c)(3)
> > nonprofit status or some foreign equivalent.
>
> There is the Cloud Identity product, which creates an organization as
> well. And the last time I looked at it, this worked pretty well.
I'm glad they seeem to have added this option - DSA and I were already
planning to use Cloud Identity, but last time I checked, standalone
Cloud Identity without G Suite couldn't create a GCP organization. This
is now possible.
Anyway, Debian doesn't neeed or want most of the proprietary G Suite
services, so starting debian.org with Cloud Identity (through SPI's G
Suite or otherwise) makes sense.
> > Shall I take your reply as a request to follow up with DSA on getting
> > the debian.org domain registered with SPI's G Suite and a GCP
> > organization created? I've been waiting on such a reply for the last two
> > weeks after you said you dropped the project that motivated the work,
> > but it's still easy to do if desired.
>
> This are two different projects. I have more or less dropped the mirror
> project. This would be a new one directly for Salsa. And this time we
> may want to do it right and not opt-in for the easy solution of a GCP
> project within google.com.
Interesting. Can you say more about why the mirror project got dropped
and how Google is now planning to handle Debian mirror access for GCP?
As for Salsa: having an official Debian/SPI arrangement gives Google
some additional ways to do this sponsorship. They could give a coupon
which we could apply to a billing account that is used by the Salsa
project, or they could directly cover the costs of such a billing
account through making it directly paid by the appropriate internal
Google cost center. Note that a single billing account can be used by
multiple GCP projects, so you can still separate on useful boundaries
like development vs production instances of Salsa.
Since SPI is a 501(c)(3) public charity, they might be able to treat
this coupon or the Google-paid billing account as a charitable donation,
which in turn might make them more willing to say yes or to offer a
larger sponsorship.
Whatever GCP projects get used for Salsa, they can be put inside
Debian's GCP organization, which would give DSA visibility but wouldn't
have to block direct access for the people doing the work.
> However I don't even know if using anything of that would work. DSA has
> choosen to ignore me. Either they have no time, which means they need
> to shed responsibilities and should not be tasked with more stuff. Or
> they explicitely ignore me, which means that I'am reluctant to use it,
> if it means everything takes ages to accomplish.
When Chris Lamb forwarded your email to me mid-February, I emailed DSA
very soon after that (maybe the next day?) proposing options. The time
between then and early May was DSA deciding how they wanted to react. It
was a novel request with an organization considered controversial within
Debian and where most of DSA had been unfamiliar with the context. By
Debian standards, taking under 3 months to decide to proceed is fast! :-)
Their email to me in early May was at a time when I was juggling lots of
housing and career things as a new immigrant, hence the ~1 month of
delay I did add. But I signed a lease last week and now mostly know how
I plan to proceed with my career! I will get things unblocked quite
quickly, with only a little bit of DSA involvement needed.
> So yes, please follow up to get the domain registered. But please make
> sure the responsibility does not solely lie with DSA.
SPI currently has 3-4 G Suite administrators, of whom I'm only one and
of whom only one overlaps with DSA. Involving SPI actually reduces the
technical bottleneck here, surprisingly. :)
That said, there's still the question of what role different Debian
teams, including DSA, ought to have. I view this differently for policy
and implementation.
Policy: As Debian's systems administrators, DSA needs to have visibility
into and oversight of Debian's GCP activities. Debian's policies like
DMUP still need to apply, and any decision by DAM to admit or expel
someone should be able to affect their access to Debian's GCP resources.
Guest access should be treated similarly to how it is on other Debian
resources.
Implementation: There's no need for DSA or DAM to be the only ones who
can twiddle the GCP bits in Google's systems, unless they want that.
They didn't insist on that for Alioth, and DebConf had separate systems
for a long time. Right now I think we can probably work out some agreed
parameters within which cloud team members manually grant access, until
it subsequently gets automated via something like SAML SSO to Debian
LDAP. Merely having it in the Debian GCP organization will allow them
the visibility and oversight when they're ready to do that.
On Fri, Jun 29, 2018 at 07:04:35PM +0100, Marcin Kulisz wrote:
> On 2018-06-29 12:47:12, Bastian Blank wrote:
> > On Fri, Jun 29, 2018 at 01:26:39AM -0400, Jimmy Kaplowitz wrote:
> > > There are other constraints: You can't create your own organization
> > > without a G Suite account, which can't be free without SPI's 501(c)(3)
> > > nonprofit status or some foreign equivalent.
> >
> > There is the Cloud Identity product, which creates an organization as
> > well. And the last time I looked at it, this worked pretty well.
>
> As far as I know CloudID is a commercial product and is billed 4pcm per user[1]
> in which case sponsoring and SP involvement will be required. But pricing
> information in this regards is a bit mixed as I think that I also saw somewhere
> info that it's free.
That seems to be a separate premium edition which we have no need for.
Cloud Identity has a free edition, which can be used together with G
Suite or separately from it.
> Anyway having CloudId for debian.org and linking it over SAML to our LDAP would
> make sense IMO.
Yes, that's roughly what we're planning to do, except defer the
SAML/LDAP part until a later stage in the iteration, so that it doesn't
block anyone from getting going. Manual first, then automate.
- Jimmy Kaplowitz
jimmy@debian.org
Reply to: