How to Organize Resources in Google Cloud

Organization of resources, or the basics

Before we begin organizing the organization’s IT policies, the first thing we need to do is... to organize the organization itself. Is it clearly divided into specific units (departments, divisions), are procedural responsibilities clearly assigned? Who needs access to what kind of data? And who should be restricted for security reasons? For mature companies, this is quite obvious, but smaller companies or those that have grown rapidly (e.g. which tripled their headcount within one year) may struggle with these decisions. Many processes are not yet formalized, and problems that arise are solved on an ad hoc basis, without adopting system solutions.

If the management of the company or organization (public office, foundation, etc.) has its procedures in order, they can move to the planning stage, i.e., to determine how to map the IT structure. Although you might be tempted to move to the deployment phase as quickly as possible, i.e., to the migration of your IT resources to the Google Cloud platform, we encourage you to take the time to plan the process well. Even something as simple as creating an appropriate folder naming convention will allow users to work more efficiently on a daily basis and adapt to organizational changes in the future.

The ABCs of Google Cloud

You can start your adventure with Google Cloud by creating projects in a flat, unorganized structure. As your projects grow, you will find that managing the right privileges becomes difficult, if not impossible. Let’s take a look at the organization of resources in Google Cloud and what instruments you can use.

Privileges to access resources are inherited in the “general to specific” or “top–bottom” model. Let’s start presenting them from the “top.” Below is a diagram of the resources hierarchy:

Source: IAM policy inheritance, Google LLC

Organization

It is a superior level that groups the company’s resources. You do not need to create the entire organization to use Google Cloud, but we do recommend at least setting one up. If you do not set up the organization, some of the operations at the Resource Manager level will not be available. Metaphorically speaking, an organization is your entire company. Another analogy would be a corporate domain.

Folders

Folders group together projects or other folders. It may be assumed that every department in the company has its own folder. This allows folders to be separated, e.g. by granting specific permissions, since the permissions granted to a folder are automatically granted to the resources below it (subfolders, projects, resources in projects). Folders can be nested as desired, for example, when there is a list of folders (one folder per department, or per product) directly below the “Organization” level, each such folder can be subdivided into people, clients, or environments.

The decision on how to use folders depends on the needs of the organization and its specific nature. We almost always recommend implementing and using this level, although as is true at the organization level, setting up folders is optional. In order to use folders, you must first set up the organization. Folders can be managed freely once they have been created.

Projects

Projects can be likened to instances of a product we need to launch. For example, if you have an online store software with a database and a number of additional services (e.g. microservices responsible for handling payments, sending texts, or even handling the flow of goods), then such a complete store instance is your project. It can come in several versions, such as the three basic versions below, which map to runtime environments:

• development – a version used for development work and internal testing by developers;
• test – a version used for testing by testers and business owners;
• production – a version that works in production and is accessible to end users.

Each of the versions cited in the example above could be a ”project.” This is the kind of resource organization that we most often recommend to our clients.

Resources referenced within a project are only visible at the project level. This is important for a number of reasons. For example, it allows you to separate environments, which is crucial for maintaining appropriate level of security and efficient work organization.

You can assign Labels to projects that can be used for filtering, e.g., billing information. Labeling is a very good practice that allows for multidimensional grouping of projects and resources. You can assign many Labels. They come in the form of “key: value” and can be associated with any information (e.g., the business owner of a particular project, the user who set up the project, details about its nature).

Moving projects between folders is very simple, and you can do it yourself. However, transferring a project between organizations requires proper preparation and contact with Google Support.

Resources

Resources are entities such as virtual machines, container orchestration platforms, databases, queues, and storage. Simply put, it is everything that contributes to the proper operation of the project and is an integral part of it. It is also the lowest level of abstraction of permission inheritance.

Note: it is not possible to transfer a resource between projects and this usually means that the resource must be recreated in a new project, e.g. from a backup, disk image, or using the Infrastructure as code mechanism. Like projects, resources can be given labels, which is definitely worth doing.

First steps

Here are the steps to follow before migrating your business to Google Cloud and/or G Suite.

1. Set up the organization

There are 3 ways to set up your own Google organization:

• by subscribing to the G Suite service;
• by subscribing to the Cloud Identity Premium service;
• by using the Cloud Identity Free service, whose limitations are discussed below.

The first two services require payment. Licenses are purchased for individual user accounts and include: In the case of G Suite – a full office suite under your own domain (Gmail, Google Drive, Google Docs etc.) and a console for comprehensive management of the organization, e.g.. users or security policies. For details, visit: G Suite price list. In the case of Cloud Identity Premium – a console to manage the organization, users, security policies and more, but without office services. For more details, visit.

The third option, Cloud Identity Free, is available for free but it is limited to 50 accounts. Detailed comparison of Cloud Identity Free and Premium versions.

In order to use Google Cloud services (without an organization) using a corporate email address, you need to:

• visit here;
• create a new account by selecting the option: “Use my current e-mail address instead,” and enter your business e-mail address.

