The movement towards multi cloud security has been growing momentum with no end in sight. Over 50% of the respondents to the SANS 2022 Multicloud Survey not only use all of the Big 3 Cloud Providers (Amazon Web Services, Azure, and Google Cloud), but they also use all of the next three most popular CSPs (Alibaba Cloud, Oracle Cloud, and IBM Cloud). The workforce has not kept up with this. Forbes wrote in late 2022 about the multicloud security skill shortage, stating, “AWS, Azure and GCP don’t handle basic security functions...in exactly the same way. There are nuances that must be taken into account in order for security measures to work properly…The professionals who understand these nuances are not easy to find.”
Multi Cloud Security Strategy
Organizations look to so-called “cloud-agnostic” technologies to manage this complexity. VMware states that cloud agnosticism, “…refers to a cloud design strategy in which applications, tools, and services are designed to migrate seamlessly between multiple cloud platforms or between on-premises and cloud in a hybrid model without disruption of service.” The software most commonly associated with this concept is Kubernetes. I will be giving a separate presentation at RSA Conference 2023 on cloud agnosticism and Kubernetes.
In this blog, we will discuss a different “cloud-agnostic” tool, Terraform. With Terraform, you can define cloud infrastructure as code and deploy it for many different cloud providers. Terraform is very popular both in the industry and here at SANS. Many of our courses use Terraform to build our lab environments. My course, SEC510: Public Cloud Security: AWS, Azure, and GCP, uses thousands of lines of Terraform code to deploy hundreds of resources to the Big 3 cloud providers. Because Terraform supports these providers and much more, many security professionals erroneously believe that their organization can produce a single set of Terraform code and configure them securely.
Cloud Agnostic Security Challenges
Unfortunately, Terraform does not simplify multicloud security significantly. To understand why this, let us analyze some code snippets. Imagine that you want to create and configure a storage bucket in each of the Big 3 providers. In AWS, the bucket will be created in the Simple Storage Service (S3). In Azure, it will be in Azure Storage. Finally, in Google Cloud, it will be in Google Cloud Storage. You might assume that you can accomplish this with a simple block of HCL like so:
Figure 1: A single block of HCL that seeks to create a private storage bucket in each of the Big 3 clouds.
Here is what a real code snippet for this task would look like:
Figure 2: A much longer block of code that is actually operable.
While the tool and its associated configuration language, HashiCorp Language (HCL), can be called cloud-agnostic, the providers that it uses are cloud-specific. Each Terraform provider integrates with the associated proprietary cloud API. They do not and cannot configure multiple cloud providers. This is partly because security concepts are inconsistent between the providers.
Multicloud IAM Security
This is especially clear when looking at cloud Identity and Access Management (IAM). Here are the evaluation logic workflow diagrams for each cloud provider. There is no way to neatly map these workflows one-to-one:
Figure 3: AWS IAM Policy Evaluation Logic Flow Chart
Figure 4: Azure Role-Based Access Control (RBAC) Evaluation Logic
Figure 5: Google Cloud Policy Evaluation
Public Cloud Provider Incentives
This is not a purely technical issue, but also a business matter. Like many platforms, the cloud providers benefit from vendor lock-in. If there was a tool that could be used to configure all three providers consistently, it would be much easier to migrate from one to another. This would allow organizations to shop around for the best service and price to suit their needs. Thus, the cloud providers would struggle to retain their customers.
Currently, despite the multicloud movement, AWS and Azure are far and away the most financially successful cloud providers. In 2022, AWS reportedly generated $80 billion USD of revenue, while Azure reportedly generated $75.3 billion. Their closest competitor, Google Cloud, reportedly generated $26.28 billion. AWS, and to a lesser extent, Azure, captured the public cloud market early on. Because of their popularity, internal, vendor, and open-source technologies were created that integrated with AWS and Azure’s proprietary APIs. If an organization chose to use an alternative cloud provider, they would forfeit the ability to use these tools. As such, they often choose the “safer option” of either AWS or Azure, even if they believe another cloud provider is superior. This creates a snowball effect: just like a snowball picks up more snow as it rolls down a hill, the cloud providers become more popular as more people use them.
Cloud agnosticism threatens this competitive advantage. If every cloud API was compatible with one another, then all the aforementioned tools would work with each provider. This would eliminate popularity as a reason for choosing a particular platform. So, it is reasonable to believe that the most popular cloud providers are happy that Terraform works the way it does.
Theoretically, it is possible that a highly skilled development team could create a generic Terraform cloud provider. Perhaps this provider works well enough to function despite not perfectly mapping security concepts to one another. If I was a leader at AWS or Azure and found such a Terraform provider, I would make sure to introduce backwards incompatible changes to the APIs to break this abstraction and lock customers in. While I cannot speak for either organization, I think this would be a reasonable business decision.
Learning More
I will be discussing these concepts, and more, in an upcoming webcast on 5/10/23, The Myth of Cloud Agnosticism: Why Securing Multiple Clouds Using Terraform is Harder Than You Think. Coincidentally, 5/10 matches the number for my course, SEC510: Public Cloud Security: AWS, Azure, and GCP, which heavily features Terraform. I hope you will join me for this webcast and one of the many SEC510 sessions we have scheduled for this year! If you are interested to learn if SEC510 is right for you, make sure to enroll in our free course demo!
About the Author
Brandon Evans helps organizations secure their applications and other workloads in cloud environments, specializing in AWS, Azure, and Google Cloud. Brandon is lead author for SEC510: Public Cloud Security: AWS, Azure, and GCP, a contributor for SEC540: Cloud Security and DevSecOps Automation, and host of the SANS Cloud Ace podcast, Season 1. Prior to becoming an independent consultant, he led Zoom's secure development training program, managed its implementation, and measured its outcomes, bringing it to the industry standard as assessed by the Building Security In Maturity Model (BSIMM). Brandon holds a bachelor’s in computer science from Binghamton University, has earned seven GIAC certifications, and holds the AWS Certified Security - Specialty certification. Read more about Brandon.
This blog post and the upcoming webcast is related to Brandon’s RSA Conference 2023 presentation, "Cloud Agnostic or Devout? How Cloud Native Security Differs Between EKS, AKS, and GKE”. Readers interested in the topics covered in this blog post will likely be interested in this presentation.
