Infrastructure-as-Code: 6 Best Practices for Securing Applications

Most modern applications deploy automatically on infrastructure created and configured via code. This practice, called Infrastructure-as-code (IaC) allows development teams to manage how applications are deployed and run on cloud infrastructure. It is being adopted by organizations to rapidly provision and deploy cloud environments — especially those that include containerized applications that run on Kubernetes.

Research from security platform provider Snyk reveals that many companies are only starting out on their IaC journey, with 63% just beginning to explore the technology and only 7% stating they’ve implemented IaC to meet current industry standards. And with this practice comes changes in responsibility: IaC further extends developers’ responsibility to include securing their code and infrastructure.

Misconfigurations can easily introduce security risks if best practices are not followed. In fact, according to Gartner, “70% of attacks against containers will be from known vulnerabilities and misconfigurations that could have been remediated.” Often, security trails behind the usage of IaC, resulting in configuration issues that are only detected after applications are deployed. That doesn’t have to be the case. In fact, the best way to ensure every configuration is secure, while still benefiting from the speed and repeatability of IaC, is to build security testing for IaC into developers’ workflows, the same as other forms of code.

So, what’s the most effective path to take for securing IaC? These six key best practices provide a great place to start.

1. Replace Hard-Coded Secrets

Any hard-coded secrets provided in Terraform variables or dynamically generated content should be replaced with sensitive variable references, dynamically generated values, or by a secrets management tool such as HashiCorp Vault. This best practice prevents credential leaks. Additionally, the managed secrets should be stored safely in a .ftstate file.

2. Statically Test IaC Files

Test every IaC configuration as it’s written and before applying it so you can fix errors as soon as possible. Use tools like Snyk IaC to statically test IaC as part of a developer’s local workflow, before committing any changes. Then test again after code is committed and pull requests are created, and again in pipelines before applying the configuration to an environment. This gives developers every chance to make sure their changes are going to work. Other static testing tools can ensure configurations are valid and check for consistent formatting. Most IaC tools have their own built-in validation tests as well.

3. Dynamically Test Against Environments

Run tests that execute IaC allow you to identify misconfigurations early. Tests should be run that connect to a real IaaS, execute the IaC tool, and assert against the results. This sounds simple, but comes with other prerequisites and caveats. For instance, IaC configurations have to be written in such a way that every result to be tested is predictable. “Toggle power” seems like a reasonable configuration, but the result could be either “on” or “off”; “turn power off,” on the other hand, should have one, and only one, result and therefore you can clearly test that assertion.

4. Auto-Update the Running Pipeline

The CI server and pipeline should be configured to automatically update the running pipeline whenever its definition changes. Pipelines are defined in code, the same as apps and IaC. As you expand testing and tools to support the safe usage of IaC, your pipelines should be able to automatically detect changes to their definition and start using the new versions automatically, rather than relying on human intervention.

5. Restrict Access to Environments

Only automated systems should make changes to infrastructure to prevent configuration drift and ensure every change to the environment is auditable via the source code management system. Access to environments should be restricted so that in most cases humans have read-only permissions. The CI server should be configured with privileged credentials that allow it to make infrastructure changes. For a complete audit trail, all code changes should be cryptographically signed as well.

6. Alert on Failures

The CI pipeline should be configured to send alerts when jobs fail, which allows misconfigurations to be identified early in the development process. The sooner a problem is identified, the easier and cheaper it is to fix. The team should be notified of failures as soon as they occur, so that the developers who made the most recent change still remember what they were doing and can take care of the problem quickly.

Don’t Wait Until It’s too Late to Secure IaC

Even though many organizations are still developing their standards and practices for the use of IaC, the Snyk IaC Security Insights research reveals some alarming IaC practices still exist. More than half of teams claim they still remediate a security issue by directly tweaking the infrastructure, instead of modifying the IaC source code. Perhaps it’s no surprise then, that post-deployment audits and pentests are the most common methods of testing infrastructure according to these teams.

But the use of IaC, when implemented correctly following best practices already used by other forms of code, presents an opportunity to prevent misconfigurations from reaching production in the first place and for keeping infrastructure secure over time, while also delivering on the speed and agility promises of IaC.

That’s why following these best practices for IaC security can help teams limit configuration drift while reducing exposure to misconfigurations and other critical security issues that can open up their cloud native applications to unnecessary risks.