terraform

In this article, we walk through how to create a Kubernetes cluster on a cloud provider (AKS, GKE) using Terraform. Next, we deploy this cluster through a CI/CD pipeline (Azure DevOps Pipeline and Github Action).

On the first project, we deploy our cluster to AKS through Azure DevOps pipeline.

On the second project, we will use Github action as our CI/CD and we will create a GKE cluster.

The choice of tool is indicatif. You can choose which one which is the best fit for your case/business.

In the previous article (part 2), we talk about the Site-to-Site VPN with active/passive configuration.

Now, we configure our Site-to-Site VPN with active/active configuration using BGP (Border Gateway Protocol).

In the end, we will take a quick look at Azure ExpressRoute.

In the previous article (part 1), we talk about the Point-to-Site VPN. It’s great when you want to connect to Azure from your local computer.

In the real world, you may want to connect your entire on-premises networks to Azure or connect multiple virtual networks in Azure together. In this case, you may consider using the Site-to-Site VPN or the Vnet-to-Vnet connection.

Part 3 (S2S VPN with High Availability) available here.

A virtual private network (VPN) is a type of private interconnected network.

VPNs are typically deployed to connect two or more trusted private networks to one another over an untrusted network (over the Internet).

Traffic is encrypted while traveling over the untrusted network to prevent eavesdropping or other attacks.

You may consider three types of gateway below when designing your hybrid network:

• Point-to-site (P2S) VPN: allows client computers in local to connect remotely to your network in Azure using IPSec/OpenVPN/SSTP protocols
• Site-to-site (S2S) VPN: connect your on-premises networks to Azure through dedicated VPN devices or connect multiple virtual networks in Azure together. Protocols supported: IPSec/IKE
• Azure ExpressRoute: connect your on-premises networks to Azure over a private network. It means that your traffic will be not travel over the Internet.

In this first part, we will discuss the Point-to-Site VPN.

Part 2 (Site-to-Site VPN) available here.

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.

In contrast of Google Cloud Platform, Azure Virtual Machine has access to the Internet by default (even if your vm doesn’t have a public ip). You don’t need to do anything to have internet access.

But what if you would like to control the web traffic (http/https) to the internet from your virtual networks (due to the company’s policy for example). You may need to establish a single access point to the internet on which you could control the outbound access.

In the previous article, we discussed the Hub-Spoke Topology. We will expand this architecture to cover our topic today.

Our architecture modified:

As you saw in the previous architecture, we have three virtual networks:

• Hub virtual network (hub-vnet): region France Central
• Spoke 1 virtual network (finance-vnet): region West Europe
• Spoke 2 virtual network (it-vnet): region North Europe

We need to control the web traffic from all spoke networks to the Internet .

We will add a new virtual network:

• Proxyout virtual network (proxyout-vnet): region France Central

On this new virtual network, we place two virtual machines (proxyout) behind a Azure Load Balancer Standard to receive/control the web traffic (http/https) from other spoke networks. You could install a middleware (squid) to allow/deny the access.

So, our architecture will be the following:

Today, we will implement a hub-spoke topology in Azure.

The hub is a virtual network in Azure that acts as a central point of connectivity to your on-premises network.

The spokes are virtual networks that peer with the hub and can be used to isolate workloads.

For more information, we refer to this document.

In our case-study, we don’t have on-premises network, so the architecture will be adjusted a little bit: