[benatkin]

What's this like on Google Cloud? Would you create a project to get into other projects and would that achieve most of what this achieves? And would you use a GSuite address so you don't log into the console just by logging into the email?

[reilly3000]

Everything in GCP is built atop the Google Auth system and tied to a GSuite domain. It’s Org->Folder->Project hierarchy is very similar to AWS Orgs. However, it’s far easier from there. IAM is tied to your gsuite email, and service accounts are also email addresses. One never needs to login with different creds to access another project. You just use your Google login or activate a service account. Projects are a really flexible abstraction. My company has one for every stage for every team plus specialized projects for net/VPC, GCR, logs, etc, hundreds in total. We’re about halfway through the F500 list. Projects are a nice abstraction and getting the setup OP described is a lot more idiomatic to GCP.

[throwawaaarrgh]

There is a lot you cannot do, or are forced to do in specific ways. A shit-ton of GCP features require project-level access, and often it's impossible to make permissions more fine-grained. For other things, you have to modify or apply a policy at the Org level. It's really broken. You basically have to abandon GCP features if you want strong isolation guarantees for most of their features. AWS is not even close to as braindead with their design.

[movedx]

> One never needs to login with different creds to access another project. You just use your Google login or activate a service account.

It's the same in AWS with AWS SSO/IAM Center. You only login once, and you can access every other account (project) you're allowed to access.

[kevincox]

But you need to keep going back to the SSO console to switch accounts because only one can be active at once. With GCP you can have multiple tabs open with different accounts.

The best part is that the account is in the URL so you can just link to specific resources in different accounts. So many of our runbooks for GCP are like "click this link" whereas for AWS it is "make sure you are looked into {specific-account} then click this link". The latter is much more error prone and can break your workflow if you were doing something in a different account previously.

[benatkin]

This* is a feature, not a bug for me – I use separate profiles in Chrome or Container Tabs in Firefox!

Edit: I realized you are talking about switching accounts twitter style. I don't mess with that - I use a separate Chrome profile. Also you are arguing for GCP, I thought you were arguing against it.

* Having separate accounts, not being able to have separate accounts - I know it's possible with AWS as AWS doesn't force you to use a single account.

[rcrowley]

All rings true, to me.

[diceduckmonk]

You can’t have nested projects, but for the purposes of organizations there is folders and orgs, which are container of containers.

GCP’s IAM somewhat addresses the isolation and scope problem mentioned in the article. Not all GCP apis, atleast with respect to OAuth2, properly utilize IAM, insofar that they require overly power OAuth2 scopes. For example, to list cloud functions you need permissions to create and edit, too. That’s broken.

In GCP, many orgs find themselves proliferating in projects because GCP’s billing is abstruse. People isolate resources to projects so they know how much specific services actually cost. This in turn presents another problem. GCP Web Console’s search doesn’t index well. For example, substring search doesn’t work on far too many resources. VMs are the exception, but we think this is inverted. Substring search should work on every resource, not be exceptional. Historically it didn’t even do cross project search. This is frankly not acceptable for a search company.

[mdaniel]

> For example, to list cloud functions you need permissions to create and edit, too. That’s broken.

Do you have a concrete example of that? Or, maybe you mean the console needs those perms to work?

[rcrowley]

We created a second GSuite for GCP at Slack because we didn’t want email and other corp IT assets to be mixed into what could’ve (but didn’t) become production infrastructure.

[benatkin]

Ah, great idea. That is my main concern.

[judge2020]

For enterprises it seems this is already baked-in, ie. when you're a Google Workspace (previously GSuite) user, your project selector has an inherent hierarchy stemming from the domain, ie. example.com -> project1, project2, etc. and, in my limited experience, switching between accounts on the command line is pretty good. But this article still makes a good point about keeping different environments in different siloed projects.

[benatkin]

It seems that with isolation between projects on gcloud the number of separate accounts needed is less, which is good because it's also harder and more expensive to create multiple accounts. If gsuite is used very carefully, 1 is enough, but I think 2 would be better for most.

[judge2020]

I think you're misunderstanding AWS accounts; they're not talking about AWS "logins", they're talking about actual "accounts" which are the entities that house resources like GCP projects. You can have an "organization" that has many accounts under it with sensible IAM, although it's less clean than GCP.

[cjcampbell]

I'm assuming you're saying a dedicated account for Google Workspace (GSuite) and a separate account for anything GCP?

[benatkin]

Yeah, that's what I'm saying. There's a lot of overlap with people who are using GSuite for things like email and people who are using GCP for production systems. It isn't great that the login/2FA for email automatically give access to GCP. Email is used so often, it's hard to be as cautious with it all the time as one can be with a something used less often.

[cjcampbell]

Thanks for confirming. Great advice, and I agree 100%.