True or false: Google manages every aspect of Google Cloud Platform customers security

At our data centers, we take security very seriously. We keep your data safe and secure by using dozens of critical security features.

We've designed our data centers with security in mind.

Security is part of our data centers' DNA. We custom-build servers exclusively for our data centers, never selling or distributing them externally. And our industry-leading security team works 24/7 around the globe making our facilities one of the safest places for your data to live.

We also have robust business continuity and disaster recovery measures in place. For example, in the event of a fire or any other disruption, we shift data access automatically and seamlessly to another data center so that our users can keep working, uninterrupted. Our emergency backup generators continue to power our data centers even in the event of a power failure. Our ongoing commitment to business continuity is demonstrated through our data centers being ISO 22301:2019 certified. Find the Google Data Centers ISO 22301:2019 certificate here.

We safeguard your data.

Rather than storing each user's data on a single machine or set of machines, we distribute all data — including our own — across many computers in different locations. We then chunk and replicate the data over multiple systems to avoid a single point of failure. We name these data chunks randomly, as an extra measure of security, making them unreadable to the human eye.

While you work, our servers automatically back up your critical data. So when accidents happen — if your computer crashes or gets stolen — you can be up and running again in seconds.

Lastly, we rigorously track the location and status of each hard drive in our data centers. We destroy hard drives that have reached the end of their lives in a thorough, multi-step process to prevent access to the data.

Our security team is on duty 24/7.

Our data centers are protected with several layers of security to prevent any unauthorized access to your data. We use secure perimeter defense systems, comprehensive camera coverage, biometric authentication, and a 24/7 guard staff. In addition, we enforce a strict access and security policy at our data centers and ensure all staff is trained to be security minded.

We also have local and regional security operations centers covering the entire data center fleet. These SOCs monitor and respond to alarms at all of our facilities, and are constantly tracking local and global events that could impact operations at our data centers. The security teams also run year-round testing to ensure that we’re always prepared to respond to any situation. And along with routine testing, the teams run a robust enterprise risk management program to proactively assess and mitigate any risks to the data centers.

Learn more about Google Cloud security and compliance.

Week 1 notes — Introduction to Google Cloud

Key Concepts in week two:

• Identify the purpose of projects, folders, and organization nodes on Google Cloud Platform
• Describe the purpose of and use cases for Identity and Access Management
• List the methods of interacting with Google Cloud Platform

Introduction

When you run workloads in GCP, you use projects to organize them. You use Google Cloud Identity, and Access Management also called IM, or IAM to control who can do what. You also use your choice of several interfaces to connect. We will learn these basics this week.

Projects are the main way to organize the resources in GCP. You can use them to group together related resources, normally ones that have a common business objective.

Principle of least privilege
Each user should have only those privileges needed to do their hobs. In a least-privilege environment, people are protected from an entire class of errors. The principle of least privilege is very important when managing any kind of compute infrastructure (on the cloud or on-premises).

There are four ways to interact with GCPs management layer

• though a web-based console
• through the SDK and its command-line tools
• though the API’s
• though mobile app

When you build an application on your on-premises infrastructure, you’re responsible for the entire stack security. This would include the physical security of the hardware, the premises in which they’re housed, the encryption of the data on disk, the integrity of your network, even securing the content stored in those applications.

GCP will handle the many lower layers of security, but the upper stacks remain the customer's responsibility. Google does, however, provide tools like IAM to help customer implement the policies they choose

The GCP Resource Hierarchy

We are going to start from the bottom up. All the resources you use, whether they’re virtual machines, cloud storage buckets, tables, and big query or anything else in GCP are organized into projects. Projects can be organized into folders. Folders can contain other folders. All folders and projects used by our org can be brought together under an organization node. Projects, folders, and organization nodes are all places where the polices can be defined. Some GCP recesses let you put policies on individual resources too, like Cloud Storage buckets. Policies are inherited downwards in the hierarchy.

All Google Cloud platform resources belong to a project. Projects are the basis for enabling and using GCP services — like managing APIs, enabling billing, adding, and removing collaborators, enabling other GCP services. Each project is a separate compartment and each resource belongs to exactly one.

Projects can have different owners and users — they are built separately and managed separately. Each GCP project has a name and project ID that you will assign. The project Id is permanent, it’s unchangeable, and a unique identifier across all of GCP. You use project Ids in many contexts to tell GCP which project you want to work with. GCP will also assign each of your projects a unique project number that you will see displayed in different contexts. In general, project Ids are made to be readable by humans and referred to in projects.