A Google Cloud Identity will be created for the corporate account, which will allow you to use Google Cloud Console and other Google services.

2. Setting up user groups

In line with best practices, access to specific folders, projects or resources should be granted through user groups rather than individuals. Group membership should be limited and managed by administrators at the Cloud Identity level.

A Google group created within an organization has the domain name of the organization, e.g., group-name@example.com. At this stage, it is useful to come up with an adequate naming convention for groups so that at least the following four things can be identified by their name alone:

• that the email address is a group;
• who should be a member of the group and, more importantly, who should not be in it;
• which environments (Google Cloud folders, projects) the group has access to;
• which privileges the group should have and what kind of overall responsibility is associated with group membership.

An example of such a convention:

• group-{org, prod, test, dev}-[app1,moduł2]-{admin, editor, viewer}-[ext]@example.com

Here are some examples of such a convention:

• group-prod-viewer@example.com – a group with read-only access to all production applications (e.g. Security Department);
• group-prod-reports-viewer-ext@example.com – a group of people outside the organization with “read-only” access to reporting modules in all production applications;
• group-test-editor@example.com – a group having access to all Google Cloud resources in the test environment with permissions to edit/create/delete, but without the permission to modify the permissions tree.

Once the conventions have been introduced and relevant groups have been created, the first users can be assigned to them and the addresses of these groups can be used to grant permissions for specific resources in Google Cloud. You can safely allow situations where you have one or two people in one group. It is a small effort that will pay off as the organization grows and evolves – you will only need to add an employee later on.

Active Directory (and Azure AD) or LDAP integration capabilities

If your company has so far used Microsoft Active Directory or LDAP (Lightweight Directory Access Protocol), you can continue to do so. There is no need to set up additional accounts for users. We recommend that you read the following articles:

• Federating Google Cloud with Active Directory;
• Federating Google Cloud with Azure Active Directory.

3. Folder organization

Google recommends organizing the folders by departments.

However, there are other variants of folder structure in organizations. For smaller companies that do not have an extensive organizational structure, we recommend creating folders for each environment (DEV/TEST/STAGE/PROD), within which all projects are grouped by relevant environment. This approach makes it easy to grant access to the appropriate group (e.g., the Security Department) to view all test and production projects. Such access is then defined at the folder level (in this case TEST and PROD folders) rather than individual projects. This approach has an obvious advantage: when a new project appears, the Security Department can immediately explore it.

Regardless of your convention, it is considered good practice to create appropriate folders at this stage.

4. Create the project and reference resources

At this stage, you can create a project and reference the specific resources needed to implement it. Thanks to good organization in the earlier stages, you will be able to separate the environments, and conveniently and securely assign permissions in the next step.

5. First IAM configuration using previously created groups

Now you can proceed to configure IAM (Identity and Access Management). This is the stage where you grant access to specific resources to individual accounts and groups. You can specify “who” can perform “what kind of activities” within “which resource.” Remember to use user groups only. When you realize at this stage that the list or range of groups does not suit your needs, you can modify them as necessary. Just remember that it is best practice to grant the minimum privileges required to perform tasks (“least privilege principle”).

6. Creating a billing account

In order to use Google Cloud, you must have a billing account. This allows you to specify billing information, such as credit card or company details.

The cost of using Google Cloud or G Suite depends not only on the usage of resources, but also on the partner you use to purchase access to the services. Billing accounts billed through OChK offer very favorable pricing terms. This is why we encourage you to link your billing account to our “master” account for immediate cost savings.

7. Migration of projects from/to another organization

Once you have a project in another organization you can migrate it to yours; however, there are a number of "up-front" steps involved, as well as contacting the Google Cloud support team. You can read more about it here.

You can easily assign projects created before the organization was established (or not assigned to any organization) to your organization. Read more.

Settle Google Cloud via OChK and pay less

If you are already a Google Cloud user, you can easily reduce your public cloud bill. This is only a change in billing – it does not require migration, and does not affect service availability. In order to change your billing, please contact our Sales Department, sign an agreement and benefit from preferential pricing by linking your billing account to our master account. Here is what the process looks like technically once the agreement is signed:

1. Sign in to Google Cloud console.
2. From the selection list in the top bar, choose the project for which you want to link/change the billing account.
3. In the Dashboard of the selected project, select “Billing” from the hamburger menu.
4. If you already have your own billing account, you can either choose “Go to linked billing account” or “Manage Billing Accounts” – please choose the latter option, “Manage Billing Accounts.”
5. Switch view to “My Projects.”
6. You can now see all your projects in the list, including the one for which you want to change the billing.
7. Click the 3 dots in the “Actions” column next to the specific project and select “Change billing.” The “Set the billing account...” window appears – select an account from the list: “Chmura Krajowa – <TWOJA_NAZWA_KLIENTA> – (…).”

We hope we have helped you find your way in the world of Google Cloud's organization. If you have any questions, feel free to contact us.

See you in the cloud!