Essential Cloud Infrastructure: Core Services - Summary Notes

This following illustration shows the Cloud IAM resource hierarchy:

Fig.3

GCP resources are organized as a hierarchically tree structure. The Organization node is the root node in the hierarchy. Folders are the children of the Organization. Projects are the children of the Folders, and the individual resources are the children of Projects
Each resource has exactly one parent
Cloud IAM allows one to set policies at any of the levels, namely, Organization, Folders, Projects, or resources
A Policy contains a set of Roles and role Members
Resources inherit Policies from their parent
The Organization resource represents a company. Cloud IAM roles granted at this level are inherited by all resources under the Organization
The Folder resource could represent a department. Cloud IAM roles granted at this level are inherited by all resources that the Folder contains
Projects represent a trust boundary within the company. Services within the same Project have a default level of trust
Child Policies cannot restrict access granted at the parent level
This following illustration shows the Organization node:

Fig.4

The Organization resource is the root node in the GCP resource hierarchy
The Organization node has many roles like the Organization Admin. The Organization Admin provides a user with administer access to all resources belonging to their organization
There is also a Project Creator role which allows a user to create Projects within their organization
This following illustration talks about creating and managing Organization node:

Fig.5

The Organization resource is closely associated with a G Suite or a Cloud Identity account. When a user with a G Suite or Cloud Identity account creates a GCP Project, the Organization resource is automatically provisioned for them
Each G Suite or Cloud Identity account is associated with exactly one Organization
An Organization is associated with exactly one domain, which is set when the Organization resource is created
Once the Organization resource is created, Google Cloud communicates its availability to the G Suite or Cloud Identity super administrators. These super admininstrator accounts should be used very carefully because they have a lot of control over the Organization and all the resources underneath it
The G Suite or Cloud Identity super administrator and the GCP Organization admin are key roles during the setup process and for lifecycle control for the Organization resource
The G Suite or Cloud Identity super administrator responsibilities are - assign the organization admin role to some users, be a point of contact in case of recovery issues, and control the lifecycle of the G Suite or Cloud Identity account and Organization resource
The responsibilities of the Organization admin role are - define IAM policies, determine the structure of the resource hierarchy, and delegate responsibility over critical components such as networking, billing, and resource hierarchy through IAM roles
This following illustration talks about Folders:

Fig.6

Folders can be viewed as sub organizations within the Organization
Folders provide an additional grouping mechanism and isolation boundary between Projects
Folders can be used to model different legal entities, departments, and teams within a company
For example, a first level of Folders can be used to represent the main departments in an Organization like Dept X and Dept Y (from Fig.6 above). Because Folders can contain Projects and other Folders, each Folder could then include other sub Folders to represent different teams like Team A and Team B (from Fig.6 above). Each team Folder could contain additional sub Folders to represent different applications like Product 1 and Product 2 (from Fig.6 above)
Folders allow delegation of administration rights
Access to resources can be limited by Folder
This following illustration talks about the resource manager roles:

Fig.7

The Organization node has a Viewer role that grants view access to all resources within an organization
For Folders, there is an Admin role that provides full control over Folders
For Folders, there is a Creator role to browse the hierarchy and create Folders
For Folders, there is a Viewer role to view Folders and Projects
For Projects, there is a Creator role that allows a user to create new Projects. This automatically grants that user the Owner role
For Projects, there is also a Project Deleter role that grants deletion privileges
This following illustration shows the 3 types of IAM roles:

Fig.8

Roles define the can do what on which resource part of Cloud IAM
There are three types of roles in Cloud IAM - Primitive roles, Predefined roles, and Custom roles
Primitive roles are broad. When applied to a GCP Project, they affect all resources in that Project
This following illustration shows the Primitive IAM roles:

Fig.9

IAM Primitive roles are for fixed, coarse-grained levels of access
The Owner has full administrative access. This includes the ability to add and remove members and delete Projects
The Editor role has modify and delete access. This allows a developer to deploy applications and modify it or configure its resources
The Viewer role has read only access
The Owner, Editor, and Viewer roles are concentric, meaning, the Owner role includes the permissions of the Editor role and the Editor role includes the permissions of the Viewer role
There is also a Billing Administrator role to manage billing and add or remove administrators without the right to change the resources in the Project
Each Project can have multiple owners, editors, viewers, and billing administrators
This following illustration shows the Predefined IAM roles:

