What Is Infrastructure as Code (IaC) and How Is It Used for DevOps?
Infrastructure as Code (IaC) is a technology that allows teams to manage the configuration of cloud infrastructure such as servers, virtual machines, storage, and networks, in a declarative manner. “Declarative” means that engineers can write a simple text-based template defining what they want to deploy, and the IaC platform deploys it automatically, ensuring it is exactly the same every time.
Just like a DevOps team uses source code versioning and container images to manage the development process, IaC enables DevOps and cloud architecture teams to manage infrastructure at scale. An IaC template creates the same environment every time it is run. DevOps teams can continuously test and evolve their templates until they reach an optimal environment setup for the applications and resources they want to run.
IaC makes the environment part of a software release, managed as part of the CI/CD pipeline. Using IaC templates can help teams accelerate configuration and deployment of environments for cloud native applications, requiring less manual intervention for each release or new instance. The template, on its own, is sufficient to generate the environment and can be used to identify inefficiencies or insecure configurations, simplifying the iteration process to track improvements in performance and security.
Because IaC automates setup and tear-down of environments for dev, test, and production environments, it improves productivity for DevOps teams and enables fast deployments and more frequent release cycles.
This is part of our series of articles about DevSecOps.
In this article:
- Benefits of Using Infrastructure as Code in DevOps
- IaC DevOps Fundamentals
- Version Control
- Test Changes
- Integrate with a CI/CD Pipeline
- Common Challenges to IaC in DevOps
- Infrastructure as Code DevOps Security with Aqua
Benefits of Using Infrastructure as Code in DevOps
Infrastructure as Code provides significant advantages for DevOps teams:
- Improved collaboration with IT teams—infrastructure code uses simple, text-based languages such as JSON and YAML. IT operations staff can participate in writing IaC templates together with developers to help ensure alignment between cloud native resource requirements and IT systems requirements. This provides a common language for describing IT environments among both teams.
- Easy automation—automation is critical to DevOps but, in many cases, can require a large effort to automate processes in the CI/CD pipeline. IaC reduces this effort, eliminating repetitive manual configuration changes without a major investment in scripting.
- Standardized environments—for DevOps teams to be effective, they need to develop and test applications on a realistic copy of the production environment. With IaC, this is easy to do because teams can simply use the same template with different parameters to generate dev, test, and prod—guaranteeing that all three environments are identical.
- Standardized security—when teams set up resources manually or using scripts, there is always the chance that a specific cloud resource will not be set up with the appropriate identity and access management (IAM) roles, security groups, and so on. When infrastructure is defined as code, it is easier to ensure that every IaC template contains the necessary security measures and complies with organizational policies.
IaC DevOps Fundamentals
Version Control
If you manage infrastructure using a tool that supports IaC, such as AWS CloudFormation or Terraform, you can use the tool’s domain-specific language to define the desired end state of the infrastructure. IaC templates are idempotent, meaning that multiple runs have exactly the same end result.
It is very common to use IaC together with container images, because container images are a convenient mechanism for immutable software packaging. With immutable infrastructure, any change results in a new artifact saved to version control. Artifacts running in production always stay the same until they are torn down.
A basic principle of DevOps with IaC is to store everything in version control—code, infrastructure templates, scripts, and other code used to generate environments. This provides visibility into exactly which code was used to generate infrastructure and when. If there is a problem, it’s easy to see which version caused it, consider performing a rollback, and adjusting the IaC configuration to address the issue.
Related content: Read our guide to DevOps tools ›
Test Changes
Every change to an IaC template can have a major impact on deployed environments. It is critical to validate changes, ensure that they are secure, and confirm that they do not break the environment. This is much more important, and challenging, when there are multiple people or teams collaborating on the same IaC templates.
Traditionally, tests can be performed to evaluate changes to IaC templates, just like a unit test is used to validate that application code changes are safe. With automated tests in place, the CI/CD system can alert stakeholders to potential issues, with the possibility of automated responses, including blocked deployment or issue management workflows. This gives teams the confidence to make changes to IaC templates without fear of breaking something or putting production assets at risk.
When designing tests, you may consider avoiding reflective tests that identify whether specific features specified in the template were really deployed. These tests are often not necessary because the IaC engine is responsible for validating that the requested environment is deployed.
A valuable test case can be to consider what can cause the deployment to fail and to check for these risks prior to deployment. For example, you can test if a resource has the appropriate security groups configurations or if there are appropriate budget quotas to run this resource at the required scale.
Related content: Read our guide to shifting left DevOps ›
Integrate with a CI/CD Pipeline
To benefit from the scalability that IaC can make possible, ensure that IaC templates are fully integrated with your CI/CD pipeline. Follow these steps for changes introduced in declarative configurations:
- Create IaC templates with the resource requirements and performance goals of the cloud native applications which will run within the environments in mind. Keep security best practices in mind during this stage.
- Run unit tests on IaC templates to ensure you catch simple errors before committing to version control.
- Test templates in a temporary sandbox environment to see if they result in the desired deployment.
- After running these “smoke tests,” save the template as a versioned artifact, which can be used in the CI/CD pipeline.
- Whenever an infrastructure issue occurs, trace it back to the IaC template version that was used, fix the issue in the template, and release a new version of the declarative definitions.
Common Challenges to IaC in DevOps
While IaC is extremely beneficial for DevOps teams, it can also introduce new challenges, including:
- Human error—an error in an IaC template can have catastrophic consequences if deployed at scale. Human error can introduce security risks, data integrity issues, or can completely break the environment. You can address this problem by ensuring that access to IaC templates is carefully controlled by IAM roles, and that only a limited number of people receive admin access.
- Unauthorized access—even a basic IaC implementation can stand up environments without appropriate access controls. It is critical to define granular IAM roles and ensure that every resource being deployed can only be accessed by authorized roles, using the least privilege principle.
- Physical server access—IaC is commonly deployed on public cloud infrastructure, and administrative staff at the cloud provider often have access to the servers. There is always the concern that cloud provider staff can directly access your sensitive data. You can address this problem by relying on security standards which have been adopted by leading cloud providers, such as ISO 27017:2015, ISO 9001:2008, and Multi-Tier Cloud Security Standard Level-3.
- Multi-environment challenges—many cloud providers have their own IaC platform with different template engines and technology standards. Because there is no global standard for IaC, it is possible that the same security configuration may not apply across multiple cloud providers, and that a separate security strategy may need to be adopted for each environment.
Infrastructure as Code DevOps Security with Aqua
Aqua Security provides solutions and tools to help enterprises, cloud architects, and DevOps professionals to configure and secure cloud environments, without changing established workflows. Aqua’s open source vulnerability scanner – Trivy – helps to make secure configuration of IaC templates for Terraform and CloudFormation an accessible reality. Aqua extends these capabilities with its commercially available cloud native application protection platform (CNAPP), with automated scanning and detection of IaC templates in CI/CD workflows, as part of its cloud security posture management (CSPM) solution.
You can experience the Aqua CNAPP for yourself with a hands-on free trial ›