You can organize projects into folders (not required). An example would be organizing folders to represent departments, teams, applications, or environments in your org. Folders let teams easily delegate administrative rights so they can each work independently. Resources in a folder will inherit IAM policies from the parent folder.

In the example above, you can put your IAM policies into folder B if both project_3 and project_4 are administered by the same team. This helps reduce errors and tedious work.

Organization Nodes

To use folders, you need an organization node at the top of the hierarchy. This is a place that can have central visibility on how resources are being used and policies being applied centrally. You could designate an organization policy admin so that only people with privilege can change policies. You could also assign a project creator role — a great way to control who can spend money.

Once you have an organization node, you can create folders under it and create projects. Below is an example of inheritance from an organization node. One thing to keep in mind: policies implemented at a higher level in this hierarchy can’t take away access that’s granted at a lower level.

Review — The Google Cloud Platform resource hierarchy

Choose the correct completion: Services and APIs are enabled on a per-__________ basis.
Project

True or false: Google manages every aspect of Google Cloud Platform customers’ security.
False

Your company has two GCP projects, and you want them to share policies. What is the less error-prone way to set this up?
Place both projects into a folder, define policies on the folder

Identity and Access Management (IAM)

IAM lets admins authorize who can take action on specific resources. An IAM policy has a “who”, and “can do what”, and an “on which resource”.

• “who?” — can be defined either by a Google account, a Google group, a Service account, an entire G Suite, or a Cloud Identity domain.
• “can do what” is defined by the IAM role (a collection of permissions)

most of the time, to do any meaningful operations, you will need more than one permission. An example is managing instances in a project — you will need to create, delete, start, stop, and change an instance. So permissions are grouped together into a role to make them easier to manage.

There are three kinds of roles in IAM:

These roles are broad, you can apply them to a GCP project and they affect all resources in that project. These are the owner, editor, and viewer roles.

• owner — do everything an editor can do plus manage permissions and roles on the resource (also lets you set up billing)
• editor — do everything a viewer can plus change state
• viewer — examine but not change state

IAM roles

Compute engines InstanceAdmin Role lets whoever has that role perform a certain set of actions on virtual machines

These actions are:

• listing them
• reading and changing configurations
• starting and stopping

On which virtual machines you may ask? That all depends on where the roles are applied. The example below shows that these are all defined on project_a

If even finer-grained roles are needed, there are custom roles. You may be familiar with a least-privileged model in which each person in your organization has the minimum amount of privilege needed to do his or her job. One example could be — maybe I want to define an InstanceOperator Role to allow some users to start and stop Compute Engine and virtual machines, but not reconfigure them. Custom roles allow us to do that.

Custom roles can only be used at the project or org levels, not folder levels.

There is also the option the give access to say, a Compute Engine virtual machine, instead of a person. This is when you would use a service account. 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 InstanceAdmin Role. This would allow an application running in a VM with that service account to create, modify, and delete other VMs.

Service accounts need to be managed too. In addition to being an identity, service accounts are also resources. So it can have it's own IAM policies.

Quiz — Resources and IAM

When would you choose to have an organization node?
When you want to create folders. Folders require an organization node. Organization nodes are optional, but if you want to create folders, having one is mandatory.

When you want to apply organization-wide policies centrally. Organization nodes let you apply policies centrally. Organization nodes are optional, but if you want to define policies that apply to all the projects in your organization, having one is mandatory.

Order these IAM role types from broadest to finest-grained.
Primitive roles, predefined roles, custom roles

Can IAM policies that are implemented higher in the resource hierarchy take away access that is granted by lower-level policies?
No. Policies implemented at a higher level in the hierarchy can’t take away access that’s granted at lower level. For example, suppose that a policy applied on a project gives user Jane the right to modify a Cloud Storage bucket. But a policy at the organization level says that she can only view Cloud Storage buckets, not change them. The more generous policy is the one that takes effect. Jane can modify the bucket.

Compared to AWS IAM

These bad boys kinda do the same thing. It’s all just a mechanism to secure user authentication and permission for the cloud. Here is a chart briefly showing the differences

Interacting with GCP

