Kategorie: Google Cloud

Naming Conventions

In the last blog post, we talked a lot about resource hierarchies. Resource hierarchies help to group projects into a folder structure and help with issues like governance, automation, access control, billing and cost management and other things.

Advantages of naming conventions

Another important issue for building up a scalable landing zone are naming conventions. Naming conventions bring up advantages for your environment, let’s shortly name some of them:

Clarity and Readability: Good naming conventions help in clearly identifying resources, their purpose, and their relationships. This enhances readability and understanding for anyone who interacts with the cloud environment, from developers to system administrators.

Consistency: Consistent naming makes it easier to manage resources across your different teams and projects. It reduces confusion and helps in setting standard practices for operations within the cloud environment.

Automation and Tooling Compatibility: Automated tools and scripts often rely on naming patterns to select and manage resources. Consistent naming conventions ensure that these tools can function correctly and efficiently, whether they are used for monitoring, provisioning, or management.

Security: Proper naming can aid in implementing security policies. For instance, names can indicate the sensitivity level of data stored in a resource, or whether a resource is in a production or development environment, helping in applying appropriate security controls.

Cost Management: Naming conventions can also aid in tracking and managing costs. By identifying resources clearly, organizations can monitor usage and costs more effectively, making it easier to optimize resource allocation and reduce wastage.

Examples of naming conventions

So there are clearly a lot of advantages of naming conventions, so let’s continue with that and provide some examples.

For projects you might want to embed some information within the project name. Common components might be:

• The stage of the project, e.g. Test, QA or Prod
• If you have a CMDB in your place, you might reuse some kind of service numbers or project numbers and embed them in the project name.
• The purpose of the project, for example a network project, a project for storing audit information

In Google, it is also important to remember that project ids cannot be changed, but project names can be changed. So if a project number or something changes over time, changing the project name is possible, but changing the project id is not. That’s why it might be better to use a surrogate as the project id, and a descriptive name for the project name.

Another thing to consider is that resource ids might not be re-used – at least not immediately. For example, if you delete a project it will be first be in the trash for something like a month until it is eventually deleted. In this time, the name for the resource cannot be resued. Luckily, you can easily deal with the problem by appending some random suffix on your ressource.

Another important thing is to clearly adhere to the naming standard – even in edge cases. For example, if you separate your components in your project name by means of “-“, you can run into problems if your descriptive name also use “-“.  Here is a small example:

Good: p-1234557-landingzone-ab123

Bad: p-1234566-landing-zone-ab123

The latter example might break your automation processes later, because you cannot clearly figure out the purpose of the project anymore.

Also important, while naming conventions are important, you do not need naming conventions for everything. Cloud providers and Google is no exception here have hundreds of services and components and if you come up with a naming convention, you would only be busy with setting up and enforcing naming conventions.

Labels

Beside naming conventions, cloud providers also allow the use of labels to store metadata information. Here are some examples of labels you might encounter or use in a cloud setting:

Environment

env=production
env=staging
env=development
env=test

Project or Application

project=finance-app
project=customer-portal
app=inventory-management
app=hr-system

Owner or Team

team=backend
owner=joseph.cooper
team=frontend
owner=devops-team

Cost Center or Budget

cost-center=12345
budget=2024-Q1
cost-center=67890
budget=annual-2023

Automation Support

To demonstrate the how you can use automation for working with projects, let’s take a look at a Python snippet. In Google, you use the Resource Manager API for working with projects. Luckily, like for all APIs, there is a comprehensive library to be imported:

from google.cloud import resource_manager
 
def list_projects():
 
    client = resource_manager.Client()
    projects = client.list_projects()
 
    project_ids = [project.project_id for project in projects]
 
    # For debugging or direct response, convert list to string
    return str(project_ids)

As you can see, automation in the Google Cloud is really easy. For many use cases, the best way to deploy such scripts, is to use a Cloud Function and trigger it manually, with a schedule or based on some event.

After we have outlined the importance of a Landing Zone for a successful cloud journey in the first part and having discussed Cloud Identity and its federation with Active Directory and Entra ID, now it is time to move to next part of our Landing Zone series – Resource hierarchies.