Fig.10

Each of the GCP services offer their own set of Predefined roles and they define where those roles can be applied. This provides members with granular access to specific GCP resources and prevents unwanted access to other resources. These roles are collections of permissions because to do any meaningful operations, one usually needs more than one permission
For example, a group of users are granted the InstanceAdmin role on Project A (from Fig.10 above). This provides the users of that group with all the Compute Engine permissions listed on the right (from Fig.10 above) and more
The permissions themselves are classes and methods in the APIs
For example, compute.instances.start can be broken down into the service, resource, and verb. That means that this permission is used to start and stop Compute Engine instance
This following illustration shows some of Compute Engine IAM roles:

Fig.11

Compute Engine has several predefined IAM roles
The Compute Admin role provides full control of all Compute Engine resources. This includes all permissions that start with Compute which means that every action for any type of Compute Engine resource is permitted
The Network Admin role contains permissions to create, modify, and delete networking resources except for firewall rules and SSL certificates. In other words, the Network Admin role allows read-only access to firewall rules, SSL certificates, and instances to view their ephemeral IP addresses
The Storage Admin role contains permissions to create, modify, and delete disks, images and snapshots
This following illustration talks about Custom IAM roles:

Fig.12

Custom Roles permit allow one to define finer-grained permission
For example, a user wants to define an Instance Operator role to allow some users to start and stop Compute Engine VMs, but not reconfigure them. Custom Roles allow them to do that
Custom roles are not maintained by Google. That means when new permissions, features or services are added to GCP, the Custom roles will not be updated automatically
This following illustration talks about Members:

Fig.13

Members define the who can do what part on a resource
There are 5 different types of members - Google Accounts, Service Accounts , Google Groups, G Suite Domains, and Cloud Identity Domains
A Google Account represents a developer, an administrator or any other person who interacts with GCP. Any email address that is associated with a Google Account can be an identity, including gmail.com or other domains. New users can sign up for a Google Account, by going to the Google Account sign-up page, without receiving mail through Gmail
A Service Account is an account that belongs to a user application, instead of to an individual end user. When the user runs code that is hosted on GCP, the user can specify the account that the code should run as. The user can create as many Service Accounts as needed to represent the different logical components of their application
A Google Group is a named collection of Google Accounts and Service Accounts. Every group has a unique email address that is associated with that group. Google Groups are a convenient way to apply an access policy to a collection of users. One can grant and change access controls for a whole group at once, instead of granting or changing access controls one at a time, for individual users or Service Accounts
G Suite Domains represent an organization's Internet domain name such as example.com. When a user is added to a G Suite Domain, a new Google Account is created for the user inside this virtual group such as username@example.com
GCP customers who are not G Suite customers can get the same capabilities through Cloud Identity. Cloud Identity lets one manage users in groups using the Google Admin Console
To create and manage users and groups, one needs either Cloud Identity or G Suite
This following illustration shows the case of organizations having their own corporate directory:

Fig.14

For enterprises that use corporate directory such as Active Directory, one can use Google Cloud Directory Sync to synchronize users and groups to their Cloud Identity Domain
With Google Cloud Directory Sync, an organization's administrator can log in and manage GCP resources using the same usernames and passwords they already use in their corporate directory
Google Cloud Directory Sync tool synchronizes users and groups from a user's existing Active Directory or LDAP system with the users and groups in their Cloud Identity Domain. The synchronization is one way only, which means that no information in their Active Directory or LDAP map is modified. Google Cloud Directory Sync, is designed to run scheduled synchronizations without supervision, after its synchronization, rules are set up
This following illustration talks about Single Sign-On (SSO):

Fig.15

GCP also supports Single Sign-On (SSO) authentication. If an organization has their identity system, they can continue using their own system. When a user authentication is required, Google will redirect to their system. If the user is authenticated in their system, access to GCP is given. Otherwise, the user is prompted to sign in. This allows one to also revoke access to GCP
A SAML2 SSO requires 3 links and a certificate to configure SSO (from Fig.15 above)

This following illustration talks about using Service accounts for server to server interactions:

Fig.16

A Service Account is an account that belongs to an application instead of to an individual end user. This provides an identity for carrying out server-to-server interactions in a Project without supplying user credentials
This following illustration talks about using Service accounts being identified by an email address:

Fig.17

Service accounts are identified by an Email address
There are 3 types of Service accounts - User-created (or custom), Built-in , and Google API service accounts
By default, all Projects come with the built-in Compute Engine default service account
Apart from the default service account, all Projects come with the GCP API service account, identifiable by the email which has the format: project-number@cloudservices.gserviceaccount.com
The GCP API service account is the service account designed specifically to run internal Google processes on the user's behalf and it is automatically granted the Editor role on their Project
One can start an instance with a Custom service account. Custom service accounts provide more flexibility than the default service account, but are required to be managed by the user
One can create as many Custom service accounts as needed, assign any arbitrary Cloud IAM roles to them, and assign the service accounts to any Virtual Machine instance
This following illustration talks about the Default Compute Engine Service account:

Fig.18

The default Compute Engine service account is automatically created per project and is identifiable by an email fo the format: project-number-compute@developer.gserviceaccount.com
The default Compute Engine service account is automatically granted the Editor role on the Project
This following illustration talks about Scopes:

Fig.19

Authorization is the process of determining what permissions an authenticated identity has on a set of specified resources
Scopes are used to determine whether an authenticated identity is authorized
For example, Application A and Application B (from Fig.19 above) use authenticated identities (Service accounts). Both applications want to use a Cloud Storage bucket. They each request access from the Google Authorization Server and in return they receive an access token. Application A receives an access token with read-only scope, so it can only read from the Cloud Storage bucket. Application B in contrast receives an access token with read-write scope so it can read and modify data in the Cloud Storage bucket
This following illustration talks about customizing Scopes:

Fig.20

Scopes can be customized when an instance is created using the default Service account as shown in the Fig.20 above
Scopes can be changed after an instance is created by stopping it
Access scopes are actually the legacy method of specifying permissions for the VM
For Custom service accounts, it is recommended to use the Cloud IAM roles for specifying permissions
This following illustration talks about Service account permissions:

Fig.21

A default Service account supports both Primitive and Predefined roles, while a Custom Service account only use Predefined roles
From Fig.21 above, first a service account is created that has the InstanceAdmin role which has permissions to create, modify, and delete VM instances and disks. Then this service account is treated as the resource, and finally this service account is used to decide who can use it by providing users or a group with the ServiceAccountUser role. This allows those users to act as that service account to create, modify, and delete VM instances and disks. Therefor be cautious when granting the ServiceAccountUser role to a user or group
This following illustration shows an example of Service account permissions:

Fig.22

From Fig.22 above, the VM running component_1 are granted Editor access to Project B using Service Account 1. VM running component_2 are granted ObjectViewer access to bucket 1 using an isolated Service Account 2. This way one can scope permissions for VMs without recreating VMs
Cloud IAM lets one slice a Project into different microservices, each with access to different resources by creating Service accounts to represent each one
One can assign the Service accounts to the VMs when they are created, and don't have to ensure the credentials are being managed correctly because GCP manages security for the user
This following illustration talks about Service account authenticating with keys:

Fig.23

Service accounts authenticate using keys. There are two types of service account keys: GCP-managed keys and User-managed keys
GCP-managed keys are used by GCP services, such as App Engine and Compute Engine. These keys cannot be downloaded, and are automatically rotated and used for a maximum of 2 weeks
User-managed keys are created, downloadable, and managed by users. When the user creates a new key pair, they download the Private key, which is not retained by Google. With user-managed keys, the users are responsible for security of the private key and other management operations such as key rotation
This following illustration talks about some Cloud IAM best practices:

Fig.24

Use Projects to group resources that share the same trust boundary
Check the policy granted on each resource and recognize the inheritance
Use the principle of Least Privilege when granting roles
Audit policies using Cloud Audit logs and audit memberships of groups using policies
Grant roles to groups instead of individuals. This allows one to update group membership instead of changing a Cloud IAM policy
From Fig.24 above, there is a Network Admin group. Some of those members need a read write role to a Cloud Storage bucket, but others need the read only role. Adding and removing individuals from all three groups controls their total access
This following illustration talks about some Service account best practices:

Fig.25

Be cautious when granting the ServiceAccountsUser role because it provides access to all the resources of the Service account has access to
When creating a Service account, give it a display name that clearly identifies its purpose