There are four ways to interact with GCP: the Console, the SDK & Cloud Shell, the Mobile App, and the APIs.

GCP Console

A web-based administrative interface. It lets you view and manage all projects and all the resources they use. GCP Console also lets you enable, disable, and explore the APIs of the GCP services.

Cloud Shell

A command-line interface to GCP that’s easily accessed from your browser. From Cloud Shell, you can use the tools provided by the Google Cloud Software Development kit SDK without having to install them somewhere first. SDK is a set of tools that you can use to manage your resources and your applications on GCP. These include the gcloud tool, which provides the main command-line interface for GCP products and services. There’s also gsutil which is for Google Cloud Storage and bq which is for BigQuery. The easiest way to get the SDK commands is to click the Cloud Shell button on the GCP console. You then get a command line in your web browser on a virtual machine with all these commands already installed. You can also install the SDK on your computer and is available as a docker image.

Mobile

There’s a mobile App for Android and iOS that lets you examine and manage the resources you’re using in GCP. It lets you build dashboards so that you can get the information you need at a glance.

REST-based API

Your code can use Google services in much the same way that web browsers talk to web servers. REST. The APIs name resources and GCP with URLs. Your code can pass information to the APIs using JSON. There is an open system for user login and access control. The GCP Console also lets you turn on and off APIs. Many APIs are off by default, and many are associated with quotas and limits. These restrictions can help protect you from using resources inadvertently. You can enable only those APIs you need and you can request increases in quotas when you need more resources.

API Explorer

The GCP Console includes a tool called the APIs Explorer that helps you learn about the APIs interactively. It lets you see what APIs are available and in what versions. These APIs expect parameters and documentation on them is built-in. You can try the APIs interactively even with user authentication. Google provides client libraries that take a lot of the work out of the task of calling GCP from your code.

There are two kinds of libraries. The Cloud Client Libraries are Google clouds latest and recommended libraries for its APIs. They adopt the native styles and idioms of each language. On the other hand, sometimes a Cloud Client Library doesn’t support the newest services and features. In that case, you can use the Google API Client Library for your desired languages. These libraries are designed for generality and completeness.

Cloud marketplace

Cloud marketplace is for staring up with GCP with little to no effort. Quickly deploying software packages on GCP. pre-packaged, ready-to-deploy solutions.

There’s no need to manually configure software, virtual machine instances, storage, or network settings. Although you can modify many of them before you launch if you like.

Quiz — Getting Started with Google Cloud Platform

True or False: In Google Cloud IAM: if a policy applied at the project level gives you Owner permissions, your access to an individual resource in that project might be restricted to View permission if someone applies a more restrictive policy directly to that
False. Policies are a union of those applied on the resource itself and those inherited from higher levels in the hierarchy. If a parent policy is**less**restrictive, it overrides a more restrictive policy applied on the resource. If a parent policy is**more**restrictive, it does not override a less restrictive policy applied on the resource. Therefore, access granted at a higher level in the hierarchy cannot be taken away by policies applied at a lower level in the hierarchy.

True or False: All Google Cloud Platform resources are associated with a project.
True. All Google Cloud Platform resources are associated with a project.

Service accounts are used to provide which of the following? (Choose all that are correct. Choose 3 responses.)
A way to allow users to act with service account permissions, authentication between google cloud platform services, a way to restrict the actions resources can perform

How do GCP customers and Google Cloud Platform divide responsibility for security?
Google takes care of the lower parts of the stack, and customers are responsible for the higher parts

Which of these values is globally unique, permanent, and unchangeable, but chosen by the customer?
The project ID

Consider a single hierarchy of GCP resources. Which of these situations is possible? (Choose all that are correct. Choose 3 responses.) note: these are the three correct answers
There is an organization node, and there are no folders. There is an organization node, and there is at least one folder. There is no organization node and no folders

What is the difference between IAM primitive roles and IAM predefined roles?
Primitive roles affect all resources in a GCP project. Predefined roles apply to a particular service in a project.

Which statement is true about billing for solutions deployed using Cloud Marketplace (formerly known as Cloud Launcher)?
You pay only for the underlying GCP resources you use, with the possible addition of extra fees for commercially licensed software.

Is Google a cloud platform?

Why might a Google Cloud customer use resources in several zones?

Why might a Google Cloud customer use resources in several zones within a region Mcq?

Why is Google Cloud Platform?