The Google Cloud is an excellent choice for your cloud journey – and the resource hierarchy is certainly one of the (many) reasons for it.

What is a resource hierarchy?

Let’s begin with what a resource hierarchy actually is.

In Google Cloud, a resource hierarchy is a structured framework that organizes all the resources (like VM instances, storage buckets, databases) you use on Google Cloud Platform (GCP). This structure is crucial for managing and administering your resources, especially as it pertains to organizing, managing access and permissions, and tracking costs. The hierarchy provides a clear, logical structure for grouping and segregating resources, facilitating governance, and cost management across an organization.

The hierarchy levels, from broadest to most specific, are:

1. Organization: The top-level container that represents your company. It is the root node in the Google Cloud resource hierarchy and provides centralized visibility and control over all GCP resources. Organizations are associated with a Google Workspace or Cloud Identity account.

2. Folders: Folders can contain projects or other folders, allowing you to group projects that share common attributes, such as the same team, application, environment (development, test, production), or other categorizations relevant to your organization. Folders help you manage access control and policies at a more granular level than the organization.

3. Projects: Projects are the fundamental grouping of resources and services in GCP. Every resource belongs to a project. Projects serve as a basis for enabling and using GCP services like compute engines, storage buckets, and database services, tracking and managing Google Cloud costs, managing permissions, and enabling billing. They can be used to represent logical divisions like different environments (prod, dev, test) or different parts of your organization.

4. Resources: At the bottom of the hierarchy, resources are the individual GCP services and components you use, such as Compute Engine instances, Cloud Storage buckets, or BigQuery datasets. Resources inherit policies and permissions from the project they are part of and can have additional policies applied directly to them.

This hierarchy allows you to apply permissions and policies at the level that makes the most sense. For example, you can set broad policies at the organization level (applicable to all resources within the organization), more specific policies at the folder or project level, and highly specific policies at the resource level. The structure also simplifies billing and resource management by allowing you to group and manage resources based on your organization’s operational needs and structure.

The following picture depicts a resource hiarchy in the Google Cloud:

What are design considerations for a resource hiarchary?

Designing a resource hierarchy in Google Cloud requires careful planning and consideration to ensure it effectively meets your organization’s needs for governance, cost management, security, and compliance. The design should be scalable, flexible, and capable of adapting to future changes in your organization or technology strategy. Here are some key considerations:

1. Organization Structure

Align the hierarchy with your organization’s structure to facilitate management and operational efficiency.

Consider how different departments, teams, or business units will use Google Cloud resources and how you can best structure projects and folders to reflect these use cases.

2. Resource Management and Governance

Plan for how resources will be managed, including who will have administrative control at various levels of the hierarchy.

Determine how to implement policies for resource usage, access control, and cost management effectively across the hierarchy.

3. Access Control and Security

Use the principle of least privilege to manage permissions; grant users only the access they need to perform their roles.

Structure your hierarchy to simplify the management of IAM policies and ensure secure access to resources.

Consider using folders to delegate administrative responsibilities and segregate environments (e.g., development, staging, production) for enhanced security.

4. Billing and Cost Management

Organize projects in a way that aligns with your billing and budgetary requirements.

Utilize folders to group projects by cost center or department to simplify billing management.

Leverage billing accounts and subaccounts effectively to manage and track costs.

5. Compliance and Regulatory Requirements

Ensure your resource hierarchy supports compliance with relevant laws and regulations.

Structure your hierarchy to isolate resources subject to specific regulatory requirements, facilitating easier compliance audits and controls.

6. Scalability and Flexibility

Design for future growth; consider how new teams, projects, or services can be added to the hierarchy without major reorganizations.

Ensure the hierarchy allows for flexibility in resource management, scaling, and reorganization as needed.

7. Environment Segregation

Clearly segregate resources for different environments (development, testing, production) to prevent unintended access or changes to critical systems.

Use projects or folders to isolate environments, applying policies and permissions accordingly to manage access and resource deployment.

8. Naming Conventions

Establish clear naming conventions for projects, folders, and resources to improve clarity and manageability.

Use meaningful names that reflect the resource’s purpose, environment, and associated team or department.

9. Policy Inheritance

Understand how policies are inherited in the hierarchy and design your structure to leverage this for efficient policy management.

