Set Up foundation for Google

cloud console for enterprise

solution.
------------------------------------------------------------------------------------------
 In this We will learn how to set up and deploy layout of our Google Cloud resources. You'll need an
organization resource to complete this.

To use Google Cloud, you must use a Google identity service (either Cloud Identity or Workspace ) to administer
credentials for users of your Google Cloud resources. Both Cloud Identity and Workspace provide authentication
credentials allowing others to access your cloud resources.

Google Workspace : Sign up for Google Workspace.

 Cloud Identity : Sign up for Cloud Identity.
This model for access management has three main parts:

•Principal. A principal can be a Google Account (for end users), a service account (for applications and compute
workloads), a Google group, or a Google Workspace account or Cloud Identity domain that can access a resource.
Each principal has its own identifier, which is typically an email address.

•Role. A role is a collection of permissions. Permissions determine what operations are allowed on a resource.
When you grant a role to a principal, you grant all the permissions that the role contains.

There are three types of roles in IAM:

•Basic roles, which include the Owner, Editor, and Viewer roles that existed prior to the introduction of IAM.

•Predefined roles, which provide granular access for a specific service and are managed by Google Cloud.

•Custom roles, which provide granular access according to a user-specified list of permissions.

•Policy. The allow policy is a collection of role bindings that bind one or more principals to individual roles. When
you want to define who (principal) has what type of access (role) on a resource, you create an allow policy and
attach it to the resource.
Concepts Related to Identity :

In IAM, you grant access to principals. Principals can be of the following types:

•Google Account :A Google Account represents a developer, an administrator, or any other person who interacts
with Google Cloud. Any email address that's associated with a Google Account can be an identity, including
gmail.com or other domains.

•Service account : A service account is an account for an application or compute workload instead of an
individual end user.

•Google group : A Google group is a named collection of Google Accounts and service accounts. Every Google
group has a unique email address that's associated with the group.

•Google Workspace account: These account are associated with organization domain such as example.com

•Cloud Identity domain : A Cloud Identity domain is like a Google Workspace account, because it represents a
virtual group of all Google Accounts in an organization.

•All users : is a special identifier that represents anyone who is on the internet, including authenticated and
unauthenticated users.
Below picture represent the first step to set up Identity management service with
organization domain.
If we haven’t created any identity account then we can select as first option that : “ I
am a new customer. And can create account for cloud Identity.
If we have already a Identity account then we can select second option as : selected in
below Picture :
And If have already setup for workspace account then can select as :
Follow the instruction as mention.
After completion first step for Identity account this will look like as below :
Continue to step 2:
As a best practice Google recommended for creation and separation of administrative
groups listed in below. However this is dependent on organization requirement. We can
create single group or can create all group using “CREATE ALL GROUPS” button.
I have created all groups as per Google recommendation :
We can change name also but best practices is use to naming convention as per Google
recommendation.
After completion of step 2 move to continue :
As per requirement if we need to add user in previously created group then we can go to admin console by
clicking on “GO TO THE GOOGLE ADMIN CONSOLE”, All the created group will be reflected in admin
console.
Or we can skip this part or can add user later by clicking on “CONTINUE” button.
If we need to add user at this time then Sign in to Google Workspace Admin Console using a super admin
account.
Add users with one of the following options:
1:Add several user at once.
2. Add user individually.
ALL THE CREATED GROUP WILL BE REFLECTED IN ADMIN CONSOLE.
The groups below are common in enterprise organizations that have multiple departments administering
its cloud infrastructure. If your setup requires a different group structure, feel free to customize our
recommendations to your needs. Below are the groups and their function which we have created as per
recommendation:
We can add member here to the group :
As continue to next step :
In this step, you grant administrative access to the gcp-organization-
admins@advikcloud.club group by assigning the following roles at the organization
level. The steps for how to perform this procedure follow at the end of this task.
By using Grant access we can provide access at organization level to the group:
Copy the group name and paste to new principals and as mentioned role we can add or delete
as per our requirements.
After granting access for these roles lets continue for further :
As step by step I have granted access for these roles to their particular principals: Lets finish
the task after clicking at “MARK TASK AS COMPLETED”.
Lets set up for billing account :
Go with option as per choice :
Billing account has been added now :
 Resource Hierarchy : A resource hierarchy helps to organize your resources
