Google Cloud Key Management Service

 

• The Google Cloud Key Management Service (KMS) is a cloud-hosted key management service that enables you to manage encryption keys on the Google Cloud Platform.

Features

• Lets you manage your symmetric and asymmetric cryptographic keys the same way you manage them in an on-premises environment.
• You can decide to use the keys generated by Cloud KMS with other Google Cloud services. These keys are known as customer-managed encryption keys (CMEK).
• Can use external KMS to protect your data in Google Cloud and separate data from key.
• You can generate a new key version for your symmetric keys automatically at a fixed time interval when you set a rotation schedule for your keys.
• Encrypt Kubernetes secrets in GKE with keys you manage in Cloud KMS. Moreover, you can store API keys, passwords, certificates, and other sensitive information with the Secret Manager storage system.

Pricing

• Cloud KMS pricing is based on:
  • the number of active key versions
  • the protection level on the key versions
  • usage rate for key operations.

Google Cloud Armor

 

• Help protect your applications and websites against denial of service and web attacks.
• Detect and mitigate attacks against your Cloud Load Balancing workloads.
• Mitigate OWASP Top 10 risks and help protect workloads on-premises or in the cloud.

Features

• Comes with predefined rules for protection against OWASP Top 10 risks.
• Easily monitor the metrics associated with your policies in the Cloud Monitoring dashboard.
• View suspicious traffic patterns on the Cloud Armor dashboard directly.
• Can be run in preview mode to understand and study ahead of the effects of the rules defined on production traffic.
• Identify and enforce access control based on the geographic location of incoming traffic and IP addresses.
• Can protect and defend on-premises applications from DDoS and web attacks.

Pricing

Google Cloud Armor Managed Protection tiers:

• The Standard tier charges for security policies and rules within that policy, including well-formed L7 requests that are evaluated by a security policy.
• The Plus tier is now in beta. It implements a subscription-based pricing model capped for the first 100 backend services and additional charges for additional resources per month.

Google Cloud Identity

 

• Cloud Identity is an API for provisioning and managing identity resources.
• Is a unified identity, access, app, and endpoint management (IAM/EMM) platform that helps IT and security teams maximize end-user efficiency, protect company data, and transition to a digital workspace.

Features

• Use a single admin console to manage user, access, app, and device policies.
• Monitor your security and compliance posture with reporting and auditing capabilities, and investigate threats with Security Center.
• Helps you enforce policies for personal and corporate devices.
• Give users one-click access to apps with Single Sign-On (SSO).
• Hybrid Identity Management
  • Extend your on-premises directory to the cloud with Google Cloud Active Directory Sync.
  • This will enable simpler access to traditional apps and infrastructure with secure LDAP.
• Integrates with hundreds of applications out of the box.

Pricing

• Cloud Identity has free and premium editions.
• Premium edition charges your organization per month per user.

Google Cloud Identity and Access Management (IAM)

 

• Create and manage permissions for your Google Cloud resources with Identity Access Management (IAM).
• Provides a unified view into your organization’s security policy with built-in auditing to ease compliance purposes.

Features

• Lets you authorize who can take specific actions on resources to give you full control and visibility on your Google Cloud services centrally.
• Permissions are represented in the form of service.resource.verb
• Can map job functions into groups and roles.
• With IAM, users only get access to what they need to get the job done.
• Cloud IAM enables you to grant access to cloud resources at fine-grained levels, well beyond project-level access.
• You can leverage Cloud Identity to easily create or sync user accounts across applications and projects.
• IAM lets you set policies at the following levels of the resource hierarchy:
  • Organization level
    • The organization resource represents your company.
    • IAM roles granted at this level are inherited by all resources under the organization.
  • Folder level
    • Folders can contain projects, other folders, or a combination of both.
    • Roles granted at the highest folder level will be inherited by projects or other folders that are contained in that parent folder.
  • Project level
    • Projects represent a trust boundary within your company.
    • Services within the same project have a default level of trust. For example, App Engine instances can access Cloud Storage buckets within the same project.
    • IAM roles granted at the project level are inherited by resources within that project.
  • Resource level
    • Grant certain users permission to a single resource within a project.

Roles

• A role contains a set of permissions that allows you to perform specific actions on Google Cloud resources.
• You don’t directly grant users permissions in IAM. Instead, you grant them roles, which bundle one or more permissions.
• To make permissions available to members, including users, groups, and service accounts, you grant roles to the members.
• There are three types of roles in Google Cloud IAM:
  • Basic Roles
    • Includes Owner, Editor, and Viewer role that existed prior to the introduction of IAM.
  • Predefined Roles
    • Provides granular access for a specific service and is managed and defined by Google Cloud.
    • Prevents unwanted access to other resources.
    • Google is responsible for updating and adding permissions as necessary.
  • Custom Roles
    • Provides granular access according to a user-defined list of permissions.
    • You can create a custom IAM role with one or more permissions and then grant that custom role to users or groups.
    • Custom roles are not maintained by Google.
  • You can grant multiple roles to a user or a group.

