HomeOperationsAutomated OperationsIntegrating Security into your Infrastructure-as-Code pipelines

Integrating Security into your Infrastructure-as-Code pipelines

Security is often left at the back of the queue when developing code, Priority is on Minimal Viable Product, and after delivering a feature, it’s quickly on to the next. The laser focus on features often means that stability or more often the security of the product suffers.

This is like not paying off your credit cards every month. Your bill just keeps getting bigger, and it’s bound to go wrong sooner or later. Surely there must be a better way?

Secure coding is not new by any means, but the democratization of IT with cloud, and multidisciplinary DevOps teams have put security under pressure. While building out infrastructure using Infrastructure-as-Code with declarative language isn’t ‘real’ programming, there are real security considerations to take into account. The difference between automatically creating a secure infrastructure and an insecure one is small.

The rest of this article will focus on how and where you can improve the security posture of your deployments.

Securing your IaC

Security_IaC

We will continue with the working assumption that Terraform is the product used to deploy the environments, as such this post is obviously biased to products and processes that play nicely with that ecosystem.

As you move closer to productionizing your Infrastructure-as-Code deployments, we need to start enforcing some rigor into our build processes and that includes enforcement of security rules. For this we have HashiCorp’s Sentinel. This is not an open source product but part of their enterprise suite of products. To use Team and Governance there is a cost of $70 USD per user per month.

HashiCorp Sentinel

HashiCorp_Sentinel

Sentinel is a language and framework to embed security policy into existing workflows to enable a finely grained, logical policy. These policies enforce what behavior is allowed. Sentinel embeds with Terraform between the planning and application stages to provide seamless policy enforcement on any proposed changes to an infrastructure.

For example if your infrastructure is only allowed access from a defined set of IP addresses or ranges, Sentinel can enforce blocking the ability to set a 0.0.0.0/0 CIDR block.

import "tfplan"
disallowed_cidr_blocks = [
  "0.0.0.0/0",
]

main = rule {
  all tfplan.resources.aws_security_group as _, instances {
    all instances as _, sg {
      all sg.applied.ingress as ingress {
        all disallowed_cidr_blocks as block {
          ingress.cidr_blocks not contains block
        }
      }
    }
  }
}

How is this possible?

Remember when you issue a Terraform plan against new code, or even current code, Terraform reads the current state file of the deployed infrastructure (if there is any) and then runs the proposed changes and issues a response showing what changes if any are being made to that state.

This is a chance to manually verify what is happening, but if you are not aware of any mandatory compliancy stance regarding your infrastructure you could inadvertently introduce valid code that lowers your security profile. This is where Sentinel enters. Sentinel’s Policy-as-Code engine will take the resultant “tfplan” and compare it against the enforceable policies and error any changes that are in contravention of policy.

Sentinel_Compliance

 

 

Common Code blocks

Another method of lowering risk is introducing a common module registry of compliant code. We have started to do this with our LAMP stack series. This reduces risk as a vast majority of deployed code comes from tried and trusted modules. Hashicorp has a central repository of modules, but if your security posture is such that you cannot use this, create your own private repository with a tool like Gitlab.

Securing Remote State

Thirdly protect your identity by introducing password and identity control Hashicorp provides for this. When running larger teams of deployment engineers, it’s recommended to use remote state and use these security controls.

Encrypt your State files when at rest. Terraform cloud always encrypts state at rest and protects it with TLS when in transit.

Additionally, Terraform cloud maintains an audit log of state changes. This makes shared accounts a bad idea, even when the cost model is user-based.

An alternative is to use an S3 back-end to store your statefiles; this is what we did with our LAMP stack deployment. S3 supports full encryption at rest with the “encrypt” option set and IAM policies and logging identify any unauthorized access attempts further any request for state data transits over a TLS connection.

VeraCode

Before your environment moves into production introduce automated testing that automatically checks your environment for vulnerabilities, Veracode can help here. Every modern developer knows and understands that automated tests are needed to verify that their code functions as designed and there are no obvious vulnerabilities; in fact this is a core component of their project gating systems. But how can we take that logic and apply it to the scale of infrastructure? The units under test are completely alien to standard development surely! Not true, the whole point of IaC is to deploy applications into production on a vastly accelerated timescale. If those applications are part of the deployment, hint here – they should be!! A post-deployment tool like Veracode is a perfect fit to undertake this role. Static analysis security testing, will test any binaries,

Software composition Analysis will identify vulnerabilities in both open source and commercial code. You can use it to undertake automated analysis of vendors security stance, without needing access to the underlying source code. And finally it provides testing tools to identify and help remediate any flaws in software post deployment.

Finally you can implement a system of automatic tests to verify that there has not been any unauthorized configuration changes to your infrastructure. This can be as simple as issuing a scheduled terraform plan against your infrastructure or a fully functional configuration management solution.

Summary

Summary

The need to test to for security is not diminished when utilizing Infrastructure-as-Code. If anything it increases it, as it is so easy to deploy new environment and introduce security risks. As we have shown it is quite simple to enhance your security profile with a with a few simple steps.

NEWSLETTER

Receive our top stories directly in your inbox!

Sign up for our Newsletters

spot_img
spot_img

LET'S CONNECT