DevSecOps: Infrastructure as Code (IaC)

Cloud Security

Infrastructure as code allows admins to deploy Infrastructure, faster and more consistently. It does this by creating a rinse and repeat process. The configuration and defined code is managed and secured ready to be used to deploy infrastructure to a standard. This increases automation and reduces the need for manual effort.

Why is it useful?

It’s useful because manual effort can create challenges. When resources are created manually, access control normally stops with cloud admins. This is because of fear that someone would create resources that don’t meet company standards. Because the cloud admins have the responsibility, it makes sense they have higher enforcement.

With IaC, the management is at the code/configuration layer. If Security and the cloud admins have approved the code, it should allow more freedom. This being allowing Developers to create resources, as they would be creating resources using code that is approved. This prevents misconfiguration which often happens with manual effort and allows a defined process to be shared.

Having IaC will also reduce wasted resources as cloud admins shouldn’t be confined to just creating resources. Although it is important to keep standards, processes and policies should be enforced to take the weight off the cloud admins’ shoulders. With IaC, the “shift left” method can be used to secure the code prior to deployment, and the platform itself would have security layers enforced via policy management.

Different Types of IaC

There are two types of IaC. Declarative and Imperative. Below are the differences:

Declarative
This is where you only define the end configuration. The code doesn’t define how it gets there, but only what it should look like in the end.

Imperative
This is where you specify a sequence of commands. This is then followed in order to reach the end configuration. It’s a bit like a step-by-step instruction book.

Security Aspect

Security is the main concern of any infrastructure management process. The process and policies need to be correctly applied so that you aren’t exposing any resources/data.

Below are a few examples of how you can improve the security of IaC:

Code Scanning — Plugins
There are multiple open-source scanners out there that can help prevent the deployment of unsecured code (Infra). Choosing which one would depend on what the code is being used for, however, research should be done to implement at least one.

Managing Secrets
Credentials and secrets should not be stored as part of the code. This should instead be referenced or called as part of the deployment. Services such as Azure Key Vault can help with this. Repo security is also a key factor as if you accidentally include sensitive information, it could lead to a breach.

Version Control
This is key as it helps track misconfiguration and which deployment is being used. Having auditing enabled alongside will give your admin team a fighting chance should something go wrong. Tagging should also be paired so that resources created can be linked back to the version of deployment (config version).

Access Control
As always, a least privilege access model should be applied to the whole process. In this instance, the code should be treated with a higher level of access, not just the deployment action. If an account was overtaken, changing the code would be enough to allow malicious changes to be deployed. This could include deploying VMs with public access or include back door credentials. The attacker doesn’t need to run the config, merely change it and wait for an admin to do it for them.

Portal Security
Regardless if you split or host your code separately, any access to your IaC process should be secured. This includes enforcing MFA and other conditions to prevent unplanned changes. Although securing IaC can be straightforward, it’s also easy to undone. For example, disabling auditing.

Continuous Monitoring
As part of the life cycle, security should be reviewing the code, and process on a regular basis. Cloud platforms do often change, and it’s important to keep up on configuration files to ensure standards are kept. This should be matched with the platform security. For example, if your compliance tool is flagging that all recent resources don’t have encryption, the resource templates should be reviewed/changed to prevent future exposure.

Tools:

Below is a list of tools that can be used for IaC. This isn’t a complete list but should give you some examples.

• Ansible
• Puppet
• Terraform
• CFEngine
• Azure Bicep
• AWS CloudFormation
• Google Cloud Deployment Manager

If you like my content, please remember to clap and follow! 😁
If you have any requests or content you wish for me to cover, simply drop my an email at contact@xstag0.com! 🦌

Thank you!