Designing your Company Architecture on Google Cloud Platform
Introduction
In this blog, I am going to cover the basic aspects of setting up your company architecture on Google Cloud. It is essential that the infrastructure you develop has high cohesion and low coupling, setting up such an architecture helps you to scale your target services and apps at an incredible speed without worrying about it affecting your entire workflow. Also, a well defined and structured architecture enables faster bug tracking/fixation and prevents the problem of single-point failure.
Google Cloud Platform Resource Hierarchy
Lets first understand how the resource hierarchy needs to be set up on google cloud platform. While designing your workflow you can take a top-down or bottom-up approach whichever you prefer, understanding these concepts is easier if you take a bottom-up approach however I strongly recommend that you keep in mind the top-down approach as well when you actually begin setting up your architecture.
If you have worked on any cloud platform before such as AWS, Azure, GCP, Digital Ocean and so on you must be familiar with Virtual Machines or EC2 Instances, these comprise your CPU/GPU instances. Your Virtual Machines are organized in projects and your projects are in turn organized in folders. Folders can be organized inside parent/child folders and in the end, your folders come under Organization Node. The Organization Node is the root of your company architecture. Generation of folders is optional in GCP however I strongly recommend that you use folders inside an organization as using a well-defined folder structure will make your life a hell of a lot easier further down the line when you want to create Teams and give IAM permissions to your Team Members or Virtual Instances. Technically you can add permissions in either of the three places — Organization Node, Folder, or Project. I personally prefer the allotment of IAM permissions at a folder level as it makes management of teams and resources much easier and ubiquitous in a team environment. Only the project Owners and Admins should have the Organisation Level Permissions. The IAM permissions have a downwards Inheritance that is why Folders are the best place to assign permissions. Often in a startup environment, numerous companies end up setting up their entire tech stack inside a single project, naturally, if everything is at a single place and it would make your life easier as you won't have to create VPC’s or subnets to make the shared resources available inside your other projects, however when you start tending toward the creation of an enterprise from a startup you would realize that doing everything inside a single project was not a good idea at all. Generation of separate projects and a folder structure might seem daunting and complex at first but trust me its all worth it. The Levels of the hierarchy provide trust boundaries and resource isolation in your organization.
Here’s an example of how you might organize your resources. There are three projects, each of which uses resources from several GCP services. Resources inherit the policies of their parent resource. For instance, if you set a policy at the organization level, it is automatically inherited by all its children's projects. And this inheritance is transitive, which means that all the resources in those projects inherit the policy too.
Google Cloud Platform Console
This is the place where you manage everything. Cloud Console in the place where you can switch between your various projects. All Google Cloud Platform resources belong to a Google Cloud Platform Console project. Thus a project is a place where all your services and apps would be.
Key Features of the Project are :
● Track resource and quota usage.
● Enable billing.
● Manage permissions and credentials.
● Enable services and APIs.
Some people think that the generation of numerous projects would result in high billings and all but this is a false assumption as projects are billed and managed separately. Your billings depends on the resources you use, so it doesn't matter that they are in which project the billing amount would be exactly the same. Moreover, it might actually help you to understand which project costs you how much.
Cloud Security
Security requires a collaborative environment from both the consumer and provider ends. One of the major advantages of using any cloud platform is that you don’t have to worry about the physical security of your resources i.e VM instances and all, as often setting up on-premise security for your data centers and servers is not feasible especially for startups and new companies. Moreover, you will also have to worry about power outages due to some calamity or some other reason. Cloud servers are backed up on various regions and on numerous continents due to which a backup system is available even if one region goes down due to some unprecedented circumstances. That being said consumers need to be careful while handling Customer -managed security responsibilities. , especially the setup of IAM roles across different members/engineers of your company and limiting the accesses to specific tasks that a particular engineer needs to perform. Also, network setting should be carefully set up while exposing your apps to the external DNS or publically accessible IP’s. Negligence on this part might often become catastrophic if some hacker gets wind of your network vulnerabilities.
IAM Roles
There are three types of IAM Roles:
- Primitive Roles: IAM primitive roles apply across all GCP services in a project. Primitive roles are broad. You apply them to a GCP project, and they affect all resources in that project.
These are the Owner, Editor, and Viewer roles. 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. The owner role on a project lets you do one more thing too: you can set up billing. Often companies want someone to be able to control the billing for a project without the right to change the resources in the project, and that’s why you can grant someone the billing administrator role.
Primitive roles provide segregation at a higher level but personally I do not prefer primitive roles for all tasks because things in real like production scenarios are not as ideal as primitive roles make them seem. We often need fine-grained roles in order to create appropriate segregation of resources and accesses across all members of our organization.
2. Predefined Roles: These roles apply to a particular GCP service in a project. GCP services offer their own sets of predefined roles, and they define where those roles can be applied. This is the role management that any initial stage startup should use. However, these roles are often better defined at a folder level rather than at user level in an organization as these are very fine-grained privileges, and maintaining them at a user level would become a tedious task as the organization grows and the number of employees increases. Maintaining this at the user level is not a viable or feasible option at all.
3. Custom Roles: These roles let you define a precise set of permissions. What if you need something even finer-grained? That’s what custom roles permit. A lot of companies use a “least-privilege” model, in which each person in your organization the minimal amount of privilege needed to do his or her job. So, for example, maybe I want to define an “instanceOperator” role, to allow some users to stop and start Compute Engine virtual machines but not reconfigure them. Custom roles allow me to do that.
Using Custom roles comes under the category of the higher level of IAM role management and early phase startups should avoid these as maintaining and setting these up is a herculean task and would need a good solid team to set this up and manage it. If you decide to use custom roles, you’ll need to manage the permissions that make them up. Some companies decide they’d rather stick with the predefined roles. Second, custom roles can only be used at the project or organization levels. They can’t be used at the folder level.
Service Accounts
Services accounts are used in the case when you want to give accesses to a resource rather than to a person. For instance, maybe you have an application running in a virtual machine that needs to store data in Google Cloud Storage. But you don’t want to let just anyone on the Internet have access to that data; only that virtual machine. So you’d create a service account to authenticate your VM to Cloud Storage. Service accounts are named with an email address, but instead of passwords, they use cryptographic keys to access resources.
In this simple example, 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.
Here’s a more complex example. Say you have an application that’s implemented across a group of Compute Engine virtual machines. One component of your application needs to have an editor role on another project, but another component doesn’t. So you would create two different service accounts, one for each subgroup of virtual machines. Only the first service account has privilege on the other project. That reduces the potential impact of a miscoded application or a compromised virtual machine.
Summary
Company Hierarchy: Company hierarchical setup is a very important task and should never be done in a rushed manner as it is the base for your entire tech stack and your product, spend as much time as needed in order to set up the best infrastructure for your organization. An Organization Node > Folders > Projects > Resources architecture customized as per your organization is a good option, to begin with.
Security: Good collaboration needs to be maintained between the customer and the provider in order to make your apps/services highly secured. Customers mainly need to work on IAM Role level and Network level for securing their organization.
Role Management: Startups should prefer using Predefined Roles allocated at a folder level or use service accounts for the role management purpose.
Thank You !
My LinkedIn : Visit Me on LinkedIn
