Last Friday, Squad's Cloud Sec community held its first workshop.
The goal? To set up a Kubernetes cluster with nodes based on VMs hosted by four cloud providers: Azure, AWS, GCP, and IBM. This involved setting up the VPN/network between the cloud providers and then installing K8bs.
There were seven of us experts spread across France: Lyon, Paris, Nantes, and Aix, working together via Teams. We were chosen for our involvement in cloud computing (certification, activity on the internal social network, participation in events, etc.). But there was a twist: each of us worked on a cloud platform we were unfamiliar with. Working alone or in teams of two, everyone set about building the environment.
First challenge: navigating the cloud providers' graphical interface
GCP experts complain about the multiple Azure screens; the resource group's ease of storage/organization does not win them over.
On the AWS side, no one got caught out by the display being limited to the active region (it's always annoying when I use AWS).
The duo working on GCP is doing relatively well with the interface.
IBM offers an interface that is certainly austere but streamlined and intuitive.
The network
We are starting with a star network with Azure centralizing the various connections from other providers. Note that we could have installed a VPN client directly on the VMs, but we chose to use VPN Gateways, which are more representative of a real environment. Despite 10 years of experience with Azure, I discovered that the VPN Gateway is actually called Virtual Network Gateway. The rise of VPNs leads to the exchange of numerous public IPs and will cause a problem that will set us back 30 minutes: a VPN will point to the public IP of a VM instead of the VPN GW, blocking operation. The question of whether or not BGP is necessary, and if so, on which side, also arose. Network engineers are still needed in the cloud, even if their work is largely invisible. They are essential for an organization to ensure that data takes the desired paths.
VM creation
Although this phase is fairly simple, the number of possible configurations/settings on Azure can be a little daunting for those who are not used to it. First-time AWS users encounter difficulties connecting to their first Linux EC2: AWS provides a .pem file .pem file that serves as a key, but it must be converted to .ppk using a specific command in order to be usable in Putty and enable the SSH connection. There is a help page, but it is not exactly intuitive for first-time users. GCP and IBM, on the other hand, do not pose any difficulties in this regard.
Installing Kubernetes and creating the cluster
We used similar Linux distributions, but packaged and, above all, hardened by cloud providers. Installing K8s was quite difficult for some (switching from repo to trusted, rights to be granted). The cluster was set up using the KubAdm package. It is relatively easy to use and allows nodes to be joined to a cluster with a single command (admittedly quite long). We did not use AKS, EKS, or other solutions to become independent from the cloud provider so that we could theoretically switch a pod from one CSP to another. (In four hours, we were unable to simulate the switch to see the network impact in particular).
Anecdote about IBM Cloud
I worked for a company that used IBM Cloud Private about ten years ago, and the service didn't meet the expected level of quality in terms of performance/elasticity (it has since closed down). As a result, I was left with a poor impression of IBM Cloud products, but the interface and results of IBM Cloud Public, which I tested this afternoon, are very promising. It's worth noting that a carbon footprint calculator is available directly in the interface (the origin of the data and the calculation method used should be checked), but it's a good idea to make it available to OPS (as well as the cost section), as it allows users to see their consumption and try to be mindful of it. This just goes to show that you shouldn't jump to negative conclusions and should always be willing to try things out!
My feedback: a really enjoyable exercise!
As is often the case, the right tools are essential:
- Team rooms are a major step forward, with the ability to split a meeting into several smaller ones, as this makes it easier for people to work as a team. A shared table must be prepared in advance in order to enter the information to be shared (IP, passphrase, key, etc.) to avoid any misunderstandings.
- Ensure that cloud providers' subscriptions are ready in advance so that participants can quickly get started. For the fourth cloud provider, I had chosen Ali Baba because of their large market share, but after opening the account, the interface did not seem to be fully translated and contained elements in Chinese. I therefore decided to go with IBM as the fourth provider.
Although they offer similar services, cloud providers have their own specific features. To simplify the workshop, I had managed the IAM part before it began. Mastering several cloud providers in terms of architecture/security is not something that can be done in a few months.
Preparing and running this workshop was a pleasure. It helps to resolve one of the biggest drawbacks of consulting work, which is the lack of connection between colleagues who work on similar topics but with different clients. This type of exercise allows us to meet, exchange ideas, and progress, all in a positive atmosphere. Hearing two consultants who have probably never met before say, "You can send me your orders so I can look at them later," is the best proof of success!
Matthew GAILLARD-MIDOL
Cloud Security Practice Leader
