Google Cloud Landing Zone Comparison

When researching how to set up your Landing Zone in GCP you come across different options provided by Google. In this blog post, we compare several key aspects of the different solutions. We had a deep look into these solutions and rolled them out in a GCP Test Organization to evaluate how they perform. After reading this blog post you will understand what the different options are, which features they provide, how easy it is to use them and which option fits best to your use-case.

Your Options to Create Google Landing Zones

Google Cloud setup checklist

In the GCP web console, you can easily set up a basic cloud foundation via a wizard called “Set up your Foundation”. It is based on the Cloud setup checklist by Google. It covers the most relevant topics that should be considered for a secure and scalable cloud foundation.

It does not apply most of the configuration directly via the web console but generates Terraform Modules. So the wizard is a nice and handy frontend for configuring some Terraform. You are guided very well through the different things that will be applied and how they are configured.

Cloud Foundation Toolkit - Example Foundation

Based on the Cloud Foundation Toolkit, Google provides a Terraform Example Foundation. It can be used as a basis and customized to individual needs. It already applies best practices and reasonable defaults that should fit many companies.

Terraform Modules are structured into different stages (bootstrap, org & resource hierarchy, environments, networking, projects, and app infrastructure). After bootstrapping the basic structure and projects by executing Terraform, it provides the option to roll out the remaining stages via CICD. Google Cloud Build and Jenkins are supported for this. But you still have to prepare the different stages by executing several commands manually before the deployment is triggered via CICD. For execution via CICD, it uses a Google Cloud Git repository per stage.

Do you need support building your Landing Zone? Book a free expert call here, to learn more about modular Landing Zone Best-Practices.

💡 We did not complete rolling out the Example Foundation as we ran into permission issues we couldn’t figure out. As we came to the conclusion that Fabric FAST is the more mature and future-proof approach, we decided not to dig deeper into rolling out the example foundation. Details about this can be found in the next sections.

Cloud Foundation Fabric FAST

Cloud Foundation Fabric is the latest approach by Google to provide a landing zone solution based on the Cloud Foundation Toolkit that is easier to apply, extend and roll out than the Terraform Example Foundation mentioned before. The result of this is the production-ready blueprint for a secure organization called Fabric FAST. It is a set of Terraform modules structured into stages (bootstrap, cicd, resource hierarchy, security, network, project factory, data platform).

Fabric FAST comes from engineers in Google Cloud's Professional Services Organization, with a combined experience of decades solving the typical technical problems faced by GCP customers.

Beyond setting up and configuring a secure Organization and Resource Hierarchy it also provides a Project Factory which enables a GitOps Workflow to provision new projects.

Initially, you need a Super Admin for Google Workspace to set up some groups and assign people to these groups. Afterward, everything is done via Terraform.

Comparing GCP Landing Zone Options

For this comparison, we assign 1 to 3 ⭐ for different aspects that we look at for the three options. If a certain aspect is not covered at all we assign a ❌. Additionally, you can find some details about why we rated an aspect. These details also provide a deeper insight into how these aspects are covered within the options.

GCP Landing Zone Feature Comparison

The feature comparison is based on the Cloud Foundation Maturity Model (CFMM). You can read details of what these blocks mean on the CFMM Website. You can also follow the links in every row that redirect you directly to the details of the according CFMM block.

GCP Landing Zone Non-Functional Comparison

Which GCP Landing Zone Should I Pick?

The Terraform Example Foundation from the CFT should not be used anymore as Fabric FAST supersedes it and provides a way cleaner and usable approach. With the Example Foundation you have to execute >20 commands per stage manually (there are 6 stages in total). We also heard from one of the Google Consultants, that Fabric Fast is the direction they want to go to in future. As we tried to roll out the Example Foundation, we noticed that it is way more painful to use than Fabric FAST and it feels way more hacky.

The Google Cloud Setup Checklist is a nice and small solution that fits well for smaller companies or companies just wanting to get started quickly with their Cloud Journey in a reasonably secure environment. It also allows growing your foundation step-by-step by extending the generated Terraform modules to your needs.

But, if you have a really big cloud foundation in mind, the Terraform Modules provided by the Cloud Setup Checklist might not suffice to scale them to something large. It also doesn’t contain solutions for advanced problems many companies face. If you want to grow your Cloud Foundation Landing Zone, you should better consider starting with Fabric FAST right from the beginning as it applies a sophisticated IAM and PAM concept and a scalable structure to organize your Terraform modules with those stages. It also provides more features that make sense for many companies.

