When building out your infrastructure, quite often you find yourself in a situation where you have pre-deployed resources in a cloud environment. Maybe the team before you deployed an RDS cluster by hand, or created an S3 bucket through the command line.

For situations like these, cloudrail has a two tier strategy for reviewing your infrastructure. We first take a look at the terraform files you’d like to deploy, which we call a “Static” assessment, and then we take a look at what’s already deployed in your cloud environment – which we call a “Dynamic” assessment. Here’s how both of them work, and how they work together.

What Is Static Analysis?

A static analysis is performed against your `.tf` files and is usually done so locally. Cloudrail checks your local configuration against the ruleset to determine if any violations are present. The thing to note however, is that It doesn’t have context for what has already been deployed in the cloud, inside or outside of your current terraform repository.

Static deployments are a great way to check that the new resources you’re writing are configured correctly. A quick one-line command to ensure the code you’re writing is secure. You can run a static deployment like this:

cd your_local_terraform_repository
cloudrail run

What is Dynamic Analysis?

A dynamic analysis is Cloudrail’s analysis of all your resources in your cloud environment. With this analysis, Cloudrail acts as a Cloud Security Posture Management (CSPM) tool, checking your resources against our ruleset for violations, whether introduced from terraform, the CLI, the console, or in other ways. We do this on a continuous basis. Where Cloudrail really shines however is combining static and dynamic assessments.

Bringing Static & Dynamic Together

A static + dynamic analysis provides the full capabilities of Cloudrail, and checks both the terraform code intended to be deployed with the existing state of your cloud. Instead of waiting for issues to be in production before they’re surfaced, cloudrail can be integrated in your CI/CD pipeline to fail a problematic deployment before it goes out. With the full context of static and dynamic analyses, there are two main advantages:

– It identifies more issues and vulnerabilities

– It reduces false positives

An implementation of Static + Dynamic analysis, usually done in a CI pipeline, can look like this:

# Get your cloud account ID from the web.cloudrail.app console
export YOUR_CLOUD_ACCOUNT_ID=230613d8-3b24-4790-b650-36f31845f19a

# Create a terraform plan
terraform plan --out plan.out

# 
cloudrail run \
    -p plan.out \
    --cloud-account-id $YOUR_CLOUD_ACCOUNT_ID \
    --drift-track

While a static analysis only uses terraform files, a static + dynamic analysis will instead rely on a pre-created terraform plan file to best represent your architecture.

FeatureStatic AnalysisDynamic AnalysisStatic + Dynamic
Scans your local terraform code for violations
Scans your cloud account for rule violations
Uses .tf terraform files
Uses terraform plan files

When should I use static, vs static + dynamic?

Running a static + dynamic assessment gives you the best representation of your infrastructure – but you may not always be in a place to be able to do that. A static + dynamic assessment requires you to be in an environment where you have access to the terraform state and can generate a terraform plan file. If you have the ability to do that on your local workstation, we’d recommend running a static + dynamic assessment to give you the best possible picture.

If however your terraform state is kept in a separate place, or managed by a service like env0 or terraform cloud, your best option for running cloudrail locally is a static assessment. That said, you can always integrate cloudrail as a part of your deployment pipeline as a specific step.

With our support of both static, and static + dynamic assessments, Cloudrail is a versatile tool that lets you fix infrastructure vulnerabilities early, and at any stage in the development pipeline. Check it out today!