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 the complexity introduced by using multiple cloud providers. 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.” We can apply this concept to security.What is Cloud Agnostic Security?
Cloud agnostic security is the strategy of applying security controls consistently across multiple cloud providers without using platform-specific solutions. This allows an organization to define and implement high-level security requirements without concerning themselves with the nuances of each cloud provider. For example, a cloud agnostic security tool would allow the organization to block access relational databases in AWS, Azure, and Google Cloud without needing to know how to accomplish this in both Amazon RDS, Azure Database, or Google Cloud SQL.
The software most commonly described as cloud agnostic is Kubernetes. I delivered a separate presentation on cloud agnostic security and its relationship to Kubernetes at RSA Conference 2023. In this blog, we will discuss a different “cloud-agnostic” tool, Terraform. With Terraform, you can define cloud infrastructure as code for many different cloud providers and automate the creation of that infrastructure in real environments. Security engineers find Terraform and similar tools invaluable because they are used to codify cloud security configuration as well. Security can work with developers to write the security configuration once, deploy it many times, and confidently tell auditors that the code matches the reality of the environments.
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: Cloud Security Controls and Mitigations, uses thousands of lines of Terraform code to deploy hundreds of resources to the Big 3 cloud providers. Because Terraform supports these cloud providers and much more, many security professionals erroneously believe that their organization can produce a single set of Terraform code to configure them all 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 of revenue in their "Intelligent Cloud" segment (which includes Azure along with many other services). 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
On May 10, 2023, I discussed these concepts and more in this webcast, 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: Cloud Security Controls and Mitigations, which heavily features Terraform.
If you are interested to learn if SEC510: Cloud Security Controls and Mitigations is right for you, make sure to enroll in our free course demo!
About the Author
Brandon Evans is the owner and an InfoSec Consultant at On-Brand Technologies LLC, a consultancy helping organizations secure their applications and other workloads in multi cloud environments, specializing in AWS, Azure, and Google Cloud. Prior to starting his consultancy, Brandon led the secure development training program at Zoom Video Communications. He began his career as a Software Engineer, where he worked on both the core product of a startup, later acquired by a Fortune 500 organization, and on various products spanning a multi-billion dollar enterprise. Brandon is lead author for SEC510: Cloud Security Controls and Mitigations a contributor to SEC540: Cloud Security and DevSecOps Automation, host of Cloud Ace podcast, Season 1, an analyst for the SANS Multicloud Survey, and a multi-year RSA Conference presenter. Read more about Brandon.