in Google Cloud.

 In this task, you create a basic structure for folders and projects in your resource hierarchy.
 Folders provide a grouping mechanism and isolation boundaries between projects. For example, they can
represent the main departments in your organization such as finance or retail, or environments such as
production versus non-production.
 Projects contain your cloud resources, such as virtual machines, databases, and storage buckets. For design
considerations and best practices to organize your resources in projects.
 The resource hierarchy in Google Cloud starts at the root node, which is called the organization. We
recommend that businesses have only one root node, except for in specific situations. You define lower levels
of the hierarchy using folders and projects, and you create folders within folders to build your hierarchy.
You can create the projects that host your workloads at any level of the hierarchy.
The following diagram shows a hierarchy for example.com, which is a fictitious financial technology
company.
Select a starting configuration to view more details. Continue to modify it to fit your organization's
needs : First View for simple team-orientated hierarchy.
Simple environment orientated hierarchy :
Business unit-orientated hierarchy
Environment-orientated hierarchy :
We can change the name of folder and as for project
also :
We can change folder name and project name and ID also, But project ID we can change later also.
We can add custom project as also :
In this step, you assign access to various groups within your organization to the folders and
projects that you just set up. At Google this process is called setting Cloud IAM policies
We can edit these assigned roles and policies as per requirement, There edit option
available.
Lets continue to Next step as networking :
Decide the network design for your Google Cloud landing zone
When you design your landing zone, you must choose a network design that works for your organization.

Choose network design : The following flowchart shows the decisions that you must make to choose the
best network design for your organization.

The preceding diagram guides you through the following questions:

Do you require Layer 7 inspection using network appliances between different workloads in Google Cloud?
If yes, see Hub-and-spoke topology with centralized appliances.
If no, proceed to the next question.
Do many of your workloads require on-premises connectivity?
If yes, go to decision point 4.
If no, proceed to the next question.
Can your workloads communicate using private endpoints in a service producer and consumer model?
If yes, see Expose services in a consumer-producer model with Private Service Connect.
If no, proceed to the next question.
Do you want to administer firewalling and routing centrally?
If yes, see Shared VPC network for each environment.
If no, see Hub-and-spoke topology without appliances.
This chart is intended to help you make a decision, however, it can often be the case that multiple designs might be suitable for
your organization. In these instances, we recommend that you choose the design that fits best with your use case.
Network Design Option :

1. Shared VPC network for each environment :

We recommend this network design for most use cases. This design uses separate Shared
VPC networks for each deployment environment that you have in Google Cloud
(development, testing, and production). This design lets you centrally manage network
resources in a common network and provides network isolation between the different
environments.
Use this design when the following is true:

•You want central control over firewalling and routing rules.

•You need a simple, scalable infrastructure.
•You need centralized IP address space management.
Avoid this design when the following is true:
•You want developer teams to have full autonomy, including the ability to manage their own firewall rules,
routing, and peering to other team networks.
•You need Layer 7 inspection using NGFW appliances.
The following diagram shows an example implementation of this design.
Lets start for Network design :
 Setup process for shared VPC for
development & other enviournment.
Subnet:- Creating your own sub-network in a network.
Here we have need to create two subnets in different regions to be in line with Google cloud architecture . Which
provides high availability and disaster-recovery workload configurations.

Firewall Rules:- Lets you allow or deny connections to or from virtual machines. Firewall rules defined at
network level, but connections are allowed or denied on a per-instance basis. Here recommended configuration of
rules are shown in attached screenshots.

Cloud NAT:- You should only configure Cloud NAT for the subnet IP ranges that require outbound Internet
access. This configuration approach provides an additional layer of control that assists with managing external
access for your workloads.
Draft VPC network Architecture
VPC Network configured
 Centralised Logging

 Centralised Logging:- This task helps you get a more centralized view of logging for all
your projects. You centrally organise logs across your organization to help with your
security, auditing and compliance needs. To help people more easily audit and
troubleshoot activity for a specific project, Google automatically collects and stores logs
within each project where the activity occurred.
 Audit logs and log administrative activity and access within your Google Cloud resources.
 Admin activity audit logs log entries for API calls or other actions that modify the
resource configuration or metadata. 
 System event audit logs log entries for actions taken by Google Cloud systems that
modify the configuration of resources. 
Centralising logs across projects

 Centralising logs across projects:- To easily search and analyse logs across all projects, we
