Google Cloud resource hierarchy

Today on day five of this journey we will study about the functional structure of Google Cloud.

Levels of hierarchy

Google Cloud’s resource hierarchy contains four levels:

1. resources

2. projects

3. folders

4. organization node.

***These are organized from bottom to top.****

\>>> Resources: Present at the first level of the hierarchy and represents virtual machines, Cloud Storage buckets, tables in BigQuery, etc in Google Cloud.

\>>>Resources are organized into projects.

\>>>Projects: Present at the second level of the hierarchy.

\>>>Projects can be organized into folders or even subfolders.

\>>>Folders: Present at the third level of the hierarchy.

\>>>Organization node: Present at the top level of the hierarchy. which holds all the projects, folders, and resources in your organization.

Importance of hierarchy

\>>>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 also 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.

PROJECT: the second level of the hierarchy

\>>>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.

Identifying attributes of project

\>>>Each Google Cloud project has three identifying attributes:

1. Project ID

2. Project name

3. Project number.

\>>>Project ID: It is a globally unique set of characters and numbers assigned to each project individually and can't be changed once assigned to a project i.e, they are immutable.

\>>>They are used to inform Google Cloud of the exact project to work with.

\>>>Project names: The project name is an identifier of a project which is created by the user itself it may or may not be globally unique and can be changed at any point in time.

\>>> Project Number: This is the unique number provided by Google for each project.

These identifiers are mainly used internally by Google Cloud to keep track of resources.

Resource Manager: It is a Google Cloud tool that is designed to programmatically help you manage projects. Basically, It is an API that can gather a list of all the projects associated with an account, create new projects, update existing projects, and delete projects. It can even recover projects that were previously deleted,and can be accessed through the RPC API and the REST API.

Folders: third level of the hierarchy

\>>> Folders let you assign policies to resources at a level of granularity you choose. The resources in a folder inherit policies and permissions assigned to that folder.

\>>>A folder can contain projects, other folders, or a combination of both. They can be used to group projects under an organization in a hierarchy.

\>>>For example, Any organization might contain multiple departments, each with its own set of 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.

\>>> The resources in a folder inherit policies and permissions from that folder.For example, if you have two different projects that are administered by the same team, you can put policies into a common folder so they have the same permissions.

\>>>Using two copies of the policies each for one project makes it error-prone and tedious to maintain because if we want to change policies we have to edit them in two places.

Organization Node: top level of the hierarchy

\>>>organization node, which is the very topmost resource in the Google Cloud hierarchy. Everything else attached to that account goes under this node, which includes folders, projects, and other resources.

\>>>There are some special roles associated with this top-level organization node. For example, you can designate an organization policy administrator so that only people with privilege can change policies. You can also assign a project creator role, which is a great way to control who can create projects and, therefore, who can spend money.

\>>>How a new organization node is created depends on whether your company is also a Google Workspace customer. If you have a Workspace domain, Google Cloud projects will automatically belong to your organization node. Otherwise, you can use Cloud Identity, Google’s identity, access, application, and endpoint management platform, to generate one.

\>>>Once created, a new organization node will let anyone in the domain create projects and billing accounts, just as they could before. folders underneath it and put projects into it. Both folders and projects are considered to be “children” of the organization node.

Identity and Access Management (IAM)

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.

\>>> Using 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 principle 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.

\>>>When a principal is given a role on a specific element of the resource hierarchy, the resulting policy applies to both the chosen element and all the elements below it in the hierarchy.

\>>>You can define deny rules that prevent certain principals from using certain permissions, regardless of the roles they're granted. This is because IAM always checks relevant deny policies before checking relevant allow policies. Deny policies, like allow policies, are inherited through the resource hierarchy.

\>>>There are three kinds of roles in IAM: basic, predefined, and custom.

BASIC ROLE TYPE

\>>>The first role type is basic. Basic roles are quite broad in scope. When applied to a Google Cloud project, they affect all resources in that project. Basic roles include owner, editor, viewer, and billing administrator.

1. Project viewers can access resources but can’t make changes.

2. Project editors can access and make changes to a resource.

3. Project owners can also access and make changes to a resource. In addition, project owners can manage the associated roles and permissions and set up billing.

\>>>Often companies want someone to control the billing for a project but not be able to change the resources in the project. This is possible through a billing administrator role.

*** BASIC ROLES MUST BE AVOIDED AS MUCH AS POSSIBLE WHEN WORKING WITH SENSITIVE DATA***

PREDEFINED ROLE TYPES

\>>>IAM provides other ways to assign permissions that are more specifically tailored to meet the needs of typical job roles. This brings us to the second type of role, predefined roles. Specific Google Cloud services offer sets of predefined roles, and they even define where those roles can be applied.

\>>>Let’s look at Compute Engine, for example, a Google Cloud product that offers virtual machines as a service. With Compute Engine, you can apply specific predefined roles—such as “instanceAdmin”—to Compute Engine resources in a given project, a given folder, or an entire organization. This then allows whoever has these roles to perform a specific set of predefined actions.

CUSTOM ROLE TYPES

\>>>Custom Roles: It is used to assign a role that has even more specific permissions.

\>>>Many companies use a “least-privilege” model in which each person in your organization is given the minimal amount of privilege needed to do their job. So, for example, maybe you want to define an “instanceOperator” role to allow some users to stop and start Compute Engine virtual machines, but not reconfigure them. Custom roles will allow you to define those exact permissions.

\>>> Before you start creating custom roles, please note two important details.

\>>>First, you’ll need to manage the permissions that define the custom role you’ve created. Because of this, some organizations decide they’d rather use predefined roles.