Plan how to apply organization-wide policies (e.g., security policies) and how to override these policies at lower levels when necessary.

Are there any best practices and patterns?

So, as you can see, designing a resource hierarchy can be challenging at first sight. Fortunately, there are some patterns that can be widely seen as discussed above. As they are important, let’s recap some of them:

• Isolate environments into separate projects or folders. As a pattern you can zse folders to group projects by environment, then apply environment-specific policies at the folder level.
  
• Centralize logging and monitoring to a dedicated project. As a pattern, create a “shared services” project for centralized logging, monitoring, and auditing. Use aggregated log sinks to collect logs from all projects.
  
• Structure projects in a way that aligns with organizational billing and budgetary needs. The pattern would be to assign a billing account to projects or folders based on budgetary ownership.
  
• Design projects around logical groupings of resources that share the same lifecycle, security requirements, and team. In this case the pattern is Create projects based on applications, microservices, or teams, rather than a single monolithic project for all resources.

Introduction

After having described what a Landing Zone is and having discussed its benefits, we want to explore what components are part of a Landing Zone and where design is needed.

In detail, we want to cover the following points:

• Identity and Access Management
• Resource hierarchy
• Group creation and naming conventions
• Organizational polices
• Connectivity
• Network Design
• DNS Design
• Availability and DR Strategy

Let’s begin with Identity and Access Management

Identity and Access Management

Every Google Cloud journey starts with setting up the basic organization – and hence setting up Google Cloud Identity. Google Cloud Identity is basically free, but also has an enterprise tier with additional features. It offers a range of benefits for organizations seeking to manage user identities and access to applications and services securely:

1. Centralized Identity Management: It allows for centralized management of users and groups, making it easier to control access to resources across an organization. 
   
2. Secure Access to Applications: Google Cloud Identity provides secure, single sign-on (SSO) access to both Google services and third-party applications. 
   
3. Multi-factor Authentication (MFA): It supports multi-factor authentication, which adds an extra layer of security beyond just passwords. 
   
4. Integration with Existing Identity Systems: Google Cloud Identity can be integrated with existing identity management systems, such as Microsoft Active Directory or Entra ID. This allows organizations to extend their current identity and access management (IAM) policies to Google Cloud resources without needing to manage separate IAM systems. As many companies already use Office 365 and its user management, this is a crucial factor.
   
5. Access and Identity Governance: It offers tools for identity governance, allowing organizations to enforce policies regarding who can access what resources under what conditions. This includes setting up conditional access policies based on user attributes, device status, location, and more. Note that some of those features come in the free Cloud Identiy Edition, but some features are only within the paid edition.
   
6. Enhanced Compliance and Reporting: It helps organizations comply with regulatory requirements by providing detailed access and activity logs. These logs can be used for auditing purposes to ensure that access policies are being followed and to investigate security incidents.

In essence, while the features of Google Cloud Identity in its paid edition are certainly worth paying, companies that do already have Microsoft Entra ID in place, for example because they use Microsoft Office 365 usually want to integrate Google Cloud Identity with Microsoft Entra ID. Fortunately, this can be done, but takes a little effort for the integration.

Entra ID and Google Identity Federation

Setting up such a federation involves two main processes:

1. Provisioning users and groups: Users and groups from Microsoft Entra ID are periodically synchronized to Cloud Identity or Google Workspace. This ensures that new users in Microsoft Entra ID are also available in Google Cloud for access management, including before their first login. It also ensures that deletions in Microsoft Entra ID are propagated to Google Cloud. This provisioning is unidirectional; changes in Microsoft Entra ID are mirrored in Google Cloud but not the other way around, and passwords are not included in the synchronization.
   
2. Single sign-on (SSO): For authentication, Google Cloud uses the Security Assertion Markup Language (SAML) protocol to delegate authentication to Microsoft Entra ID. Depending on the configuration, Microsoft Entra ID can authenticate directly, use pass-through authentication or password hash synchronization, or delegate to an on-premises AD FS server. This setup avoids the need for password synchronization and ensures enforcement of any configured security policies or multi-factor authentication (MFA) mechanisms in Microsoft Entra ID or AD FS.

The following picture depicts this integration:

