Skip to content

Google Cloud for Developers (aka The Landing Zone)

landing-zone

[[TOC]]

Introduction

I want to use Google Cloud for my apps, what now? How do I integrate services to my app? I keep hearing about "The Landing Zone", what is it?

Fear not! We will guide you on your journey on exploring the Google Cloud in FTMO, giving you enough freedom, while providing guardrails to prevent you from shooting yourself in the foot.

This document will refresh basic terms and concepts introduced in RFC 6 and enhance them with practical examples.

Series of lessons will provide end-to-end guidance on how to: - Request a GCP project - Integrating Google-managed services to your apps, - Introduce Infrastructure as a Code (IaC) to your project, - Day 2 operations, such as monitoring costs, exploring logs, setting up alerts and more.

Benefits of Landing Zone for you

  • Guardrails - we give you GCP project, with many security best practices already in place. We gradually enable more services, so you can use them safely.
  • Cost transparency - your infrastructure stays in your project, and you can check how much does your app cost you.
  • Self-service - you don't have to wait for DevOps to give you access to your resources, generate accounts for you. You can do it yourself.

Landing Zone Refresher

GCP project

Every resource (topic, storage bucket, VM, SQL database) belongs to a GCP project. GCP project is a logical group of resources, usually managed by single owner of application. You can think of it as Kubernetes namespace, where resources for your application live - databases, pub/sub topics, schedulers, etc.

Each environment has its own project, so you don't mix production and development resources, just like in Kubernetes namespaces, where each environment has it's own namespace / cluster.

GCP projects has unique identifier, called project_id, which is used to reference the project in API calls, IAM policies, etc. Naming convention is defined in RFC 6 and this is something we create for you and you don't have to worry about it.

Access levels to project

We have 4 project groups that manages access to your application GCP project. You can be a member of multiple groups to merge the permissions together:

Group Access level
Browsers list-only access to resources in project
Viewers read-only access to resources in project, providing full visibility but you can't change anything
Editors read-write access to resources - you can do CRUD operations over resources in project, but you can't change access right to them
Owners manage access levels to resources, can grant access to other applications, users, etc. The group doesn't have CRUD permission over resources.

Every GCP project has their own groups. The membership in groups is managed by DevOps (for now), based on approval of owners (which are team-leads at start).

Example

Frantisek is team lead with 3 developers in his team - Jan, Peter and Magda. Peter and Magda are senior developers, participating in on-call rotation, while Jan is a new-hire, who is still learning the ropes.

Frantisek is in the Owners and Editors groups in all projects for his application. He decides who can access their resources in every environment, while he has also read-write access to all environments.

Peter and Magda are in Editors groups in all environments - they need it, as they might need to do changes in production, when things go south during on-call duty.

Jan is member of Editors group just in development environment, so that he can get hands-on experience with resources for their app. He is in the Viewers group in stage environment - he can see metrics, logs or the messages in Pub/Sub, but he can't change anything. In production, he is in the Browsers group - he sees that resources exists, but can't inspect them further, revealing production data.

Application authentication and authorization (IAM)

When you think about your application accessing Google API, you might think that you need some sort of API key for authentication. You don't need this for majority of use cases - the authentication and authorization is built into Google Cloud Platform, when the workload stays in the cloud. You don't even need it for local development - you will leverage Application Default Credentials (ADC) associated with your Google user account. We will show this in Lesson 2.

Your application runs under service account identity (authentication), which is type of principal you can reference in IAM policy that grants access to resource (authorization). As long as you use Google Cloud client libraries in your code, the flow is handled transparently for you.

IAM manages access controls by - who (service account, user, group) has what access (role) for which resource (project, bucket, pub/sub topic). By default, if binding doesn't exist, the access is denied.

Only Owners can change the IAM policies over resources - they are also limited to what sort of roles they can grant. It should be enough for you to work with supported services.

You will see the example of IAM policies in action Lesson 2.

To learn more about IAM in depth, see relevant GCP documentation.

Supported Google APIs

Table describes Google APIs supported in Landing Zone.

Google API Service Maturity level Description Official docs
Cloud Scheduler API Beta Managed scheduled jobs with cron-like syntax https://cloud.google.com/scheduler/docs/overview
Cloud Pub/Sub API Beta Managed asynchronous messaging service https://cloud.google.com/pubsub/docs/overview
OAuth2.0 Client IDs Beta Use OAuth 2.0 to authenticate to Google APIs https://developers.google.com/identity/protocols/oauth2 https://support.google.com/cloud/answer/6158849
Cloud Storage API Beta Managed object storage https://cloud.google.com/storage/docs/introduction

Maturity levels

Maturity level is our internal classification, based on how confident are we with our permission setup, if it's used by development teams, etc.

Definitions of maturity levels:

Maturity level Description
Preview Not globally enabled, tuning the permissions internally, before given to developers.
Beta Enabled in Landing Zone, tuning permissions with development teams, ready to be test out in production.
GA Enabled and used in Landing Zone by development teams in production.

Organization policies in Landing Zone

List of organization policies, enforced in Landing Zone. Might change in the future, as more services will be supported.

Organization policy ID Default value Exceptions allowed? Description
iam.allowedPolicyMemberDomains ftmo.com Yes Allows only humans with @ftmo.com email in IAM policy. Must be disabled, if public storage buckets are required in project.
iam.disableServiceAccountKeyCreation True Yes Disable creation of service account keys. In GCP, it should be enough to use short-term token. Exceptions can be made for integrating to 3rd party / on-premise infrastructure.
iam.disableServiceAccountKeyUpload True No All Service Account keys (if created) are managed by Google. We don't allow uploading our own keys.
iam.automaticIamGrantsForDefaultServiceAccounts True No Default service accounts have their permissions dropped, to support least-privilege.
compute.skipDefaultNetworkCreation True No Disables default behavior of creating network with huge private ranges.
storage.publicAccessPrevention True Yes Buckets and objects in them are not accessible to public.
storage.uniformBucketLevelAcces True No ACLs on objects in buckets are disabled. All permissions
storage.secureHttpTransport True No Only encrypted transfer is allowed to get / send data to storage
gcp.resourceLocations European Union Yes Resources can be created in European Union regions. Can be changed when needed to more regions
gcp.restrictServiceUsage supported LZ APIs No Only Landing Zone supported APIs are available to users. Trying to access different API will result in error.
cloudscheduler.allowedTargetTypes HTTP, Pub/Sub No Cloud Scheduler can trigger either HTTP endpoint or Pub/Sub topic. We disallow App Engine target.

Lessons

  1. Lesson 1: Getting GCP project for my application
  2. Lesson 2: Quickstart - reading from Pub/Sub in my k8s app
  3. Lesson 3: Getting production ready - Infrastructure as a Code

Workshops & Recordings