The course is part of these learning paths
Mapping Needs to GCP Services
Google Cloud Platform (GCP) lets organizations take advantage of the powerful network and technologies that Google uses to deliver its own products. Global companies like Coca-Cola and cutting-edge technology stars like Spotify are already running sophisticated applications on GCP. This course will help you design an enterprise-class Google Cloud infrastructure for your own organization.
When you architect an infrastructure for mission-critical applications, not only do you need to choose the appropriate compute, storage, and networking components, but you also need to design for security, high availability, regulatory compliance, and disaster recovery. This course uses a case study to demonstrate how to apply these design principles to meet real-world requirements.
- Map compute, storage, and network needs to Google Cloud Platform services
- Create designs for high availability and disaster recovery
- Use appropriate authentication, roles, service accounts, and data protection
- Create a design to comply with regulatory requirements
We've already covered roles and permissions in the fundamentals course. So, I'll just give you a quick refresher and then go over the best practices for enterprise organizations.
To give a user permission to access particular Google Cloud resources, you assign a role to them. Primitive roles act at the project level. There are three primitive roles available: owner, editor and viewer. There are also fine grained roles for individual resources. These are called "predefined roles." They were previously known as "curated roles." For example, the Cloud SQL Viewer role, gives read only access to Cloud SQL resources.
There are a few principles you should apply when setting roles and permissions.
First, use the principle of least privilege when granting roles. That is, assign roles with the least permissions required for people to do what they need.
Second, whenever possible, assign roles to groups instead of to individuals. Then, when you need to grant a role to the user, you can just add them to the group. Not only is this easier to manage, but it also ensures consistent privileges among members of a particular group. You can also use a descriptive group name that makes it clear why group members need those permissions.
Third, keep tight control of who can add members to groups and change policies. If you don't, then people could give themselves or others, more privileges than they should have.
Fourth, to make sure that inappropriate policy changes aren't made, audit all policy changes by checking the Cloud audit logs, which record project level permission changes.
Now let's apply these principles to GreatInside. First you would grant the project Owner role to a few key system administrators. Owners are the only ones who can change policies. Unless, you grant users the organization administrator role. You should always have more than one owner, otherwise if that person is unavailable or leaves the organization, it would be difficult for someone else to take their place as owner. So avoid that situation by giving the owner role to several people, but choose wisely because owners can do just about anything.
Similarly, you would have a small number of G Suite Administrators, who could add users to groups.
Obviously, there would be large number of users who would need permissions, so I'm not going to talk about every type of user, but I'll give a couple of examples. One example would be a network administration group that you would grant the Compute Network Admin role to.
Another example would be a QA team. You could grant their group the Editor role on the test environment project. And the Viewer role on the production environment project. Alternatively, if the QA people don't need full access to the test environment, then you could grant them several predefined roles, such as compute instance admin, Cloud sequel admin, and compute storage admin.
Regarding audit logs, someone would need to take on the responsibility of checking for policy changes. The admin activity audit logs are viewable by all project members, so you wouldn't need to grant access to the person who does the checking.
And that's it for roles.
About the Author
Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).