2 Answers
Hey there. Glad you’re enjoying, so far!
This is a good question, and I’m glad you’re thinking about these real-world aspects to using GCP effectively. Google answers your question in their super-valuable "Best practices for enterprise organizations" page. In particular, in the "Project Structure" section, they write:
A general recommendation is to have one project per application per environment. For example, if you have two applications, "app1" and "app2", each with a development and production environment, you would have four projects: app1-dev, app1-prod, app2-dev, app2-prod. This isolates the environments from each other, so changes to the development project do not accidentally impact production, and gives you better access control, since you can (for example) grant all developers access to development projects but restrict production access to your CI/CD pipeline.
The ideal project structure depends on your individual requirements, and might evolve over time. When designing project structure, determine whether resources need to be billed separately, what degree of isolation is required, and how the teams that manage the resources and apps are organized. An example structure can be found at Policy design for enterprise customers.
I hope this helps!
Mattias
(Follow-up from comments, above.)
Ah, yes… ok. In general, every human being should have one single organization-controlled Google account to identify them: somename@theorganization.com . And then that single account is granted access to all the different resources, as appropriate–and grouping resources into projects helps with that. (So one human account may have access to resources in multiple projects.) But then also, each project will have its own Service Accounts for the applications that are running within it–and then each of those service accounts is also given access to various resources, as appropriate (sometimes cross-project or to external services, but often also within the project). You don’t need to make your own email-address-based accounts for service accounts; Google manages the corresponding email addresses for those, on your behalf.
One last thing to clarify: There should NEVER be any shared accounts. Resources can be shared by authorizing multiple accounts to use them, but the accounts themselves are for identifying individuals, not ever for sharing access.
I hope this helps.
Mattias
That makes sense Mattias, I will have a go and set this up. Thanks for your your support 🙂
Glad to help. 🙂
I believe the answer is about projects, but the question is about users. So maybe it should be said that the ideal project structure is what Mattias is saying, but each user would just have their own account and either directly or through groups she would be granted roles in each of the different projects
Thanks Mattias, that was useful information to read about project best practice. Rogelio is correct, I’m still unsure around user setup best practice. In your course, you setup an admin Google account and non admin account. I have setup a master Google account gcp@company.com. This is not a gmail account (company email) and is linked to billing (and has some startup credits). Now I have created another Google account (non admin) called app1@company.com (in the future we may have app2@company.com etc.). These accounts will be linked to the master account for billing. This account would have the projects for the app (dev, test and prod). In my mind, this account would not be a personal users email account where they could create their own projects, it would be a pseudo account that we can control for security. We should then share access to projects in this account to individual users. I’m not sure is this the right way of doing it. After further reading I see that we can use Google Identity to setup an organisation to manage users but when I tried to setup Google Identity with the user gcp@company.com, it said the username is already taken. Just finding it a little confusing of what I should be doing.
Ah, yes… ok. I’ll continue my response in another "answer" so you get a notification.