Resource Hierarchy and IAM in Google Cloud
Like Nigerian politicians love to claim, no institution can thrive without a functional structure, and the same goes for Google Cloud. Let's take a look at the structure of Google Cloud's resource hierarchy. It’s important to understand this hierarchy because it directly relates to how policies are managed and applied when you use Google Cloud.
Google Cloud's resource hierarchy contains four levels, and starting from the bottom (the smallest unit) to the top, they are:
resources,
projects,
folders, and
an organization node
Policies, permissions, and definitions in the hierarchy are inherited downward. This means if you define a policy at the folder level, it will affect everything below it but it won't affect the organization level.
Let's take a deeper look at each level.
Resources are the first and smallest unit of the hierarchy. They are the individual Google Cloud "resources," like virtual machines, storage buckets or tables. They are organized into projects and can only exist inside a project.
Projects are the second level of the hierarchy. They act as the basis for enabling and using Google Cloud services. Each project has three attributes: Project ID, Project name and project number.
Folders: are the third level of the hierarchy. They can contain projects, folders or both. Each resource will be grouped into different folders. Each resource in a folder will inherit all it's properties. If you want to make duplicate projects with the same permissions, it's better to keep them both under the same project rather than having to change both of them.
To create folders, you need to have an organizational node, which is the highest resource in the Google Cloud hierarchy.
Organization node: This is the topmost level of the hierarchy. Everything attached to an account goes under this node. There are also some special roles and permissions associated with it.
Analogy: To give a description of the resource hierarchy, you can liken it to a company structure. Each company (the organization node) will have departments (the folder); each department will have different staff under them (projects), and each staff member is entitled to a workspace with several resources. Any policy that affects a department will affect each staff member in that department, but not necessarily the whole company.
When there are a lot of resources, a company might need to restrict who has access to what. This is where IAM comes in
Identity and Access Management
Identity and Access Management (IAM) is a foundational principle essential for maintaining control and visibility over Google Cloud resources. It empowers administrators to meticulously authorize actions on specific resources, enabling centralized management.
In an organizational context where numerous resources coexist, the necessity arises to impose restrictions on access. This imperative stems from the dual objectives of ensuring security and holding individuals accountable for their actions within the cloud environment.
IAM acts as the linchpin in achieving these objectives. It operates through a set of policies that delineate the who, what, and which of resource access.
The "who" pertains to authenticated users, often referred to as principals. These principals can take various forms, such as a Google account, a Google group, a service account, or a cloud identity domain.
The "what" corresponds to the permissions or roles assigned to authenticated users. IAM defines the level of authorization granted to each principal, dictating what actions they can perform on Google Cloud resources.
The "which" dimension encompasses the specific resources on which these permissions apply. IAM allows administrators to specify the exact scope of access for each authenticated user, ensuring a finely tuned control over Google Cloud resources. In essence, IAM serves as a robust framework that harmonizes the who, what, and which elements, providing a comprehensive solution for effective resource management.A role is categorized with all the levels of permissions that it has. For example, to manage virtual machine instances in a project, you must be able to create, delete, start, stop, and change virtual machines. All these permissions are grouped into a single role to make it easier to understand and manage.
When a principal is given a role on an element of the resource hierarchy, the resulting policy applies to both the chosen element and all elements below it in the hierarchy.
You can also define deny rules that prevent certain principals from having certain permissions, regardless of the roles they already have. This means that deny rules are superior to allow rules.
Types of IAM roles
There are three kinds of roles in IAM: basic, predefined, and custom.
Basic roles: These are the most broad. They include project viewer, project editor, project viewer, and billing administrator.
Project viewers can access the resource but can't make changes.
Project editors can access and make changes to the resource but can't do anything else.
Project owners can access and make changes to the resource as well. In addition, they can also manage the roles and permissions and set up billing.
Billing administrators are specialized roles that are used when companies want someone to control billing on a project but nothing more. They can access the resource and set up billing.
Predefined roles: If several people are working on a project together, basic roles are probably too broad. That's when predefined roles come in.
Predefined roles are more streamlined roles that are offered by specific Google Cloud services. These services also define where the roles can be applied. With any Google Cloud product, you can apply specific predefined roles that then allows whoever has those roles to perform predefined actions on resources from that product. (might talk about an actual example of compute engine)Custom roles: What do you do when you need to assign a role that has even more specific permissions? Well, you should use custom roles.
Since many companies use a least-priviledge model in which each person in an organization is given just the exact amount of priviledge needed to do their job, they might find even predefined roles giving principals more permissions than they'd like or just not giving the exact combination of permissions they need. Custom roles allow you define those exact permissions.There are two things to note when considering custom roles though:
The company will need to manage the permissions that define the custome roles that have been created.
Custom roles can only be applied to either the project level or organization level. Not the folder level.
Because of these, some organizations rather just use the predefined roles.
In conclusion, the seamless integration of resource hierarchy and Identity and Access Management (IAM) not only fortifies the structural integrity of Google Cloud resources but also empowers organizations with the agility and control needed to navigate the complexities of a dynamic digital landscape. By leveraging the dual pillars of resource hierarchy for organized structure and IAM for nuanced access controls, businesses can confidently embark on their cloud journey, fostering a secure and efficient environment where innovation thrives and accountability reigns supreme.
