Start preparing for your Next Exam | Use coupon – TOGETHER | Avail 30% discount

Integration with external systems

  1. Home
  3. Integration with external systems

Go back to GCP Tutorials

In this tutorial we will understand about integration with external systems.

Connecting Amazon VPC to your Google Cloud virtual network

To establish the Amazon VPC, follow the instructions in Using Cloud VPN with Amazon Web Services, in the sections “Policy Based IPsec VPN: Configuration – AWS” and “Policy Based IPsec VPN: Configuration – GCP UI.”

  • Firstly, use the default VPC with the network address 172.31.0.0/16 CIDR.
  • Secondly, use the default subnet with the network address 172.31.0.0/16 CIDR.
  • Then, create a VPN connection with AWS using the static IP address aws-vpn as a Compute Engine VPN gateway.

However, you use IPsec VPN to connect Amazon VPC to the Google Cloud virtual network that you create in Google Cloud.

gcloud

  • Firstly, open Cloud Shell: ACTIVATE Cloud Shell
  • Secondly, create a Google Cloud virtual network:
    • gcloud compute networks create “aws-vpn” –subnet-mode “auto”
    • gcloud compute addresses create “aws-vpn” –region “asia-east1”
  • Thirdly, follow the instructions in Using Cloud VPN with Amazon Web Services.
  • Lastly, to show the VPN configuration in the Cloud Console, open the VPN page.

Configuring the Amazon VPC routing table

To enable the Amazon EC2 instances to access the Google Cloud virtual network in your project, follow these steps:

  • Firstly, in the AWS Management Console, click the Route Table tab.
  • Secondly, select Route Propagation and click Edit.
  • Lastly, select Propagate in your VPC network private IP range, and then click Save.

Configuring firewall rules

The next step is to add firewall rules that allow the proxy connection from Amazon VPC, and an SSH connection from all external networks. The SSH connection is used only for configuring the HTTP or HTTPS proxy instance. However, to configure the proxy without manually signing in to the instance, you can use a startup script. In this case you don’t need to create the firewall rule for the SSH connection.

gcloud

  • Firstly, in Cloud Shell, add a firewall rule for the proxy:

gcloud compute firewall-rules create “aws-vpn-allow-proxy” \
–description “Allow Google private access from AWS VPC” \
–network “aws-vpn” –allow tcp:8118 \
–source-ranges “172.31.0.0/16” –target-tags “api-proxy”

And, when the firewall rule is created, the following output appears:

Creating firewall…done.
NAME NETWORK SRC_RANGES RULES SRC_TAGS TARGET_TAGS
aws-vpn-allow-proxy aws-vpn 172.31.0.0/16 tcp:8118 api-proxy

  • Secondly, if you’re not using a startup script, add a firewall rule for the SSH connection:

gcloud compute firewall-rules create “aws-vpn-allow-ssh” \
–description “Allow SSH from anywhere” \
–network “aws-vpn” –allow tcp:22 –source-ranges “0.0.0.0/0”

And, when the firewall rule is created, the following output appears:

Creating firewall…done.
NAME NETWORK SRC_RANGES RULES SRC_TAGS TARGET_TAGS
aws-vpn-allow-ssh aws-vpn 0.0.0.0/0 tcp:22

Removing an external IP address from the proxy instance

You must prevent the proxy instance from accidentally using a public IP address to reach Google Cloud APIs.

gcloud

  • Firstly, determine the configuration name:

gcloud compute instances describe api-proxy | grep -A5 accessConfigs

In the following example output, the configuration name for the external IP address is external-nat.

accessConfigs:

kind: compute#accessConfig
name: external-nat
natIP: 104.199.157.31
type: ONE_TO_ONE_NAT
kind: compute#networkInterface

  • Secondly, remove the external IP address, specifying the configuration name from the previous step.

gcloud compute instances delete-access-config api-proxy –access-config-name “external-nat”

gcp cloud architect practice tests

Manage risk with controls

Prior to creating and deploying resources on Google Cloud, assess the security features you need to meet your internal security requirements and external regulatory requirements. However, three control areas focus on mitigating risk are:

  • Firstly, technical controls refer to the features and technologies that you use to protect your environment. These include native cloud security controls, such as firewalls and enabling logging, and can also encompass third-party tools and vendors to reinforce or support your security strategy.
  • Secondly, Contractual protections refer to the legal commitments made by the cloud vendor around Google Cloud services.
  • Lastly, third-party verifications or attestations refer to having a third party audit the cloud provider to ensure that the provider meets compliance requirements. For example, Google was audited by a third party for ISO 27017 compliance.

Technical controls

We start from the fundamental premise that Google Cloud customers own their data and control how it is used. The data a customer stores and manages on Google Cloud systems is only used to provide that customer with Google Cloud services and to make those services work better for them. Further, we have robust internal controls and auditing to protect against insider access to customer data.

Contractual controls

Google Cloud is committed to maintaining and expanding our compliance portfolio. The Data Processing and Security Terms (DPST) document defines our commitment to maintaining our ISO 27001, 27017, 27018 certifications. And also updating our SOC 2 and SOC 3 reports every 12 months. Further, the DPST also outlines the access controls in place to limit Google support engineers’ access to customers’ environments.

Implement compute security controls

It is always a best practice to secure how you expose your resources to the network. Here are controls availabe in Google Kubernetes Engine (GKE) and Compute Engine.

Private IPs
You can disable External IP access to your production VMs using organization policies. Moreover, you can deploy private clusters with Private IPs within GKE to limit possible network attacks.

Compute instance usage
It’s also important to know who can spin up instances and access control using IAM because you can incur significant cost if there is a break-in. Further, Google Cloud lets you define custom quotas on projects to limit such activity.

Compute OS images
Google provides you with curated OS images that are maintained and patched regularly. Although you can bring your own custom images and run them on Compute Engine, you still have to patch, update, and maintain them.

GKE and Docker
App Engine flexible runs application instances within Docker containers, letting you run any runtime. You can also enable SSH access to the underlying instances, we do not recommend this unless you have a valid business use case. Further, to provide infrastructure security for your cluster, GKE provides the ability to use IAM with role-based access control (RBAC) to manage access to your cluster and namespaces.

Runtime security
GKE integrates with various partner solutions for runtime security to provide you with robust solutions to monitor and manage your deployment. However, all these solutions can be built to integrate with Security Command Center, providing you with a single pane of glass.

Partner solutions for host-protection
In addition to using curated hardened OS images provided by Google, you can use various Google Cloud partner solutions for host protection. Most partner solutions offered on Google Cloud integrate with Security Command Center, from where you can go to the partner portal for advanced threat analysis or extra runtime security.

Integration with external systems GCP cloud architect online course

Reference: Google Documentation, Documentation 2

Go back to GCP Tutorials

Menu