The adoption of Infrastructure as Code(IaC) has skyrocketed in recent years as engineers seek ways to deploy cloud infrastructure faster and more efficiently. IaC refers to the technologies and processes that manage and provision infrastructure using machine-readable languages (code) as opposed to inefficient manual operations. Languages and frameworks, like Terraform and Pulumi, provide a unified language to codify infrastructure and streamline cloud orchestration across different environments and providers. Cloud providers use native IaC frameworks, such as AWS CloudFormation and Azure Resource Manager (ARM), to transform manual, one-off processes into consistent, scalable, and repeatable provisioning.
Shifting cloud security left with IaC
IaC shifts infrastructure deployment left, providing new opportunities to automate, scale, and secure cloud environments.
Historically, teams have had to approach cloud security after the fact. They did this through resource monitoring for policy violations during runtime. Even with automation in place, this approach can become time-consuming and arduous for engineers that need to address identified issues reactively. By extrapolating cloud infrastructure into code and embedding it into the development lifecycle, teams can now address cloud security preventatively.
With IaC in place, you can enforce security best practices alongside your container scanning, dependency scanning, SAST, DAST, and more. However, for IaC security to be truly effective, it must be embedded into automated CI pipelines.
For more on CI/CD security best practices, read our Ultimate guide to CI/CD security and DevSecOps
Getting started with security enforcement
How do you find policy violations and misconfigurations in the infrastructure used to build AWS, Google Cloud, Azure, and Kubernetes resources? By adding IoT security scans to your CI pipeline. Bridgecrew works by continuously scanning infrastructure to identify known security vulnerabilities and providing the code to fix them. For example, here are a few commonly overlooked policies:
- Ensuring all data stored in S3 bucket is securely encrypted at rest
- Ensuring no security groups allow ingress from 0.0.0.0:0 to port 22
- Ensuring all data stored in the Launch configuration EBS volume is securely encrypted
For IaC security to be efficient and actionable, it needs to provide consistent feedback. The best way to get that consistency is by embedding IaC security into your automated CI pipelines. We will use the Bridgecrew CircleCI orb to automate IaC security for every commit.
To follow along, you will need a few things:
Fork a misconfigured Terraform project
For this tutorial, we will fork Bridgecrew’s “vulnerable-by-design” project, TerraGoat. Head over to the TerraGoat project and fork it to your own GitHub account.
In your forked project, select Add file then Create new file. Set the file path to
.circleci/config.yml, and add the following CircleCI configuration:
version: 2.1 orbs: bridgecrew: firstname.lastname@example.org jobs: build: executor: bridgecrew/default steps: - checkout - bridgecrew/scan: directory: . api-key-variable: BC_API_KEY
Scroll to the bottom and select Commit directly to the master branch. This will add the Bridgecrew orb to the CircleCI pipeline we will create next.
Using Bridgecrew for automated IaC security
Head over to the CircleCI integration page in the Bridgecrew platform. There you will find the environment variable, your API key, and the CircleCI config.yaml that we just added to our repository.
Our next task is to add the integration to CircleCI. Go to the CircleCI projects page. If the GitHub integration is set up, the newly forked TerraGoat project will be listed.
Select Set Up Project next to
terragoat. Select Use Existing Config and Start Building. The build will fail because we have not added our API key as an environment variable. To do that now, go to Project Settings and select Environment Variables. Select Add Environment Variable. Add
BC_API_KEY and your API key from the Bridgecrew integration page here.
A new build should start. If it does not, select Rerun workflow from start next to the build. If you open that pipeline and the Scan section, you can find all the checks that failed during the build process.
This build failed because of the 129 failed checks listed. To prevent this, you can customize your organization’s guardrails by skipping irrelevant checks, or you can trigger an alert on a failed check without failing the build.
Taking it a step further
To conduct further investigation on incidents by severity, category, or compliance benchmarks, you can head to the Bridgecrew platform. Once there, you can drill into issues to understand their impact and affected resources, and fix the code as needed.
With a pull request integration in place, you can instantly push remediations to your VCS, merge, and build again. This continuous workflow is the best way to make sure that misconfigurations are not deployed into provisioned cloud resources. 🙌
IaC helps cloud-native teams take their infrastructure to the next level with benefits related to speed, scalability, cost-savings, and security. By automating your IaC security, you can leverage the inherent immutability of IaC to harden your cloud security posture and save time doing it.