A media and legal battle for the control and security of the personal data of European citizens has continued to grow since the start of the health crisis.

Many European companies storing personal data in their private data centers wish to benefit from the strength of the public cloud but find themselves confronted with human, cultural and sometimes legal conflicts over the choice between an American cloud leader and a European pure player cloud.

In this long series of posts, I invite you to discover how to find inner peace by building a multi-cloud environment 🇪🇺 🇺🇸 step by step. Keep personal data in a European cloud and entrust the operational part to an American cloud leader.

A complete proof of concept is included in this series.

Why multi-cloud ?

Enterprises embrace multi-cloud. 93 percent of enterprises have a multi-cloud setup; 87 percent have a hybrid cloud strategy [1]

There are many motivations that lead companies to choose the multi-cloud option in their organization, among them:

• Risk reduction (e.g: Vendor lock-in). Minimizing perceived risk by using more than one cloud provider.
• Architectural similarity. Reflecting technology stacks of different divisions or departments.
• Feature availability. Taking advantage of the best service and feature. [3]
• Privacy regulations and security (e.g: Sovereignty, Data localisation)
• High availability.
• Disaster recovery.

But also:

• Excessive vendor influence.
• Huge credits...

Whatever the motivations, we must first think about the answers to these questions:

• Which workloads should be run in to each cloud ?
• Which patterns to apply across multiple workloads ?
• Which technology and network topology to use ? [4]

Architecture Option

6 multi-cloud architecture options are proposed by Gregor Hohpe and well explained in his blog post [2]:

As we aim to separate operational workloads from business workloads, we will choose a Segmented Architecture.

In our case, we will have private workloads in Scaleway Elements and internet facing + operational workloads in Google Cloud.

By private workloads, I mean:

• Compute
• Database
• Storage
• Encryption
• etc.

By internet facing and operational workloads, I see:

• DevOps Platform
• CDN
• Load Balancers
• External IP Address
• DNS
• DDoS
• Disaster Recovery
• Firewall
• etc.

Let's see what kind of cloud architectures we can build with the strength of both.

Network

When a network connection is established between both cloud providers using VPN as an example, each Cloud will treat the other as an on-premise environment. Neither GCP nor Scaleway will be aware of being part of a multi-cloud architecture but will know that they are in a hybrid cloud architecture.

This is the reason why Google Cloud describes multi-cloud as it describes hybrid cloud. [4]

VPC connectivity

In my last post, I talked about the best network topology suited for a hybrid cloud which is hub-and-spoke topology. Let's see how we can architecture that for a multi-cloud:

• A VPN connection is established between both side, ensuring private communication.
• Scaleway Private Network and GCP hub VPC are both isolated from public internet thanks to security groups and firewall rules.
• A DNS resolution can also be configured between both.
• If a GCP project is attached to the Spoke Shared VPC, it will automatically have an access to Scaleway workloads thanks to VPC peering exchange custom routes between hub and spokes.
• An organisation policy compute.restrictVpnPeerIPs could be added in the Hub project to restrict the VPN Peer IP to Scaleway reserved IP addresses.

Internet facing

It's possible in Google Cloud to terminate user requests in front of a custom origin. With this option we can create a Load Balancer in GCP on top of Scaleway.[5]

• The communication between both is done by HTTPS,
• An external HTTPS Load balancer is created in Google Cloud and it will behave as a proxy. The backend service has internet NEG (Network Endpoint Groups) configured as a backend,
• The Scaleway endpoint is defined in the internet NEG.
• The Cloud CDN and Cloud Armor could be added to protect against DDoS attacks.

Workloads and communication

If we consider some applications as non sensitives like front-end apps we can deploy them in Google Cloud and keep the sensitives apps in Scaleway.

• The sensitive application is protected behind a VPN,
• The non sensitive application deployed in Compute Engine as an example has access to the sensitive application in Scaleway using an Internal HTTPS Load Balancer [6],
• Since the front-end app resides in Google Cloud, we can use all GCP services that help protect internet facing apps.

SecOps

We started by the different network architectures that we could implement between both providers. Now we will see what security architectures we can choose to protect user datas.

