What Is Infrastructure as Code (IaC) Security?
SHARE:
Infrastructure-as-Code, or IaC, has become a core component of IT provisioning and administration strategies across environments of all types. Whether you run applications in the cloud, on-premises, or a combination thereof, IaC is critical for automating infrastructure setup and application deployment at scale.
But despite all the benefits of IaC, you’ll shoot yourself in the foot if you don’t address the security risks that accompany IaC. Indeed, because IaC deploys configurations across large environments with minimal human oversight, IaC security problems can easily become widespread security issues within your environment as a whole.
This article walks through everything you need to know about IaC security. It explains how IaC security risks arise, how they can spread to production systems when IaC templates are used to provision environments, and which tools and practices teams can use to mitigate IaC security threats.
What is IaC?
What you’ll learn
-
First off: What is Infrastructure as Code?
-
The benefits - and risks - of IaC
-
Some best practices for securing your IaC
What Is IaC?
To understand IaC security, you must first understand how IaC works.
Put simply, IaC is an approach to setting up IT environments in which engineers write machine-readable policy files that define how resources should be configured, as opposed to configuring each resource manually. Those resources could be virtually any type of IT asset – a bare-metal server, a virtual machine, a local file system, an object storage bucket in the cloud, local or cloud-based applications, and so on.
Because IaC makes it possible to apply a single configuration across hundreds or thousands of resources in a fully automated way, IaC plays a central role in helping teams configure IT environments at scale. IaC also ensures that resources are configured consistently, because the configurations applied to each resource will be identical as long as they are based on the same policy file.
These benefits, among others, have led to widespread adoption of IaC over the past decade. Particularly in complex environments that span multiple clouds, or that include hundreds or thousands of individual resources, it simply wouldn’t be feasible to configure each one manually. This means that, in many modern environments, IaC is not just a nice-to-have methodology, but an absolutely essential component of IT provisioning and administration.
There are a variety of IaC frameworks available. Some work only with certain types of environments, such as a particular public cloud. Others are environment-agnostic and can be used almost anywhere. From the perspective of IaC security, however, there are no major differences between the various IaC frameworks.
IaC Security Risks
From a security perspective, IaC is something of a double-edged sword.
On the one hand, IaC offers inherent security benefits in the sense that it mitigates the risk of introducing security misconfigurations into IT environments due to human error. In other words, it eliminates the need to worry that an engineer who configures resources manually will forget to apply an important security setting or give the wrong user access, for example.
On the other hand, IaC poses a significant security risk in that security problems within IaC policy files will affect any resources that are configured using those files. This means that a security issue in just one file can become a risk that spreads to hundreds or thousands of resources in a single go.
As an example of an IaC security risk, consider the following IaC template, which can be used with CloudFormation (the Amazon cloud’s native IaC framework) to set up an AWS S3 object storage bucket:
{
"Type" : "AWS::S3::Bucket",
"Properties" : {
"AccelerateConfiguration" : AccelerateConfiguration,
"AccessControl" : String,
"AnalyticsConfigurations" : [ AnalyticsConfiguration, ... ],
"BucketEncryption" : BucketEcryption,
"BucketName" : String,
"CorsConfiguration" : CorsConfiguration,
"IntelligentTieringConfigurations" : [ IntelligentTieringConfiguration, ... ],
"InventoryConfigurations" : [ InventoryConfiguration, ... ],
"LifecycleConfiguration" : LifecycleConfiguration,
"LoggingConfiguration" : LoggingConfiguration,
"MetricsConfigurations" : [ MetricsConfiguration, ... ],
"NotificationConfiguration" : NotificationConfiguration,
"ObjectLockConfiguration" : ObjectLockConfiguration,
"ObjectLockEnabled" : Boolean,
"OwnershipControls" : OwnershipControls,
"PublicAccessBlockConfiguration" : PublicAccessBlockConfiguration,
"ReplicationConfiguration" : ReplicationConfiguration,
"Tags" : [ Tag, ... ],
"VersioningConfiguration" : VersioningConfiguration,
"WebsiteConfiguration" : WebsiteConfiguration
}
}Code language: JSON / JSON with Comments (json)In most respects, this is a secure template. But it contains one small, yet potentially significant mistake. There is a typo in the following parameter:
"BucketEcryption" : BucketEcryption,Code language: JavaScript (javascript)Notice that the word “Encryption” is missing an “n.” As a result, the setting won’t be properly recognized by CloudFormation when the template is applied.
Because this parameter is used to enforce configuration by default for data stored in the S3 buckets that this template sets up, this small error means that the S3 data won’t be encrypted. Engineers who use this template to configure cloud storage on AWS may therefore believe that their data is being encrypted by default, even though it is not. If they use this template to set up dozens or hundreds of storage buckets, the security risk will be present in each one.
Note, too, that it’s not just typos that can lead to IaC security risks. Engineers may also forget to apply certain configurations; for instance, the IaC template above doesn’t include parameters to block public access to the S3 bucket. While this isn’t necessarily insecure, it could be a security issue if the data stored in the S3 bucket shouldn’t be publicly viewable.
What Is IaC Security?
The solution to remediating risks like these is IaC security. IaC security is the tools and practices that allow engineers to find and remediate security problems within IaC templates.
Let’s break down IaC security into those two key components – tools and practices.
IaC Security Tools
IaC security tools consist of configuration auditors that can scan IaC templates and identify security risks – such as the typo described above, or the absence of settings that may be important from a security perspective – before the templates are used to provision resources.
While there is no guarantee that these tools can detect every type of security risk within IaC files, they can significantly reduce the chances of introducing security problems into production environments using IaC.
IaC Security Practices
IaC security practices define the processes that engineers should use to minimize the risk of introducing security problems when creating or applying IaC templates. Thus, you can think of IaC security practices as a form of IT governance designed to mitigate security risks associated with IaC.
Best Practices for IaC Security
No matter which IaC framework you use, or which types of resources you configure with it, there are several steps you can take to mitigate security risks associated with IaC.
Scan Your Templates
Probably the single most important step you can take to address IaC security risks is to scan IaC templates before they are applied. As explained above, IaC scanning can detect oversights or mistakes that may lead to security breaches.
Scan Your Production Systems
A limitation of IaC scanning is that it assesses security configurations generically, based on settings in IaC templates that may be applied to any number of individual resources. As a result, IaC scanning can’t detect security risks that may exist within the settings applied to specific, individual resources after they have been configured using IaC.
For instance, one storage bucket may have different security requirements than another. If both buckets are created using the same IaC template, scanning the template is of limited effectiveness for ensuring that each bucket is properly configured from a security perspective.
For this reason, you should also scan the actual configurations within your production environments after they have been set up and deployed. Advanced configuration auditing tools can assess each resource’s configuration on a granular basis and alert you to potential risks.
Use Secure Templates
You can reduce the risk of security issues by creating a core set of templates that you carefully vet for security, then using those as the foundation for creating new templates. This approach is more secure than creating each new template from scratch (or basing them on templates that you find on the Internet, which is equally problematic because those templates may not be vetted from a security perspective), which increases the risk of oversights that cause security problems.
Define Default IaC Security Settings
Consider setting rules about key security parameters that need to be included in IaC templates by default. For example, your team could be required to abide by a rule that requires data to be encrypted by default in any IaC file that is used to configure data storage resources.
Define Who Can Create and Apply Templates
IaC is relatively easy to use; anyone with basic scripting knowledge can create and apply IaC templates. But that doesn’t mean everyone on your team is equally suited to follow security best practices when working with IaC. For this reason, consider setting rules that define who is allowed to create IaC templates and who can apply them.
Conclusion
While Infrastructure-as-Code reduces security risks in some respects, it also significantly increases the chances that a small configuration error within a single policy file can become a major risk that impacts hundreds or thousands of resources.
This fact, combined with widespread reliance on IaC today, means that securing IaC is a critical component of most modern security strategies. IaC security can be achieved, in part, by scanning IaC templates, but it also requires the evaluation of production environments as well as the establishment of best practices that mitigate the risk of IaC security problems.