How to build a resource hierarchy - Google Cloud Tutorial

- [Instructor] As an administrator in Google Cloud, you will find yourself creating and managing different types of roles within your environment. You'll also control the circumstances in which users are granted or denied access to your cloud resources. To do so within the Google Cloud platform, that's where identity and access management comes in. Identity and access management also known as IAM is a collective term that covers technologies, processes, and policies used to manage user identities. It also reduces identity related access risks within a business. One of the first steps in managing your resources and users is to understand and set up your organizational resource hierarchy. Establishing this early will definitely save you future headaches. The resource hierarchy is a logical concept in which you set up how your Google Cloud resources are organized and how policies will be applied for access. This hierarchy is made up of four main pillars, an organizational resource, folders, projects, and the actual Google Cloud resources themselves. The goal of this hierarchal formation is to make the management of your resources easier, as well as enforce access restrictions on your resources through policies. In addition to understanding the pillars and goals of the resource hierarchy, it is important to understand the concept of transitive inheritance. Transitive inheritance is when your underlying resources inherit the permission settings of the policies applied on the resources higher up the hierarchy. Meaning your resources inherit permissions from policy set at the project level. Your projects inherit permissions set from policies at the folder level. And folders inherit permissions from the organizational level. Let's understand more of what transitive inheritance looks like. Say I have two users, Jasmine and Howard, both with different roles and different access to resources in my Google Cloud environment. If I set a policy on the folder level titled HR department, that grants the project editor role to Howard. Then he will have access to the underlying folders of team A and B, as well as editor access to any projects and resources under these folders. Conversely, if I assign Jasmine the instance admin role on the project titled Design Team, she will only be able to manage Compute Engine instances within that project. Now that we understand transitive inheritance, let's understand each one of the pillars of resource hierarchy. Starting from the top, there is an organizational node. This is your root node that literally represents your company. You're not required to have an organization node. But some services such as creating a folder will not be available if you do not have one. It is good practice to create an organization node so that any manage user, say for example your employees, who make a project will have that project associated with the organization instead of their individual account. That way you can keep track of all resources and personnel who might be using your data in some way within the Google Cloud platform. Next in a hierarchy diagram is the folder node. Folders are the children of the organizational node and allow you to logically isolate your projects. It is recommended to map and categorize your folder structure just as you would the departments in your actual organization. For example, creating an HR folder for your HR department and an IT folder for your IT department, and placing some team folders within each department folder. Additionally, folders can contain other folders allowing you to get as granular as necessary in your organizations. The next level down the hierarchy are project nodes. Project nodes are children of the organization or folders. And are what you actually put your Google Cloud resources into. In order to create a Google Cloud resource, you must create a project. Additionally, your organizational and folder nodes can contain multiple projects. For example, if your IT department is working on multiple initiatives and wanted to create five projects under the IT folder. And lastly, we have our resources section. Resources are children of projects and are the actual Google services themselves. For example, a Compute Engine virtual machine, a Cloud Storage bucket, or perhaps a BigQuery database. As mentioned before, these Google Cloud resources must be associated with a project. Additionally, resources can only be under one project at a time. Together, these four pillars make up your Google Cloud resource hierarchy and help build a solid foundation for you to architect your Google Cloud resources. Now that we've broken down each layer of your resource hierarchy, let's summarize some key points. First, set up your hierarchy structure as early as possible. That way you have an understanding of where your resources and data lie. Secondly, remember that permissions are transitive. Any policies you apply at an organizational level will take precedence over any permissions placed at the lower resources beneath. The same concept applies to any permissions applied at the folder, project, and resource level. Now that you understand the resource hierarchy, you can begin setting your own policies to your own resources and the Google Cloud platform.