Infrastructure as Code, or programmable infrastructure, builds off automation techniques to reduce the amount of resources spent to replicate environments. In basic terms, allowing the “copy and paste” of environments to avoid plan, procure and provision methods for every instance of a set-up. The infrastructure managed includes physical equipment as well as virtual machines, containers, and software-defined networks. (Klein & Reynolds, 2018; Elder & Williams, 2019).
One principle of IaC is idempotence, a property ensuring a deployment command always sets the target environment into the same configuration, regardless of the environment’s starting state. This is achieved by automatically configuring an existing target or by discarding the existing target and recreating a fresh environment.
Automation through the ad hoc scripting of tasks has been around for years, however, IaC technology and practices emerged with the introduction of cloud computing.
Benefits of Infrastructure as Code
Creating a new virtual machine using the Amazon Web Services management console requires stepping through at least five web forms and filling in 25 or more fields. VMs are created and torn down many times every day during development and test, so performing these tasks manually is not feasible. Cloud technologies form the basis of the third generation of IT infrastructure, where IaC has an enormous potential for improving the efficiency of creating and maintaining information systems. (Basa et al., 2020).
Firstly, as IaC can be shared across development, integration, and production environments, scenarios where software works in one environment but not another are eliminated.
Secondly, IaC stores configuration changes in a version-controlled repository. Any version of the infrastructure can be created using the IaC code corresponding to the desired version. The robust versioning enables the capability to efficiently and reliably recreate a particular configuration – as well as rollback a change made during development.
Finally, IaC can enable immutable infrastructure. Traditionally, over time, each node would be individually patched, updated and configured, resulting in configuration drift. In an immutable infrastructure, patches, updates, and configuration changes are applied to the source code to create a new version of the IaC code. Environment parity allows the new version to be tested in development and integration environments prior to production, and environment versioning allows the new changes to be rolled back if there is an unexpected issue after deploying to production.
IaC and Amazon Web Services
Amazon Web Services (AWS) has aDevOps-as-a-Service partnership which uses Continuous Integration and Continuous Delivery (CI/CD) pipelines as well as Infrastructure-as-Code (IaC) to quickly, effortlessly, and accurately deploy code and launch additional infrastructure services.
Continuous Integration (CI) and Delivery (CD) are agile software development practices where code changes are automatically built, tested and finally released to production in short cycles. (Di Penta, 2020). Continuous integration also implies that developers’ code is continuously integrated into the main codebase and continuous delivery is rather self-expanatory. The main benefits of CI/CD is that software can be developed more rapidly, while quality is still maintained. By making deployment a common task, mistakes, such as configuration errors, are less likely to occur. This process is called continuous deployment, or CDep. (Wikström, 2019).
The use of IaC and CDep together by AWS allows the ability to spin up, correctly size, and provision new environments without excessive workloads and extended timeframes.
IaC and Security
Due to the massive transfer of corporations and users to clouds, the problem of protecting information and components of the structure becomes extremely urgent.
IaC scripts which contain hard-coded credentials or other security smells, can be susceptible to security breaches – and, according to CWE (2018), “If hard-coded passwords are used, it is almost certain that malicious users will gain access to the account in question”.
So, what are security smells? Security smells are recurring coding patterns that are indicative of security weakness. A security smell does not always lead to a security breach, but deserves attention and inspection. Existence and persistence of these smells in IaC scripts leave the possibility of another programmer using these smelly scripts, potentially propagating use of insecure coding practices.
Rahman et al. (2019) outline the following Security Smells as the seven sins:
- Admin by default: This smell is the recurring pattern of specifying default users as administrative users. The smell can violate the ‘principle of least privilege’ property
- Empty password: This smell is the recurring pattern of using a string of length zero for a password.
- Hard-coded secret: This smell is the recurring pattern of revealing sensitive information such as user name and passwords as hard-coded configurations in IaC scripts.
- Invalid IP address binding: This smell is the recurring pattern of assigning the address 0.0.0.0 for a database server or a cloud service/instance.
- Suspicious comment: This smell is the recurring pattern of putting information in comments about the presence of defects, missing functionality, or weakness of the system.
- Use of HTTP without TLS: This smell is the recurring pattern of using HTTP without the Transport Layer Security (TLS). Such use makes the communication between two entities less secure, as without TLS, use of HTTP is susceptible to man-in-the-middle attacks .
- Use of Weak Cryptography Algorithms: This smell is the recurring pattern of using weak cryptography algorithms, such as MD5 and SHA-1 for encryption purposes.