Author: jayendrapatil

Google Cloud DDoS Protection and Mitigation

~ jayendrapatil

Google Cloud DDoS Protection and Mitigation

  • A Denial of Service (DoS) attack is an attempt to render the service or application unavailable to the end-users.
  • With Distributed Denial of Service (DDoS) attacks, the attackers use multiple resources (often a large number of compromised hosts/instances) to orchestrate large-scale attacks against targets.
  • Successfully thwarting and handling DDoS attacks is a shared responsibility between Google Cloud Platform and you.
  • DDoS defense involves deploying detection systems, implementing barriers, and being able to absorb attacks by scaling in order to prevent attackers from overwhelming or disabling access to the services or applications

DDoS Protection and Mitigation Best Practices

Reduce the Surface Attack

  • Provision an isolated and secure piece using Google Cloud VPC
  • Isolate and secure using subnetworks and networks, firewall rules, tags, and IAM
  • Open access for only required ports and protocols using firewall rules
    and/or protocol forwarding.
  • Anti-spoofing protection for the private network (IP addresses) is provided by default.
  • GCP automatically provides isolation between virtual networks.

Isolate the internal traffic from the external world

  • Deploy instances without public IPs unless necessary.
  • Set up a NAT gateway or SSH bastion to limit the number of instances that are exposed to the internet.
  • Deploy Internal Load Balancing for the internal client instances accessing internally deployed services to avoid exposure to the external world

DDoS Protection using Proxy-based Load Balancing

Scale to Absorb the Attack

  • Google Frontend Infrastructure – GFE
    • With Google Global Cloud Load Balancing, the GFE terminates user traffic, automatically scales to absorb certain types of attacks (e.g., SYN floods) before they reach the compute instances
  • Anycast-based Load Balancing
    • HTTP(S) Load Balancing and SSL proxy Load Balancing enable a single anycast IP to front-end the deployed backend instances in all regions.
    • User traffic is directed to the closest backend with capacity
    • In the event of a DDoS attack, it increases the surface area to absorb this attack by moving traffic to instances with available capacity in any region where backends are deployed.
  • Autoscaling
    • A sufficient number of backend instances should be provisioned and autoscaling configured to handle spikes in traffic.
    • In the event of a sudden traffic spike, the load balancing proxy layer will distribute the traffic across all the backends with available capacity
    • In parallel, the autoscaler ramps up the backends inline with traffic that needs to be handled.

DDoS Protection with CDN Offloading

  • Cloud CDN acts as a proxy between the clients and the origin servers
  • For cacheable content, Cloud CDN caches and services this content from points-of-presence (POPs) closer to the users as opposed to sending them to backend servers (instances).
  • In the event of DDoS attack for cacheable content, the requests are sent to POPs all over the globe as opposed to the origin servers, thereby providing a larger set of locations to absorb the attack.

Deploy Third-party DDoS Protection Solutions

  • Third-party DDoS protection solutions can used used to protect against DDoS attacks.
  • DDoS solutions can be deployed using Google Cloud Launcher.

App Engine Deployment

  • App Engine is designed to be a fully multi-tenant system and implements a number of safeguards intended to ensure that a single bad application will not impact the performance or availability of other applications
  • App Engine sits behind the GFE which mitigates and absorbs many Layer 4 and below attacks, such as SYN floods, IP fragment floods, port exhaustion, etc.
  • A set of IPs/IP networks via a dos.yaml file can be specified to block them from accessing the application(s).

Google Cloud Storage

  • Use Signed URLs to control access and if the users are not needed a Google account in order to be able to access the Google Cloud Storage resources,

API rate-limiting

  • API rate limits define the number of requests that can be made to the Google Compute Engine API.
  • API rate limits apply on a per-project basis. Currently, projects are limited to an API rate limit of 20 requests/second.

Resource Quotas

  • Compute Engine enforces quotas on resource usage for a variety of
    reasons, as the quotas, protect the community of Google Cloud users by preventing unforeseen spikes in usage.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Reference

Google_Cloud_DDoS_Protection

Google Cloud Data Loss Prevention – DLP

~ jayendrapatil

Google Cloud Data Loss Prevention – DLP

  • Cloud Data Loss Prevention – DLP is a fully managed service designed to help discover, classify, and protect the most sensitive data.
  • DLP helps inspect the data to gain valuable insights and make informed decisions to secure your data
  • DLP effectively reduces the data risk with de-identification methods like masking and tokenization
  • DLP seamlessly inspects and transforms the structured and unstructured data

Cloud Data Loss Prevention (DLP) Action

  • Cloud Data Loss Prevention (DLP) action is something that occurs after a DLP job completes successfully or, in the case of emails, on error.
  • DLP supports the following types of actions
    • Save findings to BigQuery (inspection and risk jobs)
    • Publish to Pub/Sub (inspection and risk jobs)
    • Publish to Security Command Center (risk jobs)
    • Publish to Data Catalog (risk jobs)
    • Publish to Google Cloud’s operations suite (risk jobs)
    • Notify by email (inspection and risk jobs)