Zero Trust

Zero Trust approach can be used in Google Cloud to access the internal applications hosted in Scaleway. In Google Cloud this can be achieved using Identity Aware Proxy (IAP). [7]

• Cloud Identity is synchronized with an Azure AD tenant.
• IAP is enabled in the HTTPS Load Balancer.
• Just like the internet facing architecture explained previously, the Load balancer behaves like a proxy and the backend services has internet NEG configured as a backend,
• The Scaleway endpoint is defined in the internet NEG.
• To avoid bypassing IAP, a IAP JWT header is included in the HTTPS requests. The JWT header is verified in Scaleway side.

Access Keys Management

To deploy Scaleway resources from a DevOps platform built in Google Cloud we will need to manage Scaleway credentials.

An access keys management that I usually recommend to customers is creating 2 access keys types:

• credentials deployer used by CI/CD tool to deploy resources,
• credentials user used by applications to access resources.

In the context of a multi-cloud we can manage those credentials in an open source tool like Vault.

The following diagram illustrate that usage:

• We use Gitlab as an example of CI/CD tool,
• Gitlab Specific runners are registered in a Google Kubernetes Engine Cluster,
• Each job ran by a Gitlab runner has an attached Kubernetes Service Account (KSA) which is authenticated in Vault [8] and can deploy Scaleway resources.
• As a VPN connection is established between providers, the resources deployed in Scaleway Kapsule Cluster have an internal network access to vault and can authenticate just as Gitlab runner jobs do.

Cryptographic Keys Management

Google Cloud supports Customer-Supplied Encryption Keys (CSEK) [9]. We can supply the encryption keys hosted in Scaleway to Google Cloud. Google will use those keys to protect the Google-generated keys used to encrypt and decrypt datas.

• A Cloud HSM cluster is deployed in Scaleway and is based on GnuPG.
• The GnuPG private keys are accessible internally to Google Cloud thanks to the VPN connection.
• A VPC Service Control and a Private Google Access are added to secure the communication between Scaleway and Cloud KMS APIs.

Data Loss Prevention

We can use DLP service of Google Cloud to anonymize our datas stored in Scaleway.

• A DLP Client is deployed in Scaleway,
• DLP Client sends requests to DLP API through the secured VPN connection,
• The datas are processed in memory, not persisted and the result is returned directly in API response,
• Also here VPC Service Control and a Private Google Access are added to secure the communication between Scaleway and Cloud DLP APIs.

Disaster recovery

Choosing multi-cloud for disaster recovery is very common.

The following diagram describes a "Backup & Restore" service level:

• The datas are encrypted in Scaleway,
• A backup instance in Scaleway creates a snapshot from the datas without decryption,
• The snapshot is sent to Google Cloud through VPN tunnel,
• Again, VPC Service Control and a Private Google Access are added to secure the communication between Scaleway and Cloud Storage APIs.

Conclusion

In this part we saw how to build a network infrastructure and implementing security patterns between Scaleway Elements and Google Cloud.

There are other patterns that I would have liked to present but the architectures are not drawn yet.

What's next ?

In the second part, we will discuss about monitoring/logging and DevOps architectures that could be applied between the two cloud providers. We will also start to architecture our proof of concept.

Documentation

[1] https://www.flexera.com/blog/industry-trends/trend-of-cloud-computing-2020/
[2] https://architectelevator.com/cloud/hybrid-multi-cloud/
[3] https://www.cloudtp.com/doppler/hybrid-cloud-vs-multi-cloud-whats-difference-matter/
[4] https://cloud.google.com/solutions/hybrid-and-multi-cloud-patterns-and-practices
[5] https://cloud.google.com/load-balancing/docs/https/setting-up-https-custom-origin
[6] https://cloud.google.com/load-balancing/docs/internal/internal-tcp-udp-lb-and-other-networks
[7] https://cloud.google.com/iap/docs/enabling-on-prem-howto
[8] https://www.vaultproject.io/docs/auth/kubernetes
[9] https://cloud.google.com/storage/docs/encryption/customer-supplied-keys