The general expectation of a DevOps team on any project is that they will be responsible for the project's entire lifecycle. This responsibility ranges from infrastructure to code and further down to support. These teams are expected to react quickly to changes using agile methodologies and processes.
With Infrastructure as Code, security is especially critical. Resources that are misconfigured in code will be misconfigured at runtime. With the speed and agility of DevOps, this can eventually lead to a massive security headache.
The problem here is that the security team is not generally involved until extremely late in the process. This created a disconnect between DevOps and security where the project is not evaluated by a security professional until just before deployment in most cases.
While each organization will have unique needs, any organization looking to secure their IaC should consider these 5 best practices for securing infrastructure as code.
With IaC, everything you need to deploy purpose-built, identical environments is defined within your configuration files. It’s a potent tool but using it does come with risks. One of the significant risks includes propagating small configuration mistakes across multiple environments. These misconfigurations can range from using insecure default configurations which are quite common with third-party templates, to utilizing unencrypted databases. These small issues can leave environments vulnerable to security breaches.
Fortunately, once a misconfiguration is identified, you can simply destroy it and replace it with a new secure resource. Running security scans against your IaC code is a powerful way to identify and correct misconfigurations before they snowball into a security disaster. Additionally, teams can scan new commits for configuration changes that no longer match the desired state of the target environment and remediate them.
Drift is defined as the scenario in which the configurations for different environments fall out of harmony with (or drift away from) known secure states over time. The intent, in this case, is usually not malicious. It can happen as a result of minor errors such as changing configurations in one environment and not others. When drift occurs, IaC becomes less useful because the misconfigurations will be repeated each time the IaC gets deployed.
IaC scanning tools can help detect drift early and prompt developers to correct these issues before they advance.
Ad hoc security scanning is an effective way to identify and correct vulnerabilities at a specific moment in time. Organizations that are serious about DevSecOps would likely take a more automated approach to this by integrating checks for IaC misconfigurations into the developer workflow.
A team can implement this check in a few ways. One option would be to create a security build rule that is automated with pull requests in CI, similarly to the way unit testing is triggered. Another option would be to add a pre-commit hook to test code as a developer saves their work. Either way, the best direction is to follow the DevOps approach, which is to automate whenever possible.
All the security measures mentioned thus far have been what the industry calls point-in-time security checks. What happens when an application has been deployed into the cluster or environment and has been running for weeks and a vulnerability is found? The security checks would not detect vulnerabilities after the fact. Instead, some sort of continuous security process would need to be implemented.
Hard-coded credentials or secrets in infrastructure as code can be potentially devastating for an organization in the wrong hands. If hard-coded credentials are left in the application, anyone with access to the project will have access to these secrets and credentials. Organizations can prevent these credentials from being compromised by scanning commits before they are merged into Main. When engineers follow these DevSecOps best practices–such as scanning IaC configurations and implementing continuous security it makes it possible to operate with a much greater degree of efficiency and reliability than traditional approaches to security management.