Starting with the Google Cloud Setup Checklist first, and adopting Fabric FAST later on is also a feasible option. Both use the same user groups and adopting the resource hierarchy, networking, and audit logging should also be possible as they don’t differ drastically.

Did this blog post help you decide which Landing Zone Solution you will apply to our GCP Org? Did you already gather your own insights to building a GCP Landing Zone and want to back up, add or discuss insights from this blog post, please do so and leave a comment! We look forward to hearing about your experience.

by Stefan Tomm

meshcloud receives funding for the cloud security approach "MultiSecure" by the German Federal Ministry of Education and Research (BMBF)

It’s been a while since we announced that we’ve been funded for our MultiSecure project. We are still very excited about the great news and have already been working hard on putting our vision into practice: We want to enable organizations to code their cloud security regulations along with their applications and infrastructure.

Additional Information:
Starting in April 2020 meshcloud receives funding by the German Federal Ministry of Education and Research (BMBF). The funded project with the title “MultiSecure” aims to create a declarative technology to describe secure multi-cloud infrastructures and organizations. It addresses the need of organizations to establish an effective way to handle security requirements as well as control on the infrastructure in their cloud transformation.

Implementing secure cloud configurations is a major challenge for large organizations

By now most large organizations already use cloud computing infrastructure for application development. Flexible on-demand access to different types of cloud resources as well as a shift towards agile methodologies enable them to accelerate their software delivery capabilities and drive innovation. Cloud service providers like Amazon AWS, Google Cloud Platform or Microsoft Azure provide a vast and continuously growing portfolio of cloud services to address these needs. As the adoption of cloud computing increases, cloud environments become more complex and are harder to control. Looking at the market, we observe that in many cases the “experimental” use of the technology has been overcome, requiring consistent, automated processes to allow for a further scalable adoption.

Security Responsibilities have shifted and decentralized across the organization

We are facing increasingly complex cloud environments. In addition to that a shift in responsibilities has occurred: While central IT departments used to be responsible for the majority of security aspects on the infrastructure layer, this responsibility has shifted and decentralized. Many services are directly provided by the cloud providers rather than the central IT departments, relieving central IT from part of the responsibility. To learn more about Shared Responsibility, check out our (Guide on Cloud Security and Compliance). On the other hand DevOps teams that use the cloud have to take care of the security on the infrastructure and application layer. Mistakes in the configuration of infrastructure are security-critical. Incidents as happened at Capital One demonstrate the risk.

This shift in responsibility raises 3 questions:

• How can central IT departments achieve control on the organization’s cloud infrastructure ?
• How can organizations handle policies across clouds and across teams ?
• How can organizations enable DevOps teams to focus on functional requirements of their application ?

Without consideration of these questions, an organization is likely to lose itself in shadow IT, immense complexity and an enormous non-functional overhead in application development.

Cloud Environments are complex, dynamic and durable

Let’s look a bit deeper into the organizational context of a cloud project. Here is an exemplary process of providing a cloud environment to a DevOps team:

• A team member, most often a team lead, requests a cloud environment for a specific cloud platform for his team.
• The environment, also known as a cloud tenant, has to be created.
• Permissions on different levels (e.g. admin/developer) have to be provided to the team members.With these permissions in place the team will have access to their cloud environment and the corresponding services.
• DevOps teams have to demonstrate compliance with the organization’s security frameworks to get an approval to bring their application to production. Therefore, before deploying an application to the cloud environment, cloud environments are usually configured to follow corresponding security controls.
  

Mostly, these configurations are not workload-specific, they cover organizational aspects of different areas like identity and access management, server geography, service configurations or cloud budgets. These are some examples:

Defining, implementing and maintaining them over time is a major challenge (Read more on this in our post on the Cloud Landing Zone Lifecycle). Especially at a large scale, organizations face the following difficulties:

• In some cases, DevOps teams receive access without prior configuration of the cloud tenant. The compliance then has to be approved retrospectively leading to additional effort and change requirements when the application has already been deployed, rather than preventing them to occur.
• If the cloud tenants are configured manually and by each team individually there is a high risk for inconsistencies, due to mistakes.
• Security controls are mostly defined abstractly and in natural language. Their interpretation is often up to the person that technically implements them which again leads to inconsistent results, even if done correctly.
• Cloud service providers offer different ways to put these configurations into place. For multi-cloud environments this makes it even harder to implement consistent policies across different cloud service providers.
• With large amounts of cloud tenants these inconsistencies multiply and with no system in place that provides cross-cloud transparency, an effective implementation and control of the measures is hard to achieve.

