gcp

Recently, I worked on a project on which we need to access privately to CloudSQL instance (PostgreSQL instance in our case). In this article, we will explore two options to do so. However, you can use the same technique for other types of CloudSQL (SQL Server or MySQL).

By default, a single filestore instance cannot be shared across multiple pods in GCP. However, there is a technique that can help you enable this functionality by using an external NFS provisioner. The latter separates the PVC of each application by using a subdirectory.

In this article, we discuss an important part of GCP: IAM or Identity and Access Management.

Before going into details, let’s take a quick look at IAM Hierarchy.

As you can see, IAM includes some basic objects at each level: organization, folders, projects and resources. GCP allows you to set IAM policies at any of these levels.

Understanding these IAM objects and how to set IAM at the corresponding level will help you to design your solution following Google’s recommended best practices.

In GCP, you have two options for sharing networks across GCP projects: Shared VPC and VPC Network Peering.

In this article, we discuss more detail its features and how to implement them.

Shared VPC overview

• Shared VPC is a centralized approach to multi-project networking allowing an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network, so that they can communicate with each other securely and efficiently using internal IPs from that network.
• When you use Shared VPC, you designate a project as a host project and attach one or more other service projects to it
• Shared VPC network is created and managed by a Shared VPC Admin which is nominated by an Organization Admin
• Shared VPC Admin is responsible to enable shared vpc feature on the host project and attach service projects to the host project. He can also delegate access to some or all subnets in the shared VPC network by granting the compute.networkUser role for Service Project Admins at the project level or the subnet level
• Service Project Admins in his turn maintain ownership and control over resources defined in their service projects. They could create and manage resources (vm instances, instance templates, instance groups, static internal ip, load balancers) in the shared VPC.

As you know in the previous article, we could take advantage of Cloud NAT to go to the Internet without an external IP.

But the NAT gateway created in one VPC network cannot provide NAT to VMs in other VPC networks connected by using VPC Network Peering, even if the VMs in peered networks are in the same region as the gateway.

So, how we can use Cloud NAT in case of we have some VPC networks ? I will explain to you in this article.

This is the third part of GCP’s series. In the first article, you have seen that a virtual machine needs to have an external IP to reach out to the services outside of the VPC in which it is deployed.

Topics to cover:

• Private Google Access
• Cloud NAT

This is the second part of GCP’s series. In the previous article we covered some basic terminology in GCP.

As you know, each virtual machine created has an internal IP assigned. From the same network, you can reach out to this vm using it’s internal IP or it’s internal DNS.

This is the first part of GCP’s series. In this article, you will familiar with some of the basic terminology used in Google Cloud Platform (GCP).

Topics to cover:

• Google Cloud
• Projects and networks
• Internal IP and External IP
• DNS resolution for internal IP
• DNS resolution for external IP
• Cloud DNS
• Firewall
• Route