Resource management
1. Resource management
Every Google Cloud resource you use must belong to a project. But what is a project? A project is a container for all your Google Cloud resources. It provides a way to organize resources, manage billing, and control access. Each project even has a unique identifier. Google Cloud's resource hierarchy contains four levels, and starting from the bottom up they are: resources, projects, folders, and an organization node. Resources are at the first level. These represent containers, virtual machines, tables in BigQuery, or anything else in Google Cloud. Resources are organized into projects, which sit on the second level. Projects can be organized into folders, or even subfolders. These sit at the third level. And then at the top level is an organization node, which encompasses all the projects, folders, and resources in your organization. It's important to understand this resource hierarchy because it directly relates to how policies are managed and applied when you use Google Cloud. Policies can be defined at the project, folder, and organization node levels. Some Google Cloud services allow policies to be applied to individual resources, too. Policies are inherited downward. This means that if you apply a policy to a folder, it will also apply to all of the projects within that folder. Let's look at the second level of the resource hierarchy, projects, in a little more detail. Projects are the basis for enabling and using Google Cloud services, like managing APIs, enabling billing, adding and removing collaborators, and enabling other Google services. Each project is a separate entity under the organization node, and each resource belongs to exactly one project. Projects can have different owners and users because they're billed and managed separately. Each Google Cloud project has three identifying attributes: a project ID, a project name, and a project number. The project ID is a globally unique identifier assigned by Google that can't be changed after creation. They're what we refer to as being immutable. Project IDs are used in different contexts to inform Google Cloud of the exact project to work with. Project names, however, are user-created. They don't have to be unique and they can be changed at any time, so they are not immutable. Google Cloud also assigns each project a unique project number. It's helpful to know that these Google-generated numbers exist, but we won't explore them much in this course. They're mainly used internally by Google Cloud to keep track of resources. You can use folders to group projects under an organization in a hierarchy. For example, your organization might contain multiple departments, each with its own set Google Cloud resources. Folders allow you to group these resources on a per-department basis. Folders also give teams the ability to delegate administrative rights so that they can work independently. And when an organization node contains lots of folders, projects, and resources, a workforce might need to restrict who has access to what. To help with this task, administrators can use Identity and Access Management, or IAM. With IAM, administrators can apply policies that define who can do what and on which resources. The "who" part of an IAM policy can be a Google account, a Google group, a service account, or a Cloud Identity domain. A "who" is also called a "principal." Each principal has its own identifier, usually an email address. The "can do what" part of an IAM policy is defined by a role. An IAM role is a collection of permissions. When you grant a role to a principal, you grant all the permissions that the role contains. For example, to manage virtual machine instances in a project, you must be able to create, delete, start, stop and change virtual machines. So these permissions are grouped into a role to make them easier to understand and easier to manage. So, who is responsible for security in the cloud? It's a shared responsibility between you and Google Cloud. A general guideline for shared responsibility is that "if you configure or store it, you're responsible for securing it." This means that a cloud provider is responsible for securing the parts of the cloud that it directly controls, such as hardware, networks, and physical security. At the same time, the customer is responsible for securing anything that they create within the cloud, such as the configurations, access policies, and user data. No matter which cloud provider you use, there is shared responsibility.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.