Service Accounts

• A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person.
• Applications use service accounts to make authorized API calls, authorized as either:
  • the service account itself
  • as Google Workspace
  • as Cloud Identity users through domain-wide delegation
• A service account is identified by its email address, which is unique to the account.
  • service-account-name@project-id.iam.gserviceaccount.com
• Each service account is associated with two sets of public/private RSA key pairs used to authenticate to Google.
• Types of service accounts:
  • User-managed service accounts
  • Default service accounts
    • Google creates a user-managed service account when you use Google Cloud services. These accounts are called default service accounts.
    • The default service accounts help you get started with Google Cloud services quickly.
  • In addition to being an identity, a service account is also a resource with IAM policies attached to it, which means you can define who can use the account and who can perform specific actions on the service account.

Policy

• A policy is a collection of bindings, audit configuration, and metadata.
• A binding associates (or binds) one or more members with a single role and any context-specific conditions that change how and when the role is granted.
• Each binding includes the following fields:
  • A member, known as an identity or principal, can be a:
    • User Account
    • Service Account
    • Google group
    • Domain
  • A role, which is a named collection of permissions that grant access to perform actions on Google Cloud resources.
  • A condition, which is a logical expression that further constrains the role binding based on attributes about the request, such as its origin, the target resource, and more.

Groups

• Groups help you manage your users at scale. It is a simple way to attach roles to users with the same job functions.
• Each member of a Google group inherits the Identity and Access Management (IAM) roles granted to that group.
• A user can belong to multiple groups.

Best Practices

• Enforce least privilege at all times.
• Mirror your Google Cloud resource hierarchy structure to your organization structure.
• Set policies at the organization level and at the project level rather than at the resource level.
• It is easier and better to manage members in a Google group than to update an IAM policy.
• In deciding how to use a service account, use the following flow-chart to guide you in your decision-making process.

• Rotate your service account keys using the IAM service account API.
• For production workloads, it’s best practice to use user-managed service accounts instead of the default service accounts.

Google Cloud Router

 

• Cloud Router is a fully distributed and managed Google Cloud service that helps you define custom dynamic routes and scales with your network traffic.

Features

• It works with both legacy networks and Virtual Private Cloud (VPC) networks.
• Cloud Router utilizes Border Gateway Protocol (BGP) to exchange routes between your Virtual Private Cloud (VPC) network and your on-premises network.
• Using Cloud Router is required or recommended in the following cases:
  • Required for Cloud NAT
  • Required for Cloud Interconnect and HA VPN
  • A recommended configuration option for Classic VPN
• When you extend your on-premises network to Google Cloud, use Cloud Router to dynamically exchange routes between your Google Cloud networks and your on-premises network.
• Cloud Router peers with your on-premises VPN gateway or router. The routers exchange topology information through BGP.

Route advertisements

• Through BGP, Cloud Router advertises the IP addresses of Google resources that clients in your on-premises network can reach. Your on-premises network then sends packets to your VPC network that have a destination IP address matching an advertised IP range. After reaching Google Cloud, your VPC network’s firewall rules and routes determine how Google Cloud route the packets.
• Default Route Advertisement – Cloud Router advertises subnets in its region for regional dynamic routing or all subnets in a VPC network for global dynamic routing.
• Custom Route Advertisement – You explicitly specify the routes that a Cloud Router advertises to your on-premises network.

Google Cloud Hybrid Connectivity

 

• There are several ways to extend your on-premises environment to the Google Cloud Platform.
• You can connect your infrastructure to Google Cloud Platform (GCP) on your terms, from anywhere based on your requirements.

Cloud Interconnect

• Provides low latency, highly available connections that enable you to reliably transfer data between your on-premises and Google Cloud VPCs.
• Cloud Interconnect connections provide internal IP address communication, which means internal IP addresses are directly accessible from both networks.
• Cloud Interconnect offers two options to extend your on-premises network to the Google Cloud Platform:
  • Dedicated Interconnect
    • Direct physical Connection to Google’s network.
  • Partner Interconnect
    • Provides connectivity through a supported service provider.
  • You can use Cloud Interconnect in combination with Private Google Access for on-premises resources so that your on-premises resources can use internal IP addresses rather than external IP addresses to reach Google APIs and services.

Direct Peering

• Direct Peering connects your on-premises network to Google services, including Google Cloud products that can be exposed via one or more public IP addresses.
• Traffic from Google’s network to your on-premises network also takes that same connection, including traffic from VPC networks in your projects.
• Direct Peering exists outside of Google Cloud Platform. So, unless you need to access Google Workspace applications, the recommended methods of access to Google Cloud Platform are via Dedicated Interconnect or Partner Interconnect.

Carrier Peering

• Carrier Peering enables you to access Google applications, such as Google Workspace, by using a service provider to obtain enterprise-grade network services that connect your infrastructure to Google.
• When connecting to Google through a service provider, you can get connections with higher availability and lower latency, using one or more links.

Cloud VPN

