Now, let's dive into the material for this module. Here the skills [inaudible] concerns essential for setting up new cloud projects and accounts. The task listed under this section involve different areas of the Google Cloud console including, the projects, user API and Stackdriver consoles. Creating projects and assigning users to the predefined roles of those projects are very basic first tasks. So we'll look at these first two items together. First, let's look at the overall structure of a simple files Google Cloud account. This is a diagram of an example of resource hierarchy within an organization. You notice that all resources are arranged under the organization node including projects. Resources can be grouped and managed together according to your organizational structure. You consume GCP resources by attaching them to or enabling them within a project. This is how they're built and tracked and given permissions to operate. Therefore, a console always have at least one project. Creating a basic project is quite an easy, but it requires some attention to labeling and naming. The two items highlighted are provided by the person setting up the project. Project ID once set cannot be changed. So think this one through carefully. The third project number is automatically generated by the GCP system and also cannot be changed. The main thing to remember, when it comes to organizing your projects, is that everything is arranged in a hierarchy. The top of this hierarchy is the organizational node. Everything else rest under this main node. Folders are used mainly for organization and after all may make a company structure. For example, you may find folders for marketing, finance, HR and IT within the organizations resource hierarchy. When you have a new organization node, by default, it lets any user and the domain create projects and billing accounts. But best practice with a new organization node is to first decide, who on your team really should be able to do those things. Then, you can assign each user to a role or roles for easier and more secure administration. Permissions in GCP are inheritable. This means that each resource that sits below another one in the hierarchy includes all of the permissions given to its parent. Parent permissions given to a child resource cannot be removed by that child or by another resource at that same level, or by anything further down in the hierarchy. For example, if the parent gives a user or role permission to edit a resource, a child of that parent cannot take that edit permission away. A child resource however, can have permissions to the ones inherited from its parent. This is how you get finer grain control over who can use or modify resources. What is a role in the context of GCP resources? A role is simply a collection of permissions. Generally, roles exist to define what tasks can be performed on certain resources and when assigned to users, who can perform them. Roles help to simplify, assigning and maintain permissions on project resources. They assist administrators in providing everyone on the project with just the right amount of access and no more to get their jobs done. Three main types of roles can be applied to GCP users and resources: Primitive, predefined and custom. We will not go into custom roles in this module. Let's look at the three primitive roles first. These primitive roles are the owner, editor and viewer. If you're a viewer on a given resource, you can examine it but not change its state. If you're an editor, you can do everything a viewer can do plus change its state and if you're an owner, you can do everything an editor can do plus manage roles and permissions on the resource. If you have several people working together on a project that contains sensitive data, primitive roles are probably not fine enough. Fortunately, GCP, AIM provides other finer grain types of roles. Permissions are set to define who can do what on which resource. This is generally a very coarse way of assigning permissions in the project because it generally means assigning view, edit or administrative levels of access. However, GCP also offers predefined roles, which help narrow the scope down to who can do what from a long lists of unique possibilities on that particular type of resource. Each service has a predefined list of possible permissions that can be granted to users working on that resource. Predefined roles bundles selected permissions up into collections that correlate with common job-related related business needs. So instead of being granted all permissions or an ad hoc list of separate permissions, there might be missing something important. A user can simply be assigned a predefined role instead. Compute engine for example, offers a set of predefined roles that can be applied to compute engine resources in a given project, a given folder or wherever an entire organization. Let's look at this in more detail. In this example, we see a partial list of the compute engine permissions to have them bundled into the predefined instance admin role. The ellipsis indicate that there are more options not shown. These permissions defined what that role is allowed to do with virtual machines. Other predefined roles in compute engine have their own customized list of permissions depending on what task that role is generally expected to perform. Having these predefined roles in place for common job functions saves time and administrated overhead. Google keeps these up-to-date with any new permissions that are deemed required for that role. Would it just giving everyone every permission on a servers be much simpler to maintain? Simpler, maybe but a much more risky because this violates the security principle of least privilege and it increases the chance of accidental or deliberate damage to a company's vital services or data. For example, an accountant might need access to reporting data generated on a compute engine instance but does not need to be able to delete that compute engine instance. Giving them permission to do so would not be good security practice, would increase the risk of accidental deletions and might in fact cause the company to violate certain regulations.