One important thing to consider is the use of DNS – which plays an important role both for Entra ID and Cloud Identity. In detail, customers have to consider how to share DNS names between Entra ID and Cloud Identity. 

Basically, Cloud Identity uses email addresses for identifying users, which guarantees that Google can send notifications to those users. This email address is stable and needs to be mapped to an user attribute in Entra ID. This can be the UPN or the email address itself.

When implementing the federation between these two systems, the following steps have to be done:

1. Users for the automatic account provisioning must be set up and configured accordingly.
   
2. Within Entra ID, there is an Enterprise Application for Google (Google Cloud/G Suite Connector by Microsoft), which must be configured. This involves at least the configuration of user provisioning and optionally the group provisioning. After the configuration, users and groups are synchronized with Cloud Identity.
   
3. Single Sign-on must be set up. Once again, there is an Enterprise Application: Google Cloud/G Suite Connector by Microsoft.
   
4. Last but not least, SSO needs to be configured in Cloud Identity.

Once everything is configured, users will be able to log in to the Google Cloud with their Entra ID credentials.

Active Directory Federation with Google Identity

In other scenarios, customers might not have Entra ID, but use Active Directory and want to use those credentials for Cloud Identity. The basic steps remain the same:

• Users and groups should be provisioned to Cloud Identity
• SSO should be configured.

To set up federation for user identity management, two main tools can be used:

1. Google Cloud Directory Sync: This is a free tool from Google that facilitates the synchronization process between your existing identity management system and Google Cloud. It operates over Secure Sockets Layer (SSL) for security and is typically deployed within your current computing infrastructure.

2. Active Directory Federation Services (AD FS): Offered by Microsoft as a component of Windows Server, AD FS allows the use of Active Directory to achieve federated authentication. 

The configuration depends on the customer’s Active Directory. Many companies will have a single forest and a single domain in AD, but larger enterprises might have multiple fores. The following graphic depicts a simple scenario:

When an Active Directory forest comprises only one domain, it’s possible to link the entire forest to a singular Cloud Identity or Google Workspace account. This setup forms a unified Google Cloud organization through which all Google Cloud resources can be managed. In such a single-domain scenario, both domain controllers and global catalog servers grant access to the entirety of objects managed within Active Directory. Typically, managing this setup involves running a single instance of Google Cloud Directory Sync to synchronize user accounts and groups to Google Cloud, alongside maintaining a single AD FS instance or fleet for single sign-on functionality.

As this blog series focus on Landing Zone, we will not go into more details here and continue with resource hierarchies in the next blog post.

Welcome to our new blog post series about Landing Zones in Google. In this and the next blog posts, we will explain what is a landing zone, why you need it, describe the components of a landing zone and explain how to setup a landing zone.

What is a Landing Zone

A landing zone, as outlined by Google’s best practices, is a foundational element in constructing an organization’s Google Cloud Platform (GCP) infrastructure. It utilizes an Infrastructure-as-Code (IaC) approach to set up a GCP organization and manage the deployment of resources for various tenants. A tenant, in this context, refers to an independent entity—typically a team responsible for one or more applications—that consumes platform resources.

The rationale behind implementing a landing zone is to streamline and standardize the setup of an organization’s cloud environment. By following established best practices, a landing zone helps prevent the duplication of efforts among tenants, ensures the use of shared components, and enforces adherence to agreed-upon policies. All environment setups are done through approved IaC methods.

Why do we need a Landing Zone

The benefits of deploying a Landing Zone include:

A landing zone for the cloud is essential for several key reasons, especially for organizations looking to deploy and manage their cloud environments effectively and securely. Here are the primary reasons why a landing zone is needed:

1. Standardization: A landing zone provides a standardized approach to setting up and configuring cloud environments. This ensures that all deployments follow the same best practices, configurations, and security standards, leading to consistency across the organization’s cloud infrastructure. This also helps in reducing unnecessary complexity: Solutions are designed following a predefined methodology.

2. Security and Compliance: By establishing a set of security baselines and policies from the outset, a landing zone helps ensure that all cloud resources comply with the organization’s security requirements and regulatory standards. This preemptive approach to security greatly reduces the risk of vulnerabilities and breaches. As such, strengthening security posture is achieved by a common framework for security, access control, and patch management for improving security and compliance.

