Infrastructure as Code: Security Risks and How to Avoid Them
Infrastructure as Code: Security Risks and How to Avoid Them
Infrastructure as Code (IaC) is a key DevOps practice that bolsters agile software development. In this report, we identify security risk areas in IaC implementations and the best practices in securing them in hybrid cloud environments.
The ever-increasing demands on IT infrastructures and the rise of continuous integration and continuous deployment (CI/CD) pipelines have pushed the need for consistent and scalable automation. This is where infrastructure as code (IaC) comes into play. IaC is the provisioning, configuring, and management of infrastructure through formatted, machine-readable files. Instead of manually setting up on-premises and cloud environments, administrators and architects can just automate them with IaC. IaC works well with infrastructure as a service (IaaS) and has been adopted by organizations to develop and deploy scalable cloud implementations faster and at reduced costs.
While the IaC concept bears similarities to programming scripts (which also automate IT processes), IaC uses descriptive language for coding more adaptive provisioning and deployments (that is, the software itself is responsible for initiating infrastructure changes). IaC is considered especially crucial for DevOps and also plays a role in cloud security automation..
IaC tools can be categorized into two groups. Orchestration tools are for provisioning, organizing, and managing infrastructure components (for example, CloudFormation and Terraform). Configuration management tools, on the other hand, are for installing, updating, and managing running software in infrastructure components (for example, Ansible, Chef, Puppet, and SaltStack). These tools enable developers and cloud architects to shift from manual, error-prone tasks and simplify large-scale configuration and management.
What are security risk areas in IaC implementations?
Keeping up with the rapid pace of CI/CD cycles through IaC, however, comes with a few challenges. For instance, an unpatched vulnerability in an IaC tool could serve as a threat entry point to the core infrastructure. Vulnerabilities could allow attackers to bypass procedures, run code on hacked servers, or even deploy cryptocurrency miners. IaC templates that have misconfigurations could also expose sensitive data or leave openings for attacks.
The general IaC principle is that a single application can manage multiple environments described in the configuration files, which take the form of code and also execute the code, (which could also be malicious) inside target environments. An IaC application can use different approaches to describe the target environment; the common thing is the configuration itself, its storage, and especially the secrets, which are necessary for connecting to managed infrastructure.
The secrets storage is important as it contains sensitive data, such as application tokens necessary for authentication, Secure Shell (SSH) keys, and passwords. Storing such data inside source code management (SCM) systems (for example, Git) or plain text files is a dangerous — and from a security perspective, irresponsible —practice, as they can be easily exposed. For instance, bots that scrape public SCM sites and look for secrets could quickly exploit them and compromise the infrastructure (for example, by spawning cryptocurrency miners). We therefore recommend using vaults for storing secrets and referencing them inside the configuration files.
Master’s communication channel
Some IaC configuration management tools (for example, SaltStack) use master-node architecture, where the nodes are managed from a master node. Generally, in accessing managed infrastructure from a single point (that is, a master), it is crucial to secure the single point as it contains all of the infrastructure or deployment specifications, and a security compromise would affect the whole infrastructure.
Using prepared environments inside the cloud reduces the risk of compromise from misconfigurations and configuring infrastructures from scratch.
Figure 1. A high-level overview of a master-node architecture
The master needs to have a secure communication channel to be able to communicate and manage the nodes. There are two different approaches for managing them:
Installing a custom agent for managing the node to perform certain tasks
Using commonly available software and communication protocols for managing nodes (also known as “agentless”), like bash script execution via SSH protocol
From a security perspective, using a custom network protocol brings another attack surface and even possible vulnerabilities to the fore, as in the cases of CVE-2020-11651and CVE-2020-11652, which are vulnerabilities in SaltStack’s Salt management framework, which is used in data centers and cloud servers.
CVE-2020-11651 is an issue in the handling of custom network protocol that could allow an unauthenticated user to perform remote code execution (RCE) inside the entire infrastructure. CVE-2020-11652, on the other hand, is a path traversal vulnerability that could allow other parties to read arbitrary files. In both cases, a malicious actor could obtain the root key and gain access to the master and, consequently, to the whole infrastructure. Both SaltStack vulnerabilities had been critical enough that F-Secure researchers who found the flaws decided not to release any proof-of-concept code.
Figure 2. A sample of a CVE-2020-11651 patch limiting exposure methods
Malicious actor had been quick to target platforms built on the management infrastructure. Cryptocurrency miners had infected cloud servers and consequently spiked CPU usage and overloaded systems in vulnerable Salt instances. Malicious actors also looked into compromising a certificate transparency (CT) server’s signing key that might have been exposed to the critical vulnerabilities.
User privileges are another security consideration. If an IaC application is used to manage application deployment, it is unlikely to require root privileges on the target machine. Following the principle of least privilege might be challenging, but it should mitigate the risk of compromise.
The same principle also applies when deploying inside public clouds like Amazon Web Services (AWS). An account or role assigned only for a particular purpose (for example, spawning prepared virtual machines) should be used with limited capabilities. Passing cloud provider credentials with administrator access for less privileged tasks is an unsecure practice.
Enabling agile deployment through provisioning and managing cloud infrastructure is done through IaC templates, which are machine-readable definition files that build environments that deploy and run code from external sources. However, they are not without risks. These templates are part of IaC processes and could unintentionally use operating system or container images from untrusted sources. These sources could open doors to threats such as backdoors and cryptocurrency miners.
IaC templates could also have vulnerabilities and unsecure default configurations that could lead to data exposure. The vulnerabilities could introduce further risks to IaC-deployed cloud infrastructures and stored data, especially if unnecessarily exposed to the public internet. Handlers should first check IaC templates for unsecure configurations and other potential weaknesses early in the development process. Regular scanning using a cloud security posture management service also helps identify and remediate misconfigurations.
How can IaC deployments be secured?
IaC deploys and manages infrastructures, including databases, networks servers, services, and virtual machines. It is a key DevOps practice that bolsters agile software development. IaC helps speed up development and efficiently manage infrastructures. Without IaC, developers and IT teams maintain the configurations of individual deployment environments. This manual process could lead to inconsistencies and security issues in deployments.
With IaC, the infrastructure is defined inside text files (code). While it allows users to specify multiple properties, its poor implementations could lead to unsecure deployments. Misconfigurations are a major security concern in cloud environments, including IaC tools. The lack of security awareness on the IaC pipeline could lead to the compromise of the entire infrastructure.
To secure hybrid and public cloud environments, we recommend the following measures:
Enforce the principle of least privilege. Account privileges in cloud services should be limited, especially when linked to public cloud providers. Permissions and access to tools should be restricted to prevent attackers from gaining a foothold in nodes. This way, IaC configurations are stored securely and data leakage is prevented.
Use IaC security plug-ins. Security plug-ins in the integrated development environment (IDE) help mitigate potential issues in IaC templates before deployment.
Update infrastructure software to the latest version. Security patches should be immediately applied when available. (Fixes for the aforementioned Salt vulnerabilities were already released.)
Do not expose a central system. A central server should not be exposed on the internet to prevent the spread of compromise to other components downstream.
Improve security and compliance posture. Real-time security that detects misconfiguration in cloud service providers should be employed to ensure protection in the pipeline. Solutions that have an auto-remediation function can also help in rectifying failures.
Trend Micro™ Cloud One™ - Conformity is a cloud security and compliance posture management service that allows organizations to achieve real-time security for their cloud infrastructures. It provides automated security and compliance checks, full visibility and simplified reporting, and seamless workflow integration.
For organizations looking for runtime workload, container image, and file and object storage security as software, the Deep Security™ solution and Deep Security Smart Check can scan workloads and container images for malware and vulnerabilities at any interval in the development pipeline to prevent threats before they are deployed.