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 networking requirements 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
This course is intended for anyone looking to design and build an enterprise-class Google Cloud Platform infrastructure for their own organization.
To get the most out of this course, you should have some basic knowledge of Google Cloud Platform.
To give a user permission to access particular Google Cloud resources, you assign a role to them. Basic roles act at the project level. There are 3 basic 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.
You can assign roles at different levels of the hierarchy, that is, at the organization, folder, project, and resource levels. If you assign roles to the same user at different levels, then their effective permissions are the union of the permissions at the different levels.
For example, if you granted Marie the Viewer role at the organization level and the Editor role at the project level, then she would have Editor permissions for all of the resources in that project. The Viewer role at the organization level would not override the Editor role at the project level. Similarly, if you assigned them in the opposite way, with the Editor role at the organization level and the Viewer role at the project level, Marie would still have the Editor role for all of the resources in that project because the project-level permissions would not override the organization-level permissions.
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 a 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 to 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 a 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 SQL 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.
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).