\>>>second, custom roles can only be applied to either the project level or organization level. They can’t be applied to the folder level.

Service Accounts

Service accounts are used to grant permissions to the compute engine virtual machines rather than to a person.

Let’s say you have an application running in a virtual machine that needs to store data in Cloud Storage, but you don’t want anyone on the internet to have access to that data–just that particular virtual machine. You can create a service account to authenticate that VM to Cloud Storage.

\>>>Service accounts are named with an email address, but instead of passwords, they use cryptographic keys to access resources.

\>>> If a service account has been granted Compute Engine’s Instance Admin role, this would allow an application running in a VM with that service account to create, modify, and delete other VMs.

\>>>Service accounts do need to be managed. For example, maybe X(a person) needs to manage which Google accounts can act as service accounts, while Y(a person) just needs to be able to view a list of service accounts. Fortunately, in addition to being an identity, a service account is also a resource, so it can have IAM policies of its own attached to it. This means that X can have the editor role on a service account, and Y can have the viewer role. This is just like granting roles for any other Google Cloud resource.

Cloud Identity

When new Google Cloud customers start using the platform, it’s common to log in to the Google Cloud Console with a Gmail account and then use Google Groups to collaborate with teammates who are in similar roles.

\>>>Although this approach is easy to start with, it can present challenges later because the team’s identities are not centrally managed.

\>>>This can be problematic if, for example, someone leaves the organization. With this setup, there’s no easy way to immediately remove a user’s access to the team’s cloud resources.

\>>>With a tool called Cloud Identity, organizations can define policies and manage their users and groups using the Google Admin Console.

\>>>Admins can log in and manage Google Cloud resources using the same usernames and passwords they already use in existing Active Directory or LDAP systems.

\>>>Using Cloud Identity also means that when someone leaves an organization, an administrator can use the Google Admin Console to disable their account and remove them from groups.

\>>>>Cloud Identity is available in a free edition and also in a premium edition that provides capabilities to manage mobile devices. If you’re a Google Cloud customer who is also a Google Workspace customer, this functionality is already available to you in the Google Admin Console.

Interacting with google cloud

\>>>There are four ways to access and interact with Google Cloud.

1. The Cloud Console

2. The Cloud SDK and Cloud Shell

3. The APIs

4. The Cloud Console Mobile App.

The cloud console:

\>>> Google Cloud Console: It is Google Cloud’s Graphical User Interface, GUI, that helps you deploy, scale, and diagnose production issues in a simple web-based interface. With the Cloud Console, you can easily find your resources, check their health, have full management control over them, and set budgets to control how much you spend on them. The Cloud Console also provides a search facility to quickly find resources and connect to instances via SSH in the browser.

The cloud SDK and cloud shell

\>>> Cloud SDK and Cloud Shell: The Cloud SDK is a set of tools that you can use to manage resources and applications hosted on Google Cloud.

• These include the gcloud tool, which provides the main command-line interface for Google Cloud products and services, gsutil, which lets you access Cloud Storage from the command line, and bq, a command-line tool for BigQuery.

• When installed, all of the tools within the Cloud SDK are located under the bin directory. Cloud Shell provides command-line access to cloud resources directly from a browser.

• Cloud Shell is a Debian-based virtual machine with a persistent 5-gigabyte home directory, which makes it easy to manage Google Cloud projects and resources. With Cloud Shell, the Cloud SDK gcloud command and other utilities are always installed, available, up-to-date, and fully authenticated.

The APIs

\>>> Application programming interfaces, or APIs: The services that make up Google Cloud offer APIs so that code you write can control them. The Cloud Console includes a tool called the Google APIs Explorer that shows which APIs are available, and in which versions. You can try these APIs interactively, even those that require user authentication.

• Suppose you’ve explored an API, and you’re ready to build an application that uses it. Do you have to start coding from scratch? No. Google provides Cloud Client libraries and Google API Client libraries in many popular languages to take a lot of the drudgery out of the task of calling Google Cloud from your code.

• Languages currently represented in these libraries are Java, Python, PHP, C#, Go, Node.js, Ruby, and C++.

The cloud console mobile APP

\>>>Console Mobile App: This can be used to start, stop, and use SSH to connect to Compute Engine instances and see logs from each instance. It also lets you stop and start Cloud SQL instances. Additionally, you can administer applications deployed on App Engine by viewing errors, rolling back deployments, and changing traffic splitting.

• The Cloud Console Mobile App provides up-to-date billing information for your projects and billing alerts for projects that are going over budget. You can set up customizable graphs showing key metrics such as CPU usage, network usage, requests per second, and server errors. The mobile app also offers alerts and incident management.

Google Cloud Marketplace

Google Cloud Marketplace lets you quickly deploy functional software packages that run on Google Cloud. Even if you are unfamiliar with services like compute engine or Cloud storage, you can start up a familiar software package without having to manually configure the software, virtual machine (VM) instances, storage, or network settings. You can deploy a software package now, and scale that deployment later when your apps require additional capacity.

You can select and deploy software packages from the cloud marketplace page of the Google Cloud console.

Cloud Marketplace offers many different products, and in some cases, offers a few variations of the same product; for example, Cloud Marketplace has multiple packages for WordPress.

To ensure a product meets your needs, each product has a details page that describes the VM type, operating system, estimated costs, and more.

Search for a package, and select one that meets your business needs. When you launch the deployment, you can either use the default configuration or customize the configuration to use more virtual CPUs or storage resources.

Some packages allow you to specify the number of VM instances to use in a cluster.

after this, you can use quicklab to set up a LAMP server using Cloud Marketplace. I will be writing a new blog about that

Thank you! keep supporting