recommend routing all logs to a central Cloud Logging log bucket, a basic container that holds your
logging data. This log bucket is stored in the central logging project that you or your organization's
administrator created in step 5: Resource hierarchy and access.
 Cloud Logging retains the logs in this bucket for 400 days; you can't change this retention period
 Types of logs that we include as under
 The following logs are included by default. If desired, you can change the inclusion filter after
deployment.
 Cloud Audit Logs: Admin activity
 Cloud Audit Logs: System event
 Cloud Audit Logs: Access Transparency
Admin Activity audit logs

 Admin Activity audit logs

 Admin Activity audit logs contain log entries for API calls or other actions that modify the
configuration or metadata of resources. For example, these logs record when users create
VM instances or change Identity and Access Management permissions.
 Admin Activity audit logs are always written; you can't configure, exclude, or disable
them. Even if you disable the Cloud Logging API, Admin Activity audit logs are still
generated.
System Event audit logs

 System Event audit logs

 System Event audit logs contain log entries for Google Cloud actions that modify the
configuration of resources. System Event audit logs are generated by Google systems;
they aren't driven by direct user action.
 System Event audit logs are always written; you can't configure, exclude, or disable them.
Access Transparency audit logs

 Access Transparency is a part of Google's long-term commitment to transparency and

user trust. Access Transparency logs record the actions that Google personnel take when
accessing customer content.
 Access Transparency logs give you different information than Cloud Audit Logs. Cloud
Audit Logs record the actions that members of your Google Cloud organization have
taken in your Google Cloud resources, whereas Access Transparency logs record the
actions taken by Google personnel.
 Access Transparency log entries include details such as the affected resource and action,
the time of the action, the reason for the action, and information about the accessor.
Data Access audit logs

 Data Access audit logs

 Data Access audit logs contain API calls that read the configuration or metadata of resources, as well
as user-driven API calls that create, modify, or read user-provided resource data.
 Publicly available resources that have the Identity and Access Management policies 
all Authenticated Users or allUsers don't generate audit logs. Resources that can be accessed without
logging into a Google Cloud, Google Workspace, Cloud Identity, or Drive Enterprise account don't
generate audit logs. This helps protect end-user identities and information.
 Data Access audit logs-- except for BigQuery Data Access audit logs-- are disabled by default
because audit logs can be quite large. If you want Data Access audit logs to be written for Google
Cloud services other than BigQuery, you must explicitly enable them. Enabling the logs might result
in your Cloud project being charged for the additional logs usage. For instructions on enabling and
configuring Data Access audit logs, see Configure Data Access logs.
Policy Denied audit logs

 Policy Denied audit logs

 Policy Denied audit logs are recorded when a Google Cloud service denies access to a
user or service account because of a security policy violation. The security policies are
determined by VPC Service Controls, which provides the Policy Denied audit logs to
Cloud Logging.
 Policy Denied audit logs are generated by default and your Cloud project is charged for
the logs storage. You can't disable Policy Denied audit logs, but you can use 
exclusion filters to prevent Policy Denied audit logs from being ingested and stored in
Cloud Logging.
 Who can access centralised logs:- The administrators assigned to the central logging
project will have access to these logs. In addition, a service account will route logs to the
log bucket.
 How long centralised logs are stored :-Note that storing logs longer than 30 days will
generate a cost of $.01/GiB/month in the future. The best practice for large enterprises is
365 days.
Other Destinations for audit logs

 Run analytics against logs data in BigQuery

 Store logs that are unlikely to be read (best for compliance purposes)
 Stream your logs to other applications, other repositories or third parties
Deploy or Download

 Terraform:- Terraform is an infrastructure automation tool that allows teams to treat their infrastructure as code.
Infrastructure as code provides many benefits such as improved recovery, predictability, and speed. Infrastructure
as code is quickly becoming a standard for managing cloud resources and is widely practiced among the top-
performing companies.
 Dowanload as Terraform:- Choose this option if you are familiar with Terraform and wish to deploy via existing
process You can always make change to code before deploying. You are responsible for managing the Terraform
pipeline.
 Deploy Directly:-Choose this option to start one time deployment configuration. After deploying, you can no
longer edit your configuration but you can always go directly to products pages within the console to make
changes.
 Billing account used in task4 is used to process your configuration when you deploy or download Billing must be
enabled to create necessary resource and should incur minimal fess or no fees.
 Before submission we can review resource Hierarchy, Networking, centralised logging .