Infrastructure-as-Code Security: a Critical Responsibility

By Thomas Segura, Technical Content Writer, GitGuardian

By large, software is still in its adolescence compared to other large-scale industries. Although its principles have been established for over half a century, it is still undergoing powerful transformations that regularly expand how it can be used. Recently, enterprises have experienced such a move with the advent of cloud computing. Moving large swaths of their IT operations to the cloud has been a massive opportunity for them to deliver new products faster. The cloud offers an unprecedented level of agility when it comes to allocating or deallocating computing resources on the fly.

But on closer inspection, we find that most of the power of the cloud relies on infrastructure capabilities. Cloud assets, cloud services, and resources, as well as orchestrators like Kubernetes, and even policies, are not managed in real-time by human operators. They are software-controlled and defined in code. Welcome to the era of Infrastructure-as-Code, or IaC!

Democratizing cloud resources

IaC is the new abstraction layer offering DevOps engineers, SRE, and developers a common language to declare what the IT infrastructure should look like: the number of servers, storage, databases, network topology, and all the basic configurations (DNS entries, firewalls, etc..).

Infrastructure is not just about production workloads. It is something required to support the entire development process. The great thing about IaC is that everyone can specify what resources are needed at every stage of the SDLC: spawn a few isolated environments at the development stage, replicate the production conditions for testing, etc. IaC is the standard language for describing these resources and how they should be configured.

This yields incredible benefits for go-to-market strategies: infrastructure becomes as flexible as the software it supports and faster to execute thanks to reusable modules, and more consistent at the same time. Maintenance costs are lowered, as is the risk of human error when done right.

Of course, as requirements become more complex, so do IaC declarations. But this is where this technology shines: having a textual “single source of truth” (meaning what’s written in the files corresponds at all times to what is deployed and how it is configured), version-controlled (allowing people to inspect changes and collaborate easily) saves engineers a lot of time and headaches.

This paradigm has a name: GitOps. It allows faster and more reliable cloud-native deployments by using the same approach for managing infrastructure configuration files as for software source code. Teams collaborate more effectively on infrastructure changes and vet configuration files with the same rigor as software code. Infrastructure definitions are stored in git repositories, are incrementally modified and reviewed pull or merge requests, and finally tested and applied via CI/CD pipelines.

Since engineers are working directly with code, IaC has made infrastructure workflows shift left.

But as with everything, this comes at a cost. In this case, it is the need to shift cloud security left as well.

Securing the infrastructure with code

Regarding security, IaC has some interesting features: first, it can be used to automate the provisioning of security controls. This means that you can enforce security policies more consistently and efficiently.

Second, IaC can help you to manage your security posture more effectively. By automating the provisioning of security controls, you can more easily track and monitor your infrastructure for security issues. It can help you to identify and resolve any potential security problems quickly.

Finally, IaC can also help you to improve your incident response capabilities. You can more quickly and easily deploy countermeasures in a security incident. This can help minimize the impact of a security incident and get infrastructure back up and running as soon as possible.

But protecting the infrastructure is a considerable challenge. By blurring the line between application and infrastructure security, IaC adoption raises a big question: who should be responsible for it?

Infrastructure-as-Code is a new responsibility

It goes without saying that infrastructure security is paramount. Traditionally, specialized operations teams supervised this attack surface with many tried and tested tools. But when code manages infrastructure, uncaught mistakes can result in sneaky security vulnerabilities. A single misconfiguration in an IaC manifest can impact runtime or network security: for instance, traffic can be left unrestricted to a resource or data mistakenly exposed to the exterior.

Not only that, but static vulnerabilities need to be specifically addressed as well: hard-coded credentials are the most critical. No matter the level of awareness about the importance of not storing plaintext credentials in configuration files, mistakes still happen on a frequent basis.

In fact, misconfigurations are one of the top ten vulnerabilities identified by OWASP. Therefore, it is logical to anticipate potential vulnerabilities by setting up the right guardrails to ship clean code from the start. This responsibility, part quality, part security, should be shared to implement a genuine DevSecOps philosophy. Failing to do so could mean a potentially costly security failure is around the corner.

Infrastructure-as-Code responsibility is at the crossroads between DevOps, AppSec, and CloudOps engineers. Enabling their collaboration from source to deployment is the only way for an organization to shield itself from future threats. Tools are starting to emerge to cater to this new paradigm.

Since IaC has reached new heights in the realm of automation, it is evident that automation is part of the answer. Bringing automated scanning for misconfigured vulnerabilities and hard-coded credentials will strengthen organizations’ overall security posture. More than that, it will also participate in raising awareness about IaC security best practices and common mistakes.

Conclusion

Infrastructure-as-code is here to stay. The benefits it brings are entirely transforming the software development cycle and opening new doors for automation and innovation. While its advantages have been praised for some time, its associated threats are becoming more apparent. Security needs to fully embrace this new paradigm centered around the dynamism and ephemerality of the underlying resources offered by the cloud. Bridging the gap between security, operations, and development activities, leveraging automation to build efficient security solutions, will be essential for organizations to raise the bar of their security posture. The first step in that direction must be to protect their cloud infrastructure at the source code level as early in the SDLC as possible.

About the Author

Thomas has worked both as an analyst and as a software engineer consultant for various big French companies. His passion for tech and open source led him to join GitGuardian as technical content writer. He focuses now on clarifying the transformative changes that cybersecurity and software are going through.

Thomas can be reached online at LinkedIn, TWITTER, and at our company website https://www.gitguardian.com/