3. Efficiency and Scalability: With a landing zone, organizations can automate the provisioning of cloud resources, making it easier to scale up or down based on demand. This automation not only speeds up the deployment process but also reduces the likelihood of human error, contributing to a more reliable and efficient cloud environment.

4. Cost Management: Landing zones can help organizations avoid unnecessary costs by ensuring that resources are efficiently allocated and used. Through governance and standardized tagging, it becomes easier to track and manage cloud spending across different departments or projects.

5. Simplified Governance: A landing zone provides a framework for governance, allowing organizations to enforce policies, monitor compliance, and manage access control effectively. This simplifies the governance of cloud resources and helps maintain order as the cloud environment grows. For example, this helps inavoiding unmanaged project sprawl, which s achieved by deploying projects within a standard structure, using consistent naming conventions, and a uniform approach to labeling resources.

6. Faster Time to Market: By streamlining the setup process and enabling automation, landing zones reduce the time it takes to deploy new applications or services. This faster deployment capability can provide a competitive advantage by allowing organizations to bring solutions to market more quickly.

7. Resource Isolation: Landing zones can be designed to isolate resources between different environments (e.g., development, testing, production) or between different projects or tenants. This isolation enhances security and operational efficiency by preventing unintended interactions between resources.

8. Improving reliability: The use of automation, immutable infrastructure, and standardized monitoring, logging, and alerting mechanisms enhance system reliability.

9. Delegating resource management: Tenants are empowered to create and manage their resources within the landing zone framework, ensuring flexibility within a controlled environment.

In summary, landing zones are foundational to building a secure, efficient, and scalable cloud environment. They enable organizations to deploy cloud resources in a controlled, automated, and consistent manner, paving the way for innovation and growth while minimizing risks and costs.

What do you get?

After talking about the benefits of a Landing Zone, let’s talk about what you get with a Landing Zone. 

1. Standardization and Efficiency: Landing Zones provide a repeatable, consistent approach for deploying cloud services using a standardized set of tools and Infrastructure-as-Code (IaC). This methodology prevents unnecessary duplication of effort and limits the proliferation of disparate products by employing curated and endorsed design blueprints as IaC.

2. IaC Capabilities:

A Landing Zone should be build by means of IaC. In order to have a repeatable set of components, the following elements can be provided:

Tenant Factory: Enables the creation of a top-level folder for a tenant along with an associated service account. In terms of Google, this is about configuring the Google organization.

Project Factory: Allows tenants to create their own projects using their service accounts, ensuring that resources are deployed exclusively via IaC and service accounts, except in sandbox projects where experimentation is allowed. With such a Project Factory, workload can later easily be onboarded with the Google Cloud.

CI/CD Toolchain: Facilitates automation and consistent deployment practices. We recommend using GitLab and GitLab CI, as already comes with support for Terraform.

3. Enforcement of Infrastructure Automation: To maintain consistency and agility, the use of infrastructure automation is enforced, preventing configuration drift and aligning with principles of automation and immutable infrastructure. This ensures that outcomes are predictable and that manual console-based configurations, which undermine consistency, are avoided. This involves not only using Terraform, but also have the “right DevOps workflows”, so that automation is done right.

4. Organizational Hierarchy and Policies:

Supports the creation of multiple isolated tenants within a platform, each with the autonomy to manage their own resources within defined boundaries.

Enforces a set of organization-wide policies aligned with best practices for security, such as preventing the creation of default networks, external IP addresses on compute instances, and mandating the use of OS Login for SSH access.

5. Predefined Network Topology:

Options for network topology include a shared VPC model or a hub-and-spoke pattern, promoting efficient resource allocation and connectivity among tenants while maintaining security through centralized control mechanisms like ingress and egress patterns. 

Like other hyperscalers, Google already provides architectural guidelines and sample architectures for  Landing Zones. For example, in the following, we can see a design from Google.

We at Soeldner Consult have a strategic partnership with CloudGems, for building Landing Zones in a very short time. Cloud Gems have their own design for a Landing Zone, which is very flexible and can be used in regulated environments as well as in traditional industries.