Infrastructure as Code (IaC) technology is popular with administrators and DevOps, as it lets them manage, provision, and configure their cloud infrastructure automatically by writing code.
Security teams use IaC tools to automate configuration of code, versus manually configuring code in their cloud infrastructure. However, the advantages that come with IaC, including speed and agility, also introduce security risks that have to be managed.
The leading IaC tools are very powerful. IaC applications, like Terraform by HashiCorp, AWS CloudFormation, Azure Resource Manager, and many more, provide pre-built code configuration templates for their users. They generally follow the same principles of configuring, provisioning, and managing assets at scale from a single point of truth. If not managed correctly though, these tools can introduce cloud risks in resources that could allow an attacker to access or gain control over the cloud environment.
So how can you manage your IaC security risks? In this article, we give an overview of infrastructure as code best practices and guidance to help you avoid and mitigate common security risks.
IaC Templates
IaC templates help users write code using an external source to build resources. Templates let DevSecOps practitioners and security teams use a provider’s pre-configurations and images to build their own assets. By doing so, you can save a significant amount of time. Deploying an IaC template is similar to developers leveraging external libraries and modules while coding.
But by doing so, organizations can expose their cloud infrastructure to security issues, like misconfigurations. Any unprotected bucket or misconfigured load balancer built using a misconfigured template has a high risk of an attacker exploiting it as an initial access point. As these IaC templates are used repeatedly, one small mistake could lead to the creation of hundreds of unsecured assets susceptible to breach.
Scan IaC Templates First for Flaws
One of the dangers with IaC templates is that users could deploy a misconfigured template multiple times, perhaps hundreds of times, before that flaw is detected.
Unencrypted S3 bucket deployed using an IaC Template
For this use case, see the screenshot below of Terraform’s simple template for S3 bucket creation.
At first glance, it looks ok. However, upon deeper investigation, a practitioner could identify that encryption is not defined by default for the module variables. Users do not expect a popular IaC template to have an active security flaw in it. As a result, when an unsuspecting user creates the new S3 bucket with this template out-of-the-box without explicitly configuring it to use encryption, this resource will be unencrypted. The result? The user now has deployed an at-risk S3 bucket where data could be exfiltrated by an attacker.
What about the new S3 bucket risk introduced? It is always important to check and scan templates for security flaws, and ensure that the source of the templates is trusted. Even a widely used IaC provider such as Terraform, may have pre-built IaC templates that could expose organizations if not deployed correctly. Therefore, DevSecOps teams should scan and review templates that are in use for vulnerabilities to manage and mitigate IaC risks.
Malicious Images Created with an IaC Template
Another security risk that IaC templates can introduce into the cloud security environment is malicious images. A threat actor could potentially upload an IaC template that creates an EC2 instance, so the users build it from an tampered image. This ultimately can lead to system backdoors and other initial access risks.
Security teams should review IaC templates for security flaws before first-time deployment, and then set up processes to ensure in-use templates and images can be trusted. IaC templates can be scanned using a cloud security platform with shift-left security.
Remote State File IaC Risks
State files are one of the core elements in IaC tools. The purpose of these files is to keep track of the state of your infrastructure, and map IaC objects to real-world resources. By default, the state file is saved locally. If multiple developers are working on the same project, all developers need to have access to the same state file in order to avoid any confusion in the environment. To store this data file for developers in the cloud, we can store the state file in a remote and shared place, but it should be done in a secure manner.
The state file contains a lot of sensitive information about the environment. If it falls into the wrong hands, it can be exploited to gain information about misconfigured and vulnerable assets, and attackers can use it to exfiltrate data. For example, if a bucket with an ACL (access control list) allows any user to read the content of the bucket (e.g., ‘public-read’ canned ACL for AWS S3 buckets) and with permissive network rules, an attacker could exfiltrate data from the bucket by exploiting these findings.
Storing sensitive data in cloud storage that supports encryption, like S3 buckets in AWS and Azure storage in Azure, is a data security best practice. Make sure to limit the access to the state file, and only grant privileges to users who need access to the file.
Hard Coding Secrets in IaC Applications
Storing hard coded secrets in IaC configuration files is a common mistake that is made by many developers, since one of the promises of using IaC is that a single application can manage multiple environments across multiple cloud vendors. Unfortunately, human error and emerging vulnerabilities pose ongoing risks to the organization’s most expensive data, whether it’s regulated data or intellectual property.
For every cloud environment, the IaC application stores secrets to be able to authenticate against the cloud provider and manage the environment. The secret storage is important as it contains sensitive data like passwords and SSH keys. Storing sensitive data inside local clear text files or in unprotected SCM (Supply Chain Management) applications is considered dangerous and could be exploited if compromised.
It is highly advised to store these types of coded secrets in a dedicated secrets manager, like Vault or AWS Secrets Manager. Then, DevSecOps can configure the IaC tool to use the secrets manager when initiating authentication with the CSP. Using a dedicated secrets manager may be costly and complicated to configure, but from the security perspective, it’s a cloud security best practice.
Artigo traduzido e disponibilizado pela DigitalSkills Consulting - Distribuidora oficial de soluções de cibersegurança do fabricante Orca Security. Para mais informações: www.digitalskills.pt | [email protected] | 21 418 05 21
Artigo original no site do fabricante em https://orca.security/resources/blog/infrastructure-as-code-common-risks/