Today’s IT organizations have to find the right balance between, which leads to a demand for new security approaches:
the agility and technological freedom DevOps teams need to leverage the cloud for a better software delivery performance
AND
the control and governance an organization must have to on their infrastructure to act responsibly and mitigate security risks. Finding this balance requires new approaches to IT security.

In a perfect world security rules and requirements are unambiguous and easily interchangeable between Stakeholders

In many cases policies bring together different stakeholders and their implementation requires the cooperation of multiple departments within an organization and beyond it. Let’s consider a compliance department: They define policies in natural language. These policies then have to be implemented by IT teams and will later be audited by an external party. While standards like the ISO/IEC 27000 family have led to alignment and a common vision of best practices in the field of information security, we still face a lot of uncertainty, when it comes to the adoption and implementation of these standards within the organization in connection with new technologies and working methods.

Textual explanations are oftentimes ambiguous and it is hard to judge, whether a control has been appropriately fulfilled or not.

In a perfect world, security organizations would be formalized, e.g. put in “code” to avoid unstructured and intransparent document battles. Rules and requirements would be clear and therefore could be communicated precisely. Suppliers, customers and companies would have a common basis for communication.

MultiSecure unifies and formalizes security and organizational rules to establish a consistent and transparent security framework for organizations

With the MultiSecure project, meshcloud aims to overcome this uncertainty and increase transparency when implementing security policies within the organization. MultiSecure bridges the gap between clearly defined security controls, custom organizational processes and the cloud infrastructure providers.

The idea – A declarative projection of the organization

The idea of MultiSecure is to describe organizational elements and their relationships as code in an open and reusable format - a declarative manifest that represents the desired target state of the organization. The information in that manifest follows a clear structure and can be handled as source code:

• It can be versioned,
• it is at all times clear who made changes to the target state definition and
• it can automatically be compared and synchronized with the actual state of the multi-cloud environment.

MultiSecure allows to centralize this information in an open format, instead of squeezing the organization into the envisaged organizational models of the cloud providers and therefore maintaining multiple proprietary organizational models in parallel and distributed. It builds a projection of the organization that can be consumed by different systems.

This is where meshcloud and our software platform meshStack come into play. meshStack consumes this organizational information either manually via our user interface or via API and automatically replicates it into the different cloud service providers, taking into account their specific native tools, services and best-practices.

The Benefits – A comprehensive IT security framework and avoidance of vendor lock-in

We already mentioned the benefits of having code to avoid ambiguities in terms of interpretation of security controls. Here are the main benefits we see regarding the overall governance of IT infrastructure within the organization.

1. An integrated security concept:
By enabling organizations to define policies centrally and in an open format, that can be applied to various cloud providers, MultiSecure provides an integrated security concept for the use of cloud technologies.

2. Reducing vendor lock-in:
Uncoupling organizational processes and security requirements from a specific cloud provider, empowers organizations to keep sovereignty over their infrastructure and choose their preferred cloud provider(s) self-determently.

3. Reducing IT security risks with preventive measures:
Configuring cloud environments to comply with security requirements, before handing them over to their users (DevOps teams) is one of the core concepts behind MultiSecure. It does not only prevent misconfigurations that could lead to security breaches, but relieves DevOps teams from non-functional requirements.

4. Made for scale and a sustainable IT strategy:
The declarative nature of MultiSecure allows for a sustainable and scalable security strategy. Cloud environments can be created fully automated fulfilling a rising demand for infrastructure of any provider. Furthermore, the approach takes into account the lifecycle of applications and policies, with mechanisms for updates and long-term operations in place.

The scope – Infrastructure as Code vs. Security as Code

The concept of a declarative manifest is not new to the cloud world. Known as “Infrastructure as Code” it has been popular for the deployment of cloud infrastructure. We are not aiming to cross this field. That is why we consider workload out of scope of the project. There are already great solutions around (e.g. terraform, ansible) to define resources within cloud environments. As meshcloud, the MultiSecure project focuses specifically on the organizational aspects of security and governance and can be considered the “terraform” for security and the organization.

Join the MultiSecure Community to shape the Future of Cloud Security

We strongly believe that this project will benefit from the contribution of diverse stakeholders. Even before the official launch of the project, we’ve received excellent and supporting feedback from customers as well as partners. We’d be more than happy to have you on board for our mission, too.

To keep up to date, we kindly invite you to

• Follow us on Twitter @secascode

We are interested in your use cases. If you see any touchpoints to MultiSecure, we’d be more than happy to discuss and get in touch with you. Reach out to us with your questions.

by Christina Kraus