• Cloud VPN securely extends your peer network to Google’s network through an IPsec VPN tunnel.
• Ipsec VPN tunnels encrypt data by using industry-standard Ipsec protocols as traffic traverses the public Internet.
• It only requires a VPN device in your on-premises network, unlike Cloud Interconnect that comes with overhead and costs to set up a direct private connection.
• Cloud VPN pricing is based on the location of the Cloud VPN gateway and the number of tunnels per hour.

Google Virtual Private Cloud

 

• You can create and manage your own virtual topology network where you can launch your Google Cloud resources using Google Virtual Private Cloud (VPC).
• Google VPC is the networking layer of Google Cloud resources.
• A VPC spans all the zones in the region. After creating a VPC, you can add one or more subnets in each zone.

Key Concepts

• A virtual private cloud (VPC) allows you to specify an IP address range for the VPC, add and expand subnets, and configure firewall rules.
• You can expand CIDR ranges without downtime.
• To protect Google Cloud resources, segment your networks by setting up firewall rules.
• Projects can contain multiple VPC networks unless you create an organizational policy that does not allow it.
• New projects start with a default network that has one subnetwork.
• VPC networks including their firewall rules and associated routes are global resources.
• Subnets are regional resources.
• Resources inside the same VPC network can communicate with each other by using an internal IPv4 address but is still subject to applicable network firewall rules.
• Instances with IPv4 addresses can communicate with Google APIs and services.
• Network administration can be secured by using Identity and Access Management (IAM) roles.

Network and Subnets

• Each VPC network consists of one or more useful IP range partitions called subnets.
• Each subnet is associated with a region.
• A network must have at least one subnet before you can use it.
• Auto mode VPC networks create subnets in each region automatically. These automatically created subnets use a set of predefined IP ranges that fit within the 10.128.0.0/9 CIDR block.
• Custom mode VPC networks start with no subnets giving you full control.
• You can create more than one subnet per region.
• You can switch a VPC network from auto mode to custom mode. This is a one-way conversion which means custom mode VPC networks cannot be changed to auto mode VPC networks.

Configuring IP Addresses

• External IP Address
  • You should assign an external IP address to instances if you need them to communicate with the Internet.
  • Instances support static and ephemeral external IP addresses.
• Internal IP Address
  • You should assign a specific internal IP address when you create a VM instance.
  • You can reserve a static internal IP address for your project and assign that address to your resources.
  • Static external IP addresses can be either a regional or a global resource. A regional static IP address allows resources of that region or resources of zones within that region to use the IP address.

Firewall Rules

• Firewall rules are defined at the network level.
• They only apply to the network where they are created but the name defined for each of them must be unique to the project.
• Firewall rule components
  • The direction of connection:
    • Ingress rules apply to incoming connections from specified sources to Google Cloud targets
    • Egress rules apply to connections going to specified destinations from targets.
  • A numerical priority, which determines whether the rule is applied.
    • Only the highest priority (lowest priority number) rule whose other components match traffic is applied;
    • Conflicting rules with lower priorities are ignored.
  • An action upon match, either allow or deny, decides whether the rule permits or blocks connections.
  • The enforcement status of the firewall rule.
  • A target, which defines the instances to which the rules apply.
  • A source for ingress rules or a destination for egress rules.
  • The protocol (such as TCP, UDP, or ICMP) and destination port.

Routes

• System-generated default route
  • When you create a VPC network, it includes a system-generated default route which serves as a path out of the VPC network, including the path to the Internet, and provides the standard path for Private Google Access.
• Subnet routes – define paths to resources like VMs and internal load balancers in a VPC network.
• Static routes – are defined using static route parameters and support static route next hops.
• Dynamic routes – are routes managed by Cloud Routers inside the VPC network. Their destinations are IP address ranges outside your VPC network, from a BGP peer. Dynamic routes are utilized by:
  • Dedicated Interconnect
  • Partner Interconnect
  • HA VPN tunnels
  • Classic VPN tunnels that use dynamic routing

Communications and access for App Engine

• VPC firewall rules apply to resources running in the VPC network. For App Engine instances, firewall rules work as follows:
  • App Engine standard environment
    • Only App Engine firewall rules apply to ingress traffic. App Engine standard environment instances do not run inside your VPC network which means VPC firewall rules do not apply to them.
  • App Engine flexible environment
    • Both App Engine and VPC firewall rules apply to ingress traffic. Inbound traffic is only permitted if it is allowed by both types of firewall rules. For outbound traffic, VPC firewall rules shall apply.

Connecting VPC Networks

• An organization can use a Shared VPC to keep a VPC network in a common host project. Authorized IAM members from other projects in the same organization can create resources that use the Shared VPC network’s subnet.
• You can use VPC Network Peering to connect VPCs to other VPC networks located in different projects or organizations.
• VPC networks can be securely connected in hybrid environments by utilizing Cloud VPN or Cloud Interconnect.

Pricing

• No charge for egress through network IP addresses. There are charges though for egress traffic through external IP addresses, even if traffic is in the same zone.
• You are also charged for active and unused static and ephemeral IP addresses inside your VPC.