Cloud Data Loss Prevention Key Concepts

  • Classification is the process to inspect the data and know what data we have, how sensitive it is, and the likelihood.
  • De-identification is the process of removing identifying information from data.
  • De-identification techniques supported by Cloud DLP
    • Redaction: Deletes all or part of a detected sensitive value.
    • Replacement: Replaces a detected sensitive value with a specified surrogate value.
    • Masking: Replaces a number of characters of a sensitive value with a specified surrogate character, such as a hash (#) or asterisk (*).
    • Pseudonymization: replaces sensitive data values with cryptographically generated tokens.
    • Generalization: is the process of abstracting a distinguishing value into a more general, less distinguishing value. Generalization attempts to preserve data utility while also reducing the identifiability of the data.
    • Bucketing: “Generalizes” a sensitive value by replacing it with a range of values. (For example, replacing a specific age with an age range, or temperatures with ranges corresponding to “Hot,” “Medium,” and “Cold.”)
    • Date shifting: Shifts sensitive date values by a random amount of time.
    • Time extraction: Extracts or preserves specified portions of date and time values.

Cloud Data Loss Prevention InfoTypes

  • Cloud Data Loss Prevention (DLP) uses information types – or infoTypes – to define what it scans for.
  • An infoType is a type of sensitive data, such as a name, email address, telephone number, identification number, credit card number, and so on.
  • An infoType detector is the corresponding detection mechanism that matches an infoType’s matching criteria.
  • Cloud DLP uses infoType detectors in the configuration for its scans to determine what to inspect for and how to transform findings. InfoType names are also used when displaying or reporting scan results.
  • Cloud DLP supports the following infoType detectors
    • Built-in infoType detectors specified by name and include detectors for the country- or region-specific sensitive data types as well as globally applicable data types.
    • Custom infoType detectors, defined by you
      • Small custom dictionary detectors
        • simple word lists that Cloud DLP matches on
        • ideal for several tens of thousands of words or phrases
        • preferred if the word list doesn’t change significantly.
      • Large custom dictionary detectors
        • are generated by Cloud DLP using large lists of words or phrases stored in either Cloud Storage or BigQuery.
        • ideal for a large list of words or phrases—up to tens of millions.
      • Regular expressions (regex) detectors
        • enable Cloud DLP to detect matches based on a regex pattern.
  • Cloud DLP supports inspection rules to fine-tune scan results using
    • Exclusion rules decrease the number of findings returned by adding rules to a built-in or custom infoType detector.
    • Hotword rules increase the quantity or change the likelihood value of findings returned by adding rules to a built-in or custom infoType detector.
  • DLP uses a bucketized representation of likelihood, which is intended to indicate how likely it is that a piece of data matches a given infoType
    • LIKELIHOOD_UNSPECIFIED: Default value; same as POSSIBLE.
    • VERY_UNLIKELY: very unlikely that the data matches the given InfoType
    • UNLIKELY: unlikely that the data matches the given InfoType.
    • POSSIBLE: possible that the data matches the given InfoType.
    • LIKELY: likely that the data matches the given InfoType.
    • VERY_LIKELY: very likely that the data matches the given InfoType

DLP Classification and De-identification

  • Cloud DLP can easily classify, redact and de-identify sensitive data contained in text-based content and images, including content stored in Google Cloud storage repositories.
  • Text Classification and Reduction
    • Text Classification returns classification findings
    • Automatic Text Redaction produces an output with sensitive data matches removed using a placeholder of ***
  • Image Classification and Reduction
    • DLP uses Optical Character Recognition (OCR) technology to recognize text prior to classification. Similar to text classification, it returns findings, but it also adds a bounding box where the text was found.
    • Inspection
      • Cloud DLP inspects the submitted base64-encoded image for the specified intoTypes.
      • It returns the detected InfoTypes, along with one or more set of pixel coordinates and dimensions.
      • Each set of pixel coordinate and dimension values indicate the bottom-left corner and the dimensions of bounding boxes, respectively
      • Each bounding box corresponds to all or part of a Cloud DLP finding.
    • Redaction
      • Cloud DLP redacts any sensitive data findings by masking them with opaque rectangles.
      • It returns the redacted base64-encoded image in the same image format as the original image.
      • Color of the redaction boxes can be configured in the request.
  • Storage classification
    • scans data stored in Cloud Storage, Datastore, and BigQuery
    • supports scanning of binary, text, image, Microsoft Word, PDF, and Apache Avro files
    • unrecognized file types are scanned as binary files.
  • Date, if considered PII, can be handled
    • Using generalization, or bucketing, which can however remove the utility in the dates for e.g. generalizing all the dates to just the year
    • Using date obfuscation by date shifting which randomly shifts a set of dates but preserves the sequence and duration of a period of time.

DLP Re-identification Risk Analysis

  • DLP Re-identification risk analysis is the process of analyzing sensitive data to find properties that might increase the risk of subjects being identified, or of sensitive information about individuals being revealed.
  • Risk analysis methods can be used before de-identification to help determine an effective de-identification strategy, or after de-identification to monitor for any changes or outliers.
  • Re-identification is the process of matching up de-identified data with other available data to determine the person to whom the data belongs.

Cloud Data Loss Prevention Templates

  • DLP Templates help decouple configuration information from the implementation of the requests
  • Templates provide a robust way to manage large-scale rollouts of Cloud DLP capabilities.
  • Cloud DLP supports two types of templates:
    • Inspection Templates: Templates for saving configuration information for inspection scan jobs, including what predefined or custom detectors to use.
    • De-identification Templates: Templates for saving configuration information for de-identification jobs, including both infoType and structured dataset transformations.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Reference

Google_Cloud_Data_Loss_Prevention

Google Cloud Identity-Aware Proxy IAP

~ Last updated on : ~ jayendrapatil

Google Cloud Identity Aware-Proxy – IAP

  • Identity-Aware Proxy IAP allows managing access to HTTP-based apps both on Google Cloud and outside of Google Cloud.
  • Identity-Aware Proxy IAP intercepts the web requests sent to the application, authenticates the user making the request using the Google Identity Service, and only lets the requests through if they come from an authorized user. In addition, it can modify the request headers to include information about the authenticated user.
  • Identity-Aware Proxy IAP helps establish a central authorization layer for applications accessed by HTTPS to use an application-level access control model instead of relying on network-level firewalls.
  • Access policies can be defined centrally and applied to all of the applications and resources.
  • IAP policies scale across the organization.
  • IAP uses Google identities and IAM, by default but by leveraging Identity Platform a wide range of external identity providers can be used, such as:
    • Email/password
    • OAuth (Google, Facebook, Twitter, GitHub, Microsoft, etc.)
    • SAML
    • OIDC
    • Phone number
    • Custom
    • Anonymous

How IAP Works

Google Cloud Identity-Aware Proxy Compute GKE

  • Only users with the correct IAM role can access application or resource protected by IAP
  • Users are subject to the fine-grained access controls implemented by the product in use without requiring a VPN.
  • When a user tries to access an IAP-secured resource, IAP performs authentication and authorization checks.
  • Authentication
    • Requests to the Google Cloud resources come through App Engine, Cloud Load Balancing (HTTPS), or internal HTTP load balancing.
    • If IAP is enabled, information about the protected resource is sent to the IAP authentication server which includes information like the project number, the request URL, and any IAP credentials in the request headers or cookies.
    • For authentication, the user is directed to an OAuth 2.0 Google Account sign-in flow that stores a token in a browser cookie for future sign-ins.
    • If the request credentials are valid, the authentication server uses those credentials to get the user’s identity (email address and user ID).
    • The authentication server then uses the identity to check the user’s IAM role and check if the user is authorized to access the resource.
  • Authorization
    • After authentication, IAP applies the relevant IAM policy to check if the user is authorized to access the requested resource.
    • User with IAP-secured Web App User role on the Cloud Console project where the resource exists is authorized to access the application
    • When you turn on IAP for a resource, it automatically creates an OAuth 2.0 client ID and secret.
  • For on-premises apps, the requests are routed through the IAP connector which forwards the request through a site-to-site connection established with Cloud Interconnect from Google Cloud to the on-premises network.

Securing with Signed Headers

  • Identity-Aware Proxy (IAP) can be configured to use JSON Web Tokens (JWT) to make sure that a request to the app is authorized
  • Be default, only headers x-goog-authenticated-user-{email,id}are passed and can be easily forged and bypass IAP
  • It protects App from
    • IAP is accidentally disabled;
    • Misconfigured firewalls;
    • Access from within the project.
  • IAP JWT provides a more secure alternative by verifying the header, payload, and signature of the JWT, which is in the HTTP request header x-goog-iap-jwt-assertion
  • Signed headers provide secondary security in case someone bypasses IAP.

IAP Best Practices

  • Don’t use a third-party CDN in front of the application. CDNs may cache content and serve cached pages to unauthenticated users.
  • Make sure all requests to Compute Engine or GKE are routed through the load balancer:
  • Use signed headers for App Engine flexible environment, App Engine standard environment, Compute Engine, and GKE applications.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Reference

Google_Cloud_Identity-Aware_Proxy

Google Cloud Security Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

Cloud Armor

  • Cloud Armor protects the applications from multiple types of threats, including distributed denial-of-service (DDoS) attacks and application attacks like cross-site scripting (XSS) and SQL injection (SQLi).
  • Cloud Armor provides protection only to applications running behind an external HTTP(S) and TCP/SSL Proxy load balancer.
  • Cloud Armor supports applications deployed on Google Cloud, in a hybrid deployment, or in a multi-cloud architecture.
  • Cloud Armor is implemented at the edge of Google’s network in Google’s points of presence (PoP).
  • Security policies protect applications running behind a load balancer from DDoS and other web-based attacks
  • Backend service can have only one security policy associated with it
  • Prioritized rules define configurable match conditions, actions (allow or deny) and order in a security policy
  • Cloud Armor provides Preview mode that helps evaluate and preview the rules before going live.

Cloud Identity-Aware Proxy

  • Identity-Aware Proxy IAP allows managing access to HTTP-based apps both on Google Cloud and outside of Google Cloud.
  • Identity-Aware Proxy IAP intercepts the web requests sent to the application, authenticates the user making the request using the Google Identity Service, and only lets the requests through if they come from an authorized user. In addition, it can modify the request headers to include information about the authenticated user.
  • Identity-Aware Proxy IAP helps establish a central authorization layer for applications accessed by HTTPS to use an application-level access control model instead of relying on network-level firewalls.
  • IAP uses Google identities and IAM and can leverage external identity providers as well like OAuth with Facebook, GitHub, Microsoft, SAML, etc.
  • Identity-Aware Proxy (IAP) can be configured to use JSON Web Tokens (JWT) as signed headers to make sure that a request to the app is authorized and doesn’t bypass IAP

Cloud Data Loss Prevention – DLP

  • Cloud Data Loss Prevention – DLP is a fully managed service designed to help discover, classify, and protect the most sensitive data.
  • provides two key features
    • Classification is the process to inspect the data and know what data we have, how sensitive it is, and the likelihood.
    • De-identification is the process of removing, masking, replacing information from data.
  • uses information types – or infoTypes – to define what it scans like credit card numbers, email addresses, etc.
  • provides various built-in infoType detector and supports custom ones
  • supports inspection rules to fine-tune scan results using
    • Exclusion rules decrease the number of findings
    • Hotword rules increase the quantity or change the likelihood value of findings
  • provides likelihood, which indicates how likely it is that a piece of data matches a given infoType like VERY_LIKELY or POSSIBLE, etc.
  • supports Text Classification and Reduction
  • supports Image Classification and Reduction, where the image is handled using its base64 encoded version
  • supports storage classification with scans on data stored in Cloud Storage, Datastore, and BigQuery
  • supports scanning of binary, text, image, Microsoft Word, PDF, and Apache Avro files
  • supports Templates help decouple configuration information from the implementation of the requests and manage large scale rollouts

Security Command Center – SCC

  • is a Security and risk management platform
  • helps generate curated insights that provide a unique view of incoming threats and attacks to the assets, which include organization, projects, instances, and applications
  • displays possible security risks, called findings, that are associated with each asset.
  • provides services
    • Security Health Analytics provides managed vulnerability assessment scanning that can automatically detect the highest severity vulnerabilities and misconfigurations across assets.
    • Web Security Scanner custom scans provide granular information about application vulnerability findings like outdated libraries, XSS, etc.
    • Cloud Data Loss Prevention discovers, classifies, and protects sensitive data
    • Cloud Armor protects Google Cloud deployments against threats
    • Anomaly Detection identifies security anomalies for the projects and VM instances, like potential leaked credentials and coin mining, etc.
    • Container Threat Detection can detect the most common container runtime attacks
    • Forseti Security, the open-source security toolkit, and third-party security information and event management (SIEM) applications
    • Event Threat Detection monitors the organization’s Cloud Logging stream and consumes logs to detect Malware, Cryptomining, etc.
    • Phishing Protection helps prevent users from accessing phishing sites by classifying malicious content that uses the brand and reporting the unsafe URLs to Google Safe Browsing
    • Continuous Exports, which automatically manage the export of new findings to Pub/Sub.

DDoS Protection and Mitigation

  • Distributed Denial of Service (DDoS) Protection and Mitigation is a shared responsibility between Google Cloud and the Customer
  • DDoS attack is an attempt to render the service or application unavailable to the end-users using multiple sources
  • DDoS Protection and Mitigation Best Practices
    • Reduce the Attack Surface
      • Isolate and secure network using VPC, subnets, firewall rules. tags and IAM
      • Google provides Anti-spoofing protection and Automatic isolation between virtual networks
    • Isolate Internal Traffic
      • Use privates IPs and avoid using Public IPs
      • Use NAT Gateway and Bastion host
      • Use Internal Load Balancer for internal traffic
    • Enable Proxy-based Load Balancing
      • HTTP(S) or SSL proxy load balancer uses GFE that helps mitigate and absorb layer 4 and other attacks
      • Disperse traffic across multiple regions
    • Scale to Absorb the Attack
      • Use GFE for protection
      • Use Anycast-based load balancing to provide single anycast IP to FE
      • Use Autoscaling to scale backend services as per the demand
    • Protection using CDN Offloading
      • CDN acts as a proxy and can help render cache content reducing the load on the origin servers
    • Deploy Third-party DDoS Protection solutions
    • App Engine Deployment
      • A fully multi-tenant system with isolation
    • Google Cloud Storage
      • Use signed URLs to access Google Cloud Storage
    • API Rate Limiting
      • Define rate limiting based on the number of allowed requests
      • API Rate limits are per applied per-project basis
    • Resource Quotas
      • Quotas help prevent unforeseen spikes in usage

Access Context Manager

  • Access Context Manager allows organization administrators to define fine-grained, attribute-based access control for projects and resources
  • helps prevent data exfiltration
  • helps reduce the size of the privileged network and move to a model where endpoints do not carry ambient authority based on the network.
  • helps define desired rules and policy but isn’t responsible for policy enforcement. The policy is configured and enforced across various points, such as VPC Service Controls.

FIPS 140-2 Validated

  • The NIST developed the Federal Information Processing Standard (FIPS) Publication 140-2 as a security standard that sets forth requirements for cryptographic modules, including hardware, software, and/or firmware, for U.S. federal agencies.
  • FIPS 140-2 Validated certification was established to aid in the protection of digitally stored unclassified, yet sensitive, information.
  • Google Cloud Platform uses a FIPS 140-2 validated encryption module called BoringCrypto in its production environment.
  • Data in transit to the customer and between data centers, and data at rest are encrypted using FIPS 140-2 validated encryption.
  • BoringCrypto module that achieved FIPS 140-2 validation is part of the BoringSSL library.
  • BoringSSL library as a whole is not FIPS 140-2 validated
  • In order to operate using only FIPS-validated implementations:
    • Google’s Local SSD storage product is automatically encrypted with NIST approved ciphers, but Google’s current implementation for this product doesn’t have a FIPS 140-2 validation certificate. If you require FIPS-validated encryption on Local SSD storage, you must provide your own encryption with a FIPS-validated cryptographic module.
    • Google automatically encrypts traffic between VMs that travels between Google data centers using NIST-approved encryption algorithms, but this implementation does not have a FIPS validation certificate. If you require this traffic to be encrypted with a FIPS-validated implementation, you must provide your own.
    • Clients connecting to Google infrastructure with TLS clients must be configured to require use of secure FIPS-compliant algorithms; if the TLS client and GCP’s TLS services agree on an encryption method that is incompatible with FIPS, a non-validated encryption implementation will be used.
    • Applications built and operated on GCP might include their own cryptographic implementations; in order for the data they process to be secured with a FIPS-validated cryptographic module, you must integrate such an implementation yourself.
  • All Google Cloud regions and zones currently support FIPS 140-2 validated encryption.

Google Cloud Armor

~ Last updated on : ~ jayendrapatil

Google Cloud Armor

  • Google Cloud Armor helps protect the applications from multiple types of threats, including distributed denial-of-service (DDoS) attacks and application attacks like cross-site scripting (XSS) and SQL injection (SQLi).
  • Google Cloud Armor provides protection only to applications running behind an external load balancer, and several features are only available for external HTTP(S) and TCP/SSL Proxy load balancers.
  • Cloud Armor supports applications deployed on Google Cloud, in a hybrid deployment, or in a multi-cloud architecture.
  • Cloud Armor is implemented at the edge of Google’s network in Google’s points of presence (PoP).
  • Cloud Armor does not support following
    • Cloud CDN
    • Cloud Storage Buckets
    • Internal HTTP/S Load Balancer
  • Security policies
    • protect applications running behind a load balancer from DDoS and other web-based attacks
    • are available only for backend services behind an external HTTP(S) load balancer
    • backend service’s load balancing scheme must be EXTERNAL
    • backend service’s protocol must be one of HTTP, HTTPS, or HTTP/2
    • backend service can have only one security policy associated with it
  • Prioritized rules define configurable match conditions, actions (allow or deny) and order in a security policy
  • Rule evaluation order is determined by rule priority, from the lowest number to the highest number
  • Security policies are made up of rules that allow or prohibit traffic from IP addresses or ranges defined in the rule
  • Preconfigured rules help protect the web applications from common attacks from the internet and help mitigate the OWASP Top 10 risks.
  • Adaptive Protection helps protect the applications and services from L7 distributed DDoS attacks by analyzing patterns of traffic to the backend services, detecting and alerting on suspected attacks, and generating suggested WAF rules to mitigate such attacks
  • Cloud Armor provides Preview mode that helps evaluate and preview the rules before going live.

Google Cloud Armor

Google Cloud Armor Works

Google Cloud Armor

  • Cloud Armor provides always-on DDoS protection against network or protocol-based volumetric DDoS attacks for applications behind external HTTP(S), SSL proxy, and TCP proxy load balancers.
  • Cloud Armor’s DDoS protection is always-on inline, scaling to the capacity of Google’s global network.
  • Cloud Armor is implemented at the edge of Google’s network in Google’s points of presence (PoP).
  • Cloud Armor security policies help allow or deny access to the external HTTP(S) load balancer at the Google Cloud edge, as close as possible to the source of incoming traffic.
  • Prevents unwelcome traffic from consuming resources or entering the VPC networks
  • Backend services behind an external HTTP(S) load balancer also have access to security policies to enforce custom Layer 7 filtering policies, including pre-configured WAF rules to mitigate the OWASP Top 10 web application vulnerability risks.
  • Backends to the backend service can be
    • VM instances in an instance group,
    • zonal network endpoint groups (zonal NEGs), or
    • internet network endpoint groups (internet NEGs).
  • Google Cloud Armor can be used to protect a hybrid deployment or multi-cloud architecture, the backends must be internet NEGs, or hybrid connectivity NEGs when you use Traffic Director in an on-premises or multi-environment deployment. Google Cloud Armor also protects serverless NEGs when traffic is routed through a load balancer.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company offers a popular gaming service. Your instances are deployed with private IP addresses, and external access is granted through a global load balancer. You believe you have identified a potential malicious actor, but aren’t certain you have the correct client IP address. You want to identify this actor while minimizing disruption to your legitimate users. What should you do?
    1. Create a Cloud Armor Policy rule that denies traffic and review necessary logs.
    2. Create a Cloud Armor Policy rule that denies traffic, enable preview mode, and review necessary logs.
    3. Create a VPC Firewall rule that denies traffic, enable logging and set enforcement to disabled, and review necessary logs.
    4. Create a VPC Firewall rule that denies traffic, enable logging and set enforcement to enabled, and review necessary logs

Reference

Google_Cloud_Armor

Google Cloud – Professional Cloud Network Engineer Certification learning path

Google Cloud - Professional Cloud Network Engineer Certification
~ Last updated on : ~ jayendrapatil

Google Cloud – Professional Cloud Network Engineer Certification learning path

Google Cloud – Professional Cloud Network Engineer certification exam focuses on almost all of the Google Cloud network services.

Google Cloud -Professional Cloud Network Engineer Certification Summary

  • Has 50 questions to be answered in 2 hours.
  • Covers a wide range of Google Cloud services mainly focusing on network services
  • Hands-on is a MUST, if you have not worked on GCP before make sure you do lots of labs else you would be absolutely clueless for some of the questions and commands
  • I did Coursera and ACloud Guru which is really vast, but hands-on or practical knowledge is MUST.

Google Cloud – Professional Cloud Network Engineer Certification Resources

Google Cloud – Professional Cloud Network Engineer Certification Topics

Network Services

  • Refer Google Cloud Networking Services Cheat Sheet
  • Virtual Private Cloud
    • Understand Virtual Private Cloud (VPC), subnets, and host applications within them
    • VPC Routes determine the next hop for the traffic. HINT: It can be defined for specific tags as well. More specific takes priority.
    • Firewall rules control the Traffic to and from instances. HINT: rules with lower integers indicate higher priorities. Firewall rules can be applied to specific tags.
    • VPC Peering allows internal or private IP address connectivity across two VPC networks regardless of whether they belong to the same project or the same organization. HINT: VPC Peering uses private IPs and does not support transitive peering
    • Shared VPC allows an organization to connect resources from multiple projects to a common VPC network so that they can communicate with each other securely and efficiently using internal IPs from that network HINT: VLAN attachments and Cloud Routers for Interconnect must be created in the host project
    • Understand the concept internal and external IPs and the difference between static and ephemeral IPs
    • VPC Subnets support primary and secondary (alias) IP range
    • Primary IP range of an existing subnet can be expanded by modifying its subnet mask, setting the prefix length to a smaller number.
    • Private Access options for services allow instances with internal IP addresses can communicate with Google APIs and services.
    • Private Google Access allows VMs to connect to the set of external IP addresses used by Google APIs and services by enabling Private Google Access on the subnet used by the VM’s network interface. HINT: Private Google Access is enabled on the subnet and not on the VPC level
    • VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.
    • Firewall Rules Logging enables auditing, verifying, and analyzing the effects of the firewall rules HINT: Default implicit ingress deny rule is not captured by firewall rules logging. Add an explicit deny rule
    • Resources within a VPC network can communicate with one another by using internal IPv4 addresses
  • Hybrid Connectivity
  • Cloud VPN
    • Cloud VPN provides secure connectivity from the on-premises data center to the GCP network through the public internet. Cloud VPN does not provide internal or private IP connectivity
    • Understand what are the requirements to setup Cloud VPN.
    • Cloud VPN is quick to setup and test hybrid connectivity
    • Understand limitations of Cloud VPN esp. 3Gbps limit. How it can be improved with multiple tunnels.
    • Cloud VPN requires non overlapping primary and secondary IPs address between on-premises and GCP VPC networks
    • Cloud VPN HA provides a highly available and secure connection between the on-premises and the VPC network through an IPsec VPN connection in a single region
  • Cloud Interconnect
    • Cloud Interconnect provides direct connectivity from the on-premises data center to GCP network
    • Dedicated Interconnect provides a direct physical connection between the on-premises network and Google’s network. Supports > 10Gbps
    • Partner Interconnect provides connectivity between the on-premises and VPC networks through a supported service provider. Supports 50Mbps to 10 Gbps
    • Understand Dedicated Interconnect vs Partner Interconnect  and when to choose
    • Know Interconnect as the reliable high speed, low latency, and dedicated bandwidth option.
    • Cloud Monitoring monitors interconnect links. Circuit Operational Status metric threshold tracks the circuits while Interconnect Operational Status metric tracks all the links
  • Cloud Router
    • Cloud Router provides dynamic routing using BGP with HA VPN and Cloud Interconnect
    • Cloud Router Global routing mode provides visibility to resources in all regions
    • Cloud Router uses Multi-exit Discriminator (MED) value to route traffic. The same MED value results in Active/Active connection and different MED results in Active/Passive connection
  • Cloud NAT
    • Cloud NAT allows VM instances without external IP addresses and private GKE clusters to send outbound packets to the internet and receive any corresponding established inbound response packets.
    • Requests would not be routed through Cloud NAT if they have an external IP address
  • Cloud Peering
    • Google Cloud Peering provides Direct Peering and Carrier Peering
    • Peering provides a direct path from the on-premises network to Google services, including Google Cloud products that can be exposed through one or more public IP addresses does not provide a private dedicated connection
  • Cloud Load Balancing
    • Google Cloud Load Balancing provides scaling, high availability, and traffic management for your internet-facing and private applications.
    • Understand Google Load Balancing options and their use cases esp. which is global and internal and what protocols they support.
      • Network Load Balancer – regional, external, pass through and supports TCP/UDP
      • Internal TCP/UDP Load Balancer – regional, internal, pass through and supports TCP/UDP
      • HTTP/S Load Balancer – regional/global, external, pass through and supports HTTP/S
      • Internal HTTP/S Load Balancer – regional/global, internal, pass through and supports HTTP/S
      • SSL Proxy Load Balancer – regional/global, external, proxy, supports SSL with SSL offload capability
      • TCP Proxy Load Balancer – regional/global, external, proxy, supports TCP without SSL offload capability
    • Cloud Load Balancing supports health checks with managed instance groups
  • Cloud CDN
    • Understand Cloud CDN as the global content delivery network
    • Know CDN works only for global external HTTP/S Load Balancer
    • Cache is not removed if the underlying origin data is removed. Cache has to be invalidated explicitly, or is removed once expired.
    • Cloud CDN does not compress but serves response from the origin as is. HINT: As LB adds Via header some web server do not compress response and must be configured to ignore the Via header
  • Cloud DNS
    • Understand Cloud DNS and its features
    • supports migration or importing of records from on-premises using JSON/YAML format
    • supports DNSSEC, a feature of DNS, that authenticates responses to domain name lookups and protects the domains from spoofing and cache poisoning attacks

Identity Services

  • Cloud Identity and Access Management
    • Identify and Access Management – IAM provides administrators the ability to manage cloud resources centrally by controlling who can take what action on specific resources.
    • Compute Network Admin does not provide access to SSL certificates and firewall rules. Need to assign Security Admin role

Compute Services

  • Compute services like Google Compute Engine and Google Kubernetes Engine are lightly covered more from the networking aspects
  • Google Compute Engine
    • Google Compute Engine is the best IaaS option for compute and provides fine grained control
    • Difference between managed vs unmanaged instance groups and auto-healing feature
    • Regional Managed Instance group helps spread load across instances in multiple zones within the same region providing scalability and HA
    • Managed Instance group helps perform canary and rolling updates
    • Managed Instance group autoscaling can be configured on CPU or load balancer metrics or custom metrics.
    • Managing access using OS Login or project and instance metadata
  • Google Kubernetes Engine

Security Services

  • Cloud Armor
    • Cloud Armor protects the applications from multiple types of threats, including DDoS attacks and application attacks like XSS and SQLi
    • with GKE needs to be configured with GKE Ingress
    • can be used to blacklist IP
    • supports preview mode to understand patterns without blocking the users

All the Best !!

Google Cloud Hybrid Connectivity

~ Last updated on : ~ jayendrapatil

Google Cloud Hybrid Connectivity

Google Cloud provides various network connectivity options to meet the needs, using either public networks, peering, or interconnect technologies

Google Cloud Hybrid Connectivity Options

Public Network Connectivity

Standard internet connection can be used to connect Google Cloud with the on-premises environment if it meets the bandwidth needs.

Cloud VPN

  • provides secure, private connectivity using IPSec
  • connects on-premises networks to VPC or two VPCs in GCP
  • traffic flows via the VPN tunnel but is still routed over the public internet
  • traffic is encrypted by one gateway and decrypted by the other
  • allows users to access private RFC1918 addresses on resources in the VPC from on-prem computers also using private RFC1918 addresses.
  • can be used with Private Google Access for on-premises hosts
  • provides guaranteed uptime of 99.99% using High availability VPN
  • supports only site-to-site VPN
  • supports up to 3Gbps per tunnel with a maximum of 8 tunnels
  • supports static as well as dynamic routing using Cloud Router
  • supports IKEv1 or IKEv2 using a shared secret

Peering

  • Peering provides better connectivity to Google Cloud as compared to the public connection. However, the connectivity is still not RFC1918-to-RFC1918 private address connectivity.
  • Peering gets your network as close as possible to Google Cloud public IP addresses.

Direct Peering

  • requires you to lease co-lo space and install and support routing equipment in a Google Point Of Presence (PoP).
  • supports BGP over a link to exchange network routes.
  • All traffic destined to Google rides over this new link, while traffic to other sites on the internet rides your regular internet connection.

Carrier Peering

  • preferred if installing equipment isn’t an option or would prefer to work with a service provider partner as an intermediary to peer with Google
  • connection to Google is via a new link connection installed to a partner carrier that is already connected to the Google network itself.
  • supports BGP or uses static routing over that link.
  • All traffic destined to Google rides over this new link.
  • Traffic to other sites on the internet rides your regular internet connection.

Interconnect

  • Interconnects are similar to peering in that the connections get your network as close as possible to the Google network.
  • Interconnects differ from peering as they provide connectivity using private address space into the Google VPC.
  • For RFC1918-to-RFC1918 private address connectivity, either a dedicated or partner interconnect is required

Dedicated Interconnect

  • provides private, high-performance connectivity to Google Cloud
  • requires you to lease co-lo space and install and support routing equipment in a Google Point Of Presence (PoP).
  • requires installing a link directly to Google by choosing a 10 Gbps or 200 Gbps pipe and provisioning a VLAN attachment over the physical link
  • gives the RFC1918-to-RFC1918 private address connectivity.
  • All traffic destined to the Google Cloud VPC rides over this new link.
  • Traffic to other sites on the internet rides the regular internet connection.
  • Single Interconnect connection does not offer HA and GCP recommends redundancy using 2 (99.9%) or 4 (99.99%) interconnect connections so that if one connection fails, the other connection can continue to serve traffic

Partner Interconnect

  • provides private, high-performance connectivity to Google Cloud
  • preferred if bandwidth requires are below 10 Gbps or installing equipment isn’t an option or would prefer to work with a service provider partner as an intermediary
  • similar to carrier peering in that you connect to a partner service provider that is directly connected to Google.
  • supports BGP or use static routing over that link.
  • requires provisioning a VLAN attachment over the physical link
  • gives the RFC1918-to-RFC1918 private address connectivity.
  • All traffic destined to your Google VPC rides over this new link.
  • Traffic to other sites on the internet rides your regular internet connection.

Google Cloud Hydrid Connectivity Decision Tree

Google Cloud Hydrid Connectivity Decision Tree

Google Cloud Hybrid Connectivity

Google Cloud Peering

~ Last updated on : ~ jayendrapatil

Google Cloud Peering

Direct Peering

  • Direct Peering establishes a direct peering connection between the on-premises network and Google’s edge network and exchanges high-throughput cloud traffic.
  • Direct Peering provides a direct path from the on-premises network to Google services, including Google Cloud products that can be exposed through one or more public IP addresses.
  • Traffic from Google’s network to the on-premises network also takes that direct path, including traffic from VPC networks in the projects.
  • Google Cloud customers must request that direct egress pricing be enabled for each of the projects after they have established Direct Peering with Google
  • Direct Peering exists outside of Google Cloud.
  • Direct Peering doesn’t produce any custom routes in a VPC network
  • Direct Peering does not provide any SLA
  • Direct peering helps reduce Internet egress rates to on-premises network from GCP resources

Carrier Peering

  • Carrier Peering helps access Google applications, such as Google Workspace, by using a service provider to obtain enterprise-grade network services that connect your infrastructure to Google.
  • Carrier Peering exists outside of Google Cloud
  • Carrier Peering doesn’t produce any custom routes in a VPC network
  • Direct Peering does not provide any SLA

Peering Requirements

  • Publicly routable ASN
  • Publicly routable address space (at least one /24 of IPv4 and/or one /48 of IPv6 space)
  • ASN record completed in PeeringDB
  • 24×7 NOC contact
  • Presence at one or more internet exchanges or private peering interconnection facilities listed for Google in PeeringDB
  • Up to date Maintainer, ASN, AS-SET, and Route/Route6 objects in an internet routing registry (IRR) used by Google

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You want to establish a dedicated connection to Google that can access Cloud SQL via a public IP address and that does not
    require a third-party service provider. Which connection type should you choose?

    1. Carrier Peering
    2. Direct Peering
    3. Dedicated Interconnect
    4. Partner Interconnect

 

Google Cloud Interconnect

~ Last updated on : ~ jayendrapatil

Google Cloud Interconnect

  • Google Cloud Interconnect provides two options for extending the on-premises network to the VPC networks in Google Cloud.
    • Dedicated Interconnect (Dedicated connection) provides a direct physical connection between the on-premises network and Google’s network
    • Partner Interconnect (Use a service provider) provides connectivity between the on-premises and VPC networks through a supported service provider.
  • Cloud Interconnect provides access to all Google Cloud products and services from the on-premises network except Google Workspace.
  • Cloud Interconnect also allows access to supported APIs and services by using Private Google Access from on-premises hosts.

Dedicated Interconnect

  • Dedicated Interconnect provides direct physical connections between the on-premises network and Google’s network.
  • Dedicated Interconnect enables the transfer of large amounts of data between networks, which can be more cost-effective than purchasing additional bandwidth over the public internet.
  • Dedicated Interconnect requires your network to physically meet Google’s network in a colocation facility with your own routing equipment
  • Dedicated Interconnect supports only dynamic routing
  • Dedicate Interconnect supports bandwidth to 10 Gbps minimum to 200 Gbps maximum.
  • VLAN attachment should be associated with a Cloud Router.
  • Cloud Router creates a BGP session for the VLAN attachment and its corresponding on-premises peer router.
  • Cloud Router receives the routes that the on-premises router advertises. These routes are added as custom dynamic routes in the VPC network.
  • Cloud Router also advertises routes for Google Cloud resources to the on-premises peer router.

Google Cloud Dedicated Interconnect

Dedicated Interconnect Provisioning

  • Find a collocation facility with GCP Point of Presence (PoP) which offers Direct Interconnect connections
  • Order an Interconnect connection so that Google can allocate the necessary resources and send a Letter of Authorization and Connecting Facility Assignment (LOA-CFA).
  • LOA-CFA is sent via email to NOC (technical contact) or can be download from the Google Cloud console.
  • Submit the LOA-CFA to the vendor so that they can provision the Interconnect connections between Google’s network and your network.
  • Configure and test the connections with Google before you can use them.
  • Create VLAN attachments to allocate a VLAN on the connection.
  • Configure the on-premises router to establish a BGP session with the Cloud Router

Dedicated Interconnect Redundancy

  • Single Dedicated Interconnect connection does not offer redundancy or high availability
  • Google recommends redundancy using 2 (99.9%) or 4 (99.99%) interconnect connections so that if one connection fails, the other connection can continue to serve traffic
  • Redundant Interconnect connection with 2 connections must be created in the same metropolitan area (city) as the existing one, but in a different edge availability domain (metro availability zone).
  • Redundant Interconnect connection with 4 connections must be created with 2 connections in two different metropolitan areas (city), and each connection in a different edge availability domain (metro availability zone)
  • Dynamic routing mode for the VPC network must be global so that Cloud Router can advertise all subnets and propagate learned routes to all subnets regardless of the subnet’s region.

Google Cloud Dedicated Interconnect Redundancy

Partner Interconnect

  • Partner Interconnect provides connectivity between the on-premises network and the VPC network through a supported service provider
  • A Partner Interconnect connection is useful if the data center is in a physical location that can’t reach a Dedicated Interconnect colocation facility, or the data needs don’t warrant an entire 10-Gbps connection.
  • Partner Interconnect supports bandwidth to 50 Mbps minimum to 10 Gbps maximum.
  • Service providers have existing physical connections to Google’s network that they make available for their customers to use.
  • After the connectivity with a service provider is established, a Partner Interconnect connection from the service provider can be requested.
  • After the service provider provisions the connection, you can start passing traffic between your networks by using the service provider’s network.
  • Partner Interconnect provides Layer 2 and Layer 3 connectivity
    • For Layer 2 connections
      • you must configure and establish a BGP session between the Cloud Routers and on-premises routers for each created VLAN attachment
      • BGP configuration information is provided by the VLAN attachment after your service provider has configured it.
    • For Layer 3 connections
      • The service provider establishes a BGP session between the Cloud Routers and their edge routers for each VLAN attachment.
      • You don’t need to configure BGP on the on-premises router. Google and the service provider automatically set the correct configuration

Google Cloud Partner Interconnect

Partner Interconnect Provisioning

  • Connect the on-premises network to a supported service provider.
  • Create a VLAN attachment for a Partner Interconnect connection in the Google Cloud project, which generates a unique pairing key that must be used to request a connection from the service provider.
  • Activate the connection
  • Depending on the connection, either you or your service provider then establishes a Border Gateway Protocol (BGP) session.
  • Partner Interconnect provisioning does not require LOA-CFA

Partner Interconnect Redundancy

  • Single Partner Interconnect connection does not offer redundancy or high availability
  • 99.9% availability requires
    • At least two VLAN attachments in a single Google Cloud region, in separate edge availability domains (metro availability zones).
    • At least one Cloud Router, connected to both VLAN attachments.
  • 99.99% availability requires
    • At least four VLAN attachments across two metros, one in each edge availability domain (metro availability zone)
    • Two Cloud Routers (one in each Google Cloud region of a VPC network).
    • Associate one Cloud Router with each pair of VLAN attachments.
  • Dynamic routing mode for the VPC network must be global so that Cloud Router can advertise all subnets and propagate learned routes to all subnets regardless of the subnet’s region.

Google Cloud Dedicated Interconnect Redundancy - Layer 2

Cloud Interconnect Security

  • Cloud Interconnect does not encrypt the connection between your network and Google’s network.
  • Currently, Cloud VPN can’t be used with Dedicated Interconnect.
  • For additional security, use application-level encryption or your own VPN.

Dedicated Interconnect vs Partner Interconnect

  • Choosing between Dedicate Interconnect vs Partner Interconnect, consider the connection requirements, such as the connection location and capacity.
    • If you can’t physically meet Google’s network in a colocation facility to reach your VPC networks, you can use Partner Interconnect to connect to service providers that connect directly to Google:
    • If you have high bandwidth needs, Dedicated Interconnect can be a cost-effective solution.
    • If you require a lower bandwidth solution, Dedicated Interconnect and Partner Interconnect provide capacity options starting at 50 Mbps.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company has decided to build a backup replica of their on-premises user authentication PostgreSQL database on Google
    Cloud Platform. The database is 4 TB, and large updates are frequent. Replication requires private address space communication.
    Which networking approach should you use?

    1. Google Cloud Dedicated Interconnect
    2. Google Cloud VPN connected to the data center network
    3. A NAT and TLS translation gateway installed on-premises
    4. A Google Compute Engine instance with a VPN server installed connected to the data center network
  2. A company wants to connect cloud applications to an Oracle database in its data center. Requirements are a maximum of 20 Gbps
    of data and a Service Level Agreement (SLA) of 99%. Which option best suits the requirements?

    1. Implement a high-throughput Cloud VPN connection
    2. Cloud Router with VPN
    3. Dedicated Interconnect
    4. Partner Interconnect
  3. A company wants to connect cloud applications to an Oracle database in its data center. Requirements are a maximum of 9 Gbps
    of data and a Service Level Agreement (SLA) of 99%. Which option best suits the requirements?

    1. Implement a high-throughput Cloud VPN connection
    2. Cloud Router with VPN
    3. Dedicated Interconnect
    4. Partner Interconnect