Terrascan Blog

• 2021
• Terrascan Expands Beyond Policy as Code for IaC
• Automating Terraform Security with pre-commit-terraform and Terrascan
• Terraform Security: Terrascan in Atlantis Workflows
• 2022
• Test your cloud-native IaC in your browser with the Terrascan Sandbox
• GitOps Security: Same tool, same policies, one Terrascan
• Improving Kubernetes Security
• 2020
• Kustomize gets Policy as Code with Terrascan
• Terrascan extends Policy as Code to Kubernetes
• Terrascan Leverages OPA to Make Policy as Code Extensible
• Securing Infrastructure as Code Using Terrascan

2021

Terrascan Expands Beyond Policy as Code for IaC

Terrascan emerged from the need for a scalable way to ensure that cloud infrastructure configuration adheres to evolving security best practices. It helps identify issues such as missing or misconfigured encryption on resources and communication, and inadvertent exposure of cloud services. Terrascan fundamentally enhances the value of Infrastructure as Code (IaC) used by organizations to define and manage cloud infrastructure, and improves security by enabling teams to eliminate risk before infrastructure is deployed.

Policy as Code has proven a great fit for enforcing policies in automated workflows, and Terrascan’s focus on Infrastructure as Code (IaC) such as Terraform and Kubernetes has filled an important role. As we integrated Terrascan into DevOps tooling, pipelines and software supply chains, we realized that IaC is not the only source of risk we can help mitigate before deployment.

Over the past few months, we’ve been busy expanding Terrascan’s ability to enforce policies across multiple important dimensions of risk.

Addressing Risks in IaC and Container Source Files

We added support for scanning Dockerfiles, to help identify security misconfigurations in container-based architectures including Kubernetes. We also added support for Azure Resource Manager (ARM) templates, an IaC technology that’s native to Azure, and for scanning CloudFormation templates including nested stacks.

Adding support for new input formats includes creating policies for relevant security risks in those formats. For example, we added numerous Dockerfile policies including one to ensure that Dockerfiles don’t RUN commands as root.

Managing Vulnerability Risks in Containers

In addition to identifying security misconfigurations in IaC, Terrascan can now identify security vulnerabilities in container images referenced from Elastic Container Registry (ECR), Azure Container Registry, Google Container Registry, Google Artifact Registry, and Harbor. This is especially useful for ensuring the absence of vulnerabilities in custom and third-party containers used and built in your development pipelines.

Enforcing Policy During Deployment to Kubernetes Clusters

Terrascan can now be used as an admission controller for Kubernetes, enforcing policies as changes are applied to the cluster and preventing security issues from making it into the runtime environment. Gone are the days of managing different tools and policies for pipelines and runtime. Terrascan enables you to enforce the same policies in development and runtime!

Improving Relevance with Prioritization and Filtering

Finding violations is important, but sometimes less is more. Terrascan now offers the ability to prioritize or de-prioritize issues based on specific levels of severity for policies in each IaC file. This helps tailor policies within Terrascan for the particular use case or architecture being tested, so you can focus specifically on the issues you care most about.

Deeper Integrations, Better Automation

Automating policy enforcement into existing workflows ensures that controls are applied consistently without increasing friction in the development process. The Terrascan GitHub action can be used within GitHub workflows to detect and prevent security issues from being merged into your code repository.

For those that need earlier enforcement, evaluating IaC even before code is committed into version control, Terrascan provides a pre-commit hook which runs on the developer workstation before code changes are committed into the git repository.

Better Collaboration with Reporting and Compliance Processes

Enforcing policies in development processes is important, but it’s sometimes just as important to be able to demonstrate that development processes are continuously compliant with the security policy. Terrascan has added support for SARIF output to facilitate integration with common compliance and security reporting tools, such as GitHub security reports.

Easier Custom Policy Development for Advanced Needs

Terrascan includes an extensive library of policies and best practices, but sometimes you need to implement policies that address your unique requirements or circumstances. The newly published Terrascan Rego Editor, a VS Code extension, makes it easier to create and test policies with a seamless workflow driven in the IDE.

Automating Terraform Security with pre-commit-terraform and Terrascan

One of the best things about using Terraform to manage your systems is that best practices can be defined and applied to your templates in a manner similar to what is done with application code. This means that linting and testing the infrastructure as code (IaC) templates for quality, operational, and security issues can be accomplished easily, using some of the same workflows as application code. The most common place to enforce coding best practices is in continuous integration (CI) pipelines.

You can configure your CI pipelines to help enforce compliance with your coding policies by automatically executing validation scripts and tools and failing the CI job whenever there’s a violation. These can be configured to prevent any merges to your main branch if there’s a violation that could be considered a blocker to your system.

One of the drawbacks to relying on pipelines for enforcement is that they are bottlenecks in the development process. Every code change goes through them, and one bad commit can break the build for everybody. This can be extremely disruptive when teams are iterating quickly. One way to avoid this problem is to use a pre-commit hook to enforce standards locally on a developer’s system before pushing code to the repository. By adding a pre-commit configuration to your repository, you can help those contributing to your repository test locally to ensure their commit will not break the build once it is pushed and CI pipelines are completed.

For Terraform, one of the best projects out there to configure your repository’s pre-commit scripts is pre-commit-terraform. The pre-commit-terraform project includes multiple git hooks specifically for Terraform that can help with linting, documentation, operational, and security compliance. As part of its security toolbox pre-commit-terraform includes Terrascan, the static code analyzer for IaC maintained by Accurics.

Terraform security with pre-commit-terraform

Let’s take a look at how Terrascan can be leveraged to find Terraform security issues using pre-commit-terraform in an example.

The first step is to install pre-commit. Alternate ways of installing are available here. ~ ➜ pip install pre-commit

Once pre-commit is installed we can create the repository that will contain our Terraform templates.

~ ➜  mkdir pre-commit-tf-example
~ ➜  git init pre-commit-tf-example
~ ➜  cd pre-commit-tf-example

We’ll add a .pre-commit-config.yaml file in the root of our repository configured to use the terrascan git hook within the pre-commit-terraform repository. We’ll reference release v1.50.0 which is the latest release as of this writing.

pre-commit-tf-example git:(main) ✗ ➜  cat .pre-commit-config.yaml
repos:
-   repo: https://github.com/antonbabenko/pre-commit-terraform
	rev: v1.50.0
	hooks:
	-   id: terrascan
pre-commit-tf-example git:(main) ✗ ➜

Now, we’ll run the pre-commit install, which will configure pre-commit for this particular repository using the information obtained from the .pre-commit-config.yaml file.

pre-commit-tf-example git:(master) ✗ ➜  pre-commit install
pre-commit installed at .git/hooks/pre-commit
pre-commit-tf-example git:(master) ✗ ➜  

Let’s add a Terraform template with a known violation. In this case we’re going to add an AWS S3 object resource that’s missing the encryption at rest configuration.

pre-commit-tf-example git:(master) ✗ ➜  cat main.tf
variable "bucket" {}

resource "aws_s3_bucket_object" "html" {
  bucket   	= var.bucket
  key      	= "index.html"
  source   	= "index.html"
  acl      	= "public-read"
  content_type  = "text/html"
  etag     	= filemd5("index.html")
}
pre-commit-tf-example git:(master) ✗ ➜  

Once we try to commit the Terraform template, pre-commit will execute Terrascan. Since we have not set encryption for this object, Terrascan will fail and provide feedback on what it found.

pre-commit-tf-example git:(master) ✗ ➜  git add . && git commit -m 'add terraform'
[INFO] Initializing environment for https://github.com/antonbabenko/pre-commit-terraform.
terrascan................................................................Failed
- hook id: terrascan
- exit code: 3

Violation Details -
    
    Description	:    Ensure S3 object is Encrypted
    File       	:    main.tf
    Line       	:    3
    Severity   	:    MEDIUM
    -----------------------------------------------------------------------
    

Scan Summary -

    File/Folder     	  :    /Users/therasec/pre-commit-tf-example
    IaC Type        	  :    terraform
    Scanned At      	  :    2021-05-10 03:32:22.117445 +0000 UTC
    Policies Validated  :    607
    Violated Policies   :    1
    Low             	  :    0
    Medium          	  :    1
    High             	  :    0
pre-commit-tf-example git:(master) ✗ ➜  

Let’s fix the issue by configuring server side encryption for the object and try to commit again.

pre-commit-tf-example git:(master) ✗ ➜  cat main.tf

variable "bucket" {}

resource "aws_kms_alias" "a" {
  name = "alias/my-key-alias"
}

resource "aws_s3_bucket_object" "html" {
  bucket             	= var.bucket
  key                	= "index.html"
  source             	= "index.html"
  acl                	= "public-read"
  content_type       	= "text/html"
  etag               	= filemd5("index.html")
  server_side_encryption = "AES256"
  kms_key_id         	= data.aws_kms_alias.a.target_key_id
}
pre-commit-tf-example git:(master) ✗ ➜  

Since we added the server_side_encryption and kms_key_id parameters, the issue should be solved and we should be able to perform git commit.

pre-commit-tf-example git:(master) ✗ ➜  git add .
pre-commit-tf-example git:(master) ✗ ➜  git commit -m 'add terraform'
terrascan................................................................Passed
[master (root-commit) 41138a6] adds terraform
 2 files changed, 22 insertions(+)
 create mode 100644 .pre-commit-config.yaml
 create mode 100644 main.tf
pre-commit-tf-example git:(master) ✗ ➜  

By using a pre-commit hook we’re able to get quick feedback into security issues affecting the code we’re trying to commit. This allows us to solve issues quickly and prevent any misconfigurations from being merged into our baseline code. Terrascan can be leveraged as a pre-commit hook and as part of your CI/CD pipelines to find Terraform security weaknesses and is included as part of the pre-commit-terraform project.

Terraform Security: Terrascan in Atlantis Workflows

Atlantis is a popular open source automation platform for Terraform that leverages an organization’s code repository, such as Git, to streamline and automate Terraform workflows. At its most basic:

• New Terraform code is introduced as a pull request
• Atlantis automatically creates a Terraform plan with the new changes.
• A colleague reviews the pull request, a common development practice.
• Atlantis will apply the new plan when it receives the command, deploying new cloud infrastructure.

This is a very powerful way to manage complex cloud infrastructure across multiple teams. Moreover, the version control system naturally provides useful features like version control, permission management and audit logs.

At Tenable, we are most excited about how the entire workflow is managed as a single pull request thread. Moreover, at the end of the process, the Terraform code repository should reflect the actual deployed infrastructure. While not explicitly a GitOps approach for Terraform automation, a lot of the core tenets are present. We work well in GitOps workflows, so we decided to explore whether we can seamlessly integrate Terrascan into the Atlantis workflow.

Terraform Security with Atlantis and Terrascan

Terrascan is an infrastructure as Code (IaC) security scanner. Powered by hundreds of OPA’s Rego security policies, it scans Terraform source code and detects security vulnerabilities embedded within them. It allows users to fix vulnerable infrastructure before it is ever deployed. Scanning can be done at different stages of the deployment lifecycle. Ideally, it would be done in multiple stages.

By integrating Terrascan directly into the Atlantis workflow, scan results are reported as part of the same pull request workflow, which will inform the pull request reviewer before approving. In the spirit of automation, Terrascan can fail the automated plan build if a vulnerability of a certain severity is found.

Terraform security - Terrascan finds policy violations in Atlantis workflows

Of course, that is not the only place that Terrascan can fit in the development lifecycle. A developer can scan their code as they are writing it. Terrascan’s Github Action can automatically scan new code as it is pushed, which could actually reduce the turnaround time for a fix. To enforce policy at the organizational level, just before code is applied as infrastructure, integrating Terrascan into the Atlantis flow provides a welcome new level of security.

Getting Started with Terrascan in Atlantis

Terrascan supports being run as a server on a separate environment, so only network connectivity is required to integrate Terrascan into existing Atlantis environments. For even more flexibility, we will soon publish an Atlantis container image that includes the Terrascan binary.

To integrate Terrascan into your Atlantis deployment, please follow the steps in our documentation.

2022

Test your cloud-native IaC in your browser with the Terrascan Sandbox

Terrascan is open-source software from Tenable that scans infrastructure-as-code (IaC) for security misconfigurations and violations before the code is provisioned into cloud-native infrastructure. Now, you can try Terrascan right from your browser with the new Terrascan Sandbox.

The Terrascan Sandbox can test a variety of code, including:

• Azure Resource Manager (ARM)
• CloudFormation Templates (CFT)
• Docker
• Kubernetes
• Terraform
• Terraform plans

Simply paste your code into the code window, select the appropriate IaC version you’re using, and click Scan. You’ll immediately see security violations, details about their severity and the Tenable Research policies that are impacted.

Code is analyzed and compared against hundreds of security policies, providing details about the origin and impact of each violation, the same capabilities you get when you download and run Terrascan on your workstation. The policy library provides details on how to remediate each problem.

Terrascan is at the heart of Tenable Cloud Security, an enterprise solution for scanning cloud-native runtimes, cloud environments and IaC. Terrascan and Tenable.cs are both part of Tenable’s mission to help organizations implement comprehensive cyber exposure management and enable sound security practices earlier in the software lifecycle.

Learn more about Terrascan, download the app or join the community by visiting runterrascan.io.

GitOps Security: Same tool, same policies, one Terrascan

Among their many advantages, GitOps pipelines enable teams to run automated security tests using codified policies. Since your Git repository reflects your infrastructure configurations, scanning your Infrastructure as Code (IaC) repository is a straightforward way to find and fix security vulnerabilities as part of local development cycles.

Terrascan, a leading open-source static code analyzer for cloud technologies like Terraform, Helm, Docker, Kubernetes (K8) and others, has had the ability to scan and test IaC repositories for some time. It’s ideal for teams who are – or want to – add security checks to the code they use to provision cloud and on-prem systems. This practice is what’s commonly known as Policy as Code.

One of the key advantages of Terrascan is the ability to scan code throughout its lifecycle, on developer workstations, in git repositories, Kubernetes admissions controllers and in CI/CD pipelines. This empowers DevOps teams to integrate Terrascan into their workflows and apply the same policies used to enforce policies in production environments. Using the same tool, with the same policies, ensures security and consistency across the GitOps pipeline and prevents code-to-cloud drift.

GitOps is a framework that takes the automation and best practices from the world of application development into the world of cloud native infrastructure. Argo CD is a GitOps CI/CDtool for Kubernetes. In a GitOps pipeline, infrastructure is codified, collaborated upon and version controlled. Like application code, infrastructure is codified and stored in a Git repo, and a tool such as Argo CD is responsible for ensuring that infrastructure remains synchronized with the git repository.

Figure 1. GitOps security using the Argo CD workflow with Terrascan policy as code.

Integrating security testing into a Argo CD workflow is easy using Terrascan.

You start by setting up a single instance of Terrascan, and connecting both your Argo CD and Kubernetes cluster to it. Once connected, youre be able to leverage consistent configurations, and establish thresholds that trigger CI/CD events. For example, you can set which policy violations will break an Argo CD build or reject admission to the Kubernetes cluster.

If you are only interested in code-scanning – or you have a specialized need – you can add your own policies and apply them to both your Argo repository and your Kubernetes cluster. Unlike other tools powered by the Open Policy Agent (OPA), no other adapters are necessary. Terrascan achieves this by standardizing the input around the same policy, regardless of the target. You can also use hundreds of built-in standard Terrascan policies, or mix and match as desired.

Wondering why you should trigger security controls in both the CD workflow and at admission to your Kubernetes cluster? The answer is that changes to the cluster can be made by tools other than your CD tool, either by mistake or by malice. The admission controller is your defense against those threats, but for ease of maintenance and remediation, it is best not to rely on the admission controller alone for recurring workflows. Rather, it’s a best practice to leverage your CD tooling for integrated tests.

Terrascan provides 500+ out-of-the-box policies so you can scan IaC against common policy standards such as the CIS Benchmark. Terrascan leverages the OPA engine so you can easily create custom policies using the Rego query language. If you’re new to Terrascan, you can play around with it in the online sandbox at tenable.com/terrascan.

For more information, please check out the Argo CD integration folder in our public git repo, and check out the documentation. The Terrascan team is committed to building in public, and this is just the beginning of our GitOps story. We would love to hear from you on our Github repo.

Improving Kubernetes Security

Given the mind-boggling rate of innovation and adoption of cloud native technologies, the Terrascan team at Tenable has resolved to help cloud native development teams identify and mitigate more vulnerabilities than ever. Terrascan provides a great platform for this, since it is easy to integrate [policy as code] (https://www.tenable.com/products/tenable-cs) into development pipelines and the extensible architecture makes it easy to build flexible policies with the popular Open Policy Agent (OPA).

With all the attention on Kubernetes security at the moment, we decided to start there. We are focusing on a couple of common themes that underpin Kubernetes vulnerabilities. Specifically:

• Establishing a sandbox for your containers. It is important to establish constraints on the capabilities of your containers, so attackers cannot compromise your nodes or host systems.
• Resource management. Configurations should specify limits for the resources that can be used by containers and pods, to prevent denial of service when demand spikes.

For simplicity, I generally refer to “pods” in the explanations below. Many of these policies are relevant for numerous types of resources, such as pods, ReplicaSets, Deployments, etc. Our policies actually protect all the relevant object types, even though I may only mention pods. To fully understand which resources are protected by a particular policy, you can reference the source code or the documentation.

Policy as Code Enforcing Resource Management

Proactive resource management is a best practice for Kubernetes. If you do not establish limits on the resources that your containers and pods can use, then you can end up in a situation where they require more resources than are available. These limits also help the folks managing your production environment understand the scaling characteristics of your system, since they are probably not as familiar with it as you are.

Note that these policies are relevant from a security perspective as well as an operational perspective.

To avoid these types of problems, teams should establish a policy that Kubernetes configurations must specify resource limits. They can leverage policy as code tools like Terrascan to scan configurations and flag any that do not comply with the codified policy.

The first two policies pertain to CPU limits and requests. In short, your pods should specify how much CPU they want, and also define a limit for how much CPU they may consume in the worst case. This enables the scheduler to place the workload on an appropriate node with an eye to the worst case CPU consumption to avoid starving other tenants.

1. CPU Limits Should be Set
2. CPU Request Should be Set The following configuration includes the desired settings and is compliant with our policy. A non-compliant configuration would lack one or both of the CPU limits and requests.

apiVersion: v1
kind: Pod
metadata:
  name: cpu-request-limit-example
spec:
  containers:
  - name: cpu-request-limit-container
    image: images.example/app-image
    resources:
      # Applies to policy #1 (CPU limit should be set)
      limits:
        cpu: "1500m"
      # Applies to policy #2 (CPU request should be set)
      requests:
        cpu: "500m"

The third and fourth resource policies are similar to those above, except they apply to memory rather than CPU. The rationale is the same.

• Memory Limits Should be Set
• Memory Requests Should be Set

apiVersion: v1
kind: Pod
metadata:
  name: memory-request-limit-example
spec:
  containers:
  - name: memory-request-limit-container
    image: images.example/app-image
    resources:
     # Applies to policy #3 (Memory limit should be set)
     limits:
       memory: "512M"
     # Applies to policy #4 (Memory requests should be set)
     requests:
       memory: "256M"

• Avoid use of vulnerable volume types CVE-2020-8555 affects certain versions of Kubernetes, and allows an information leak when pods use certain types of volumes. This policy helps you avoid vulnerable configurations by identifying unsafe use of these volume types.

Policy as Code Enforcing Container Sandboxes

Linux, and by extension the container runtime, provides a variety of “capabilities” that processes can use, which establish finer-grained permissions than simply testing whether they are running as root. Perhaps more important than the need to limit the resources that containers can use, is the need to limit the capabilities that containers will have at runtime–these capabilities will increase the container’s access to the host system and the container runtime daemon. By limiting these capabilities, you can prevent the container workload from breaking out of the container to access other processes and resources on the host system.

In the case of Kubernetes applications, breaking out the container may enable a workload to access the node upon which the workload runs, and in turn to access Kubernetes secrets which may allow access to other nodes and the control plane. Several of these policies pertain to the [PodSecurityPolicy] (https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for a particular pod or node:

• Container Should Not Be Privileged Privileged containers can bypass restrictions in the Docker daemon, allowing them to access the host system like a privileged local process. This is necessary for certain use cases, but should not normally be enabled for production workloads. This corresponds to the privileged field.
• Containers Should Not Run with AllowPrivilegeEscalation This policy protects against applications that try to escalate their privilege entitlements at runtime, potentially gaining privileges that the container creator did not intend for them to have. This corresponds to the allowPrivilegeEscalation field.

Containers generally run inside an isolated environment that prevents pods from accessing host-level information on the node such as process ids (PIDs), interprocess communication (IPC) mechanisms, the underlying host network, and so forth. Moreover, processes running inside containers may be able to indirectly access resources on the host based on the user id (UID) under which they run. For example, filesystem permissions are often based on UIDs. As a result, it is important for developers to make efforts to enforce isolation within the container runtime so that workloads can’t access things which they should not be able to access. The following rules enforce those constraints:

1. Containers Should Not Share Host IPC Namespace If a container is able to access the host’s IPC namespace, then it can discover and communicate with processes in other containers or on the host itself. This corresponds to the hostIPC field

2. Containers Should Not Share Host Process ID Namespace If a container is able to access the host’s PID namespace, then it can discover and potentially escalate privileges for any process on the host including itself. This corresponds to the hostPID field

3. Containers Should Not Share the Host Network Namespace If a container is able to directly access the host network, then it can operate outside the virtual network established by Kubernetes–potentially accessing the control plane or internal services which should not be accessible. This corresponds to the hostNetwork field

4. Containers Should Run as a High UID to Avoid Host Conflict Containers ideally will run under a unique UID which is not present on the host system. This ensures that the container will not be able to access resources on the host to which it is not entitled. If a container runs under UID 0, for example (a common default), then it might be able to access privileged files like /etc/passwd if it gained access to the host’s filesystem. If the container runs under a unique UID, then it would not be able to access host-based files even if it gained access to the filesystem. This corresponds to the runAsUser field

5. Ensure that readOnlyRootFileSystem is set to true Containers with writable root filesystems may be able to modify the cached image used by other pods based on the same image. Thus, it is important to ensure that the readOnlyRootFilesystem field is true.

6. Restrict Mounting Docker Socket in a Container If a container can access the Docker daemon socket, then they can control the container runtime. This includes listing and controlling containers, changing capabilities, and even gaining control over the host. This rule ensures that containers are configured to prevent access to the Docker socket from within the container.

The isolation of each container is typically augmented by imposing restrictions on capabilities, security profiles, and access to kernel settings (sysctls). The following Terrascan rules ensure that sensible restrictions are configured for containers, and that containers do not attempt to remove such restrictions:

1. Do Not Use CAP_SYS_ADMIN Linux Capability The CAP_SYS_ADMIN capability essentially grants root privileges to the container and should be avoided for the same reasons as #6 and #7 above. This corresponds to enabling SYS_ADMIN in the allowedCapabilities field.
2. Ensure that every pod has AppArmor profile set to runtime/default in annotations If you use AppArmor, then you should leverage the default, secure profiles for your workloads. This rule ensures that you are using one of the secure defaults, rather than a profile which provides insufficient protection. This corresponds to AppArmor annotations added to the PodSecurityPolicy, as described in the [documentation] (https://kubernetes.io/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations).
3. Ensure that seccomp profile is set to runtime/default or docker/default An alternative to AppArmor is seccomp. Similar to #16, users should use the secure default profiles rather than potentially insecure ones. This corresponds to the seccompProfile field or seccomp annotations added to the pod, depending on the version of Kubernetes in use.
4. Ensure that forbidden sysctls are not included in pod spec Some sysctl access is necessary for containers to operate, but sysctls are a very low-level and potentially invasive capability. This rule ensures that containers do not enable sysctls that will represent a risk to the broader host system. This corresponds to the forbiddenSysctls and allowedUnsafeSysctls fields.
5. Minimize Admission of Containers with Capabilities Assigned Explicitly adding capabilities to the allowedCapabilities field is inherently dangerous because it gives the container capabilities beyond the secure defaults. If an attacker were able to gain control of the container, they could leverage these extra capabilities to potentially take over the node or access the control plane.
6. Minimize Admission of Root Containers SecurityContext should specify runAsNonRoot to ensure containers do not run with the root UID of 0. See #6-#12 above for more information about the dangers of containers as root.

These new policies will enable development teams to better enforce reasonable security policies at build time, and shine a light on configurations that introduce unnecessary risk of vulnerability in the system. By leveraging policy as code in automated pipelines, teams can effectively identify and remediate risk during development and before insecure systems are deployed. . Note: this series focuses on policies available on the main branch of Terrascan which may precede a release that includes the new policies. If you want to ensure you are using the latest policies, you can delete your local policy configuration (typically in $HOME/.terrascan) and re-run terrascan init. The policies discussed in this document were committed to the repository on 2021-01-13 and will be included in the release after 1.2.

2020

Kustomize gets Policy as Code with Terrascan

Most organizations – in fact, over 78% – leverage Kubernetes in their move to cloud-native applications. This powerful and flexible platform enables teams to deploy and manage sophisticated systems while delivering innovation to market faster than ever. Unfortunately, that power and flexibility often requires significant care and effort, especially as apps migrate through their lifecycle. Each new environment may require configuration and connectivity changes which need to be tracked and managed.

Kustomize helps teams address these challenges by providing a way to tweak configurations based on declarative overrides. It works great for building environment-specific configurations into automated processes without adding brittle pre-processing steps or managing external properties and templates.

Given the popularity of Kustomize and Kubernetes – they are regularly downloaded millions of times each month – we’re excited to include support for both Kustomize and Kubernetes in release 1.2.0 of Terrascan.

Terrascan is an open, extensible architecture that enables teams to enforce policies and compliance in numerous types of IaC, and has supported Kubernetes for some time now. With the addition of Kustomize support, it now has a better understanding of those configurations and can deliver more accurate and relevant results. Policy as Code guardrails are a best practice for cloud native development, and this is just one more example of Terrascan’s commitment to delivering that capability for the most popular technologies.

Kustomize and Terrascan: Getting Started

Getting started with Terrascan is easy, regardless of whether you use the portable Go binary, a Docker container, or you build from source. The command line interface works well in many contexts, regardless of whether you want to run from a shell, a script, or in a pipeline.

Start in the directory where your Kustomize project is stored and launch Terrascan:

terrrascan scan -i kustomize

Kustomize support is implemented as a new IaC provider, leveraging Terrascan’s extensible architecture. The “scan” command will scan the infrastructure, and the “-i” option enables the Kustomize IaC provider.

Terrascan defaults to scanning from the current directory, and you can add the -d option one or more times if you would like to scan other directories. The output will be sent to the terminal in YAML format by default, and includes a summary of the results as well as the details needed to prioritize and fix the findings. The structured output works well for programmatic processing and is easy for humans to read.

Please tell us what you’d like to see next! Feedback is always welcome in our Community Discord or via Terrascan GitHub Issues.

Terrascan extends Policy as Code to Kubernetes

Accurics is excited to announce Terrascan v1.1.0, with Kubernetes (k8s) support! Cloud native apps and infrastructure are notoriously complex and difficult to secure with traditional tools, and kubernetes adds automation and orchestration that es##calate those problems to another level. Practically speaking, security automation is mandatory because it’s not realistic to expect humans to comprehend such complex, dynamic environments.

Terrascan is an extensible, open source tool that enables teams to detect compliance and security violations across Infrastructure as Code to mitigate risk before provisioning cloud native infrastructure. By adding k8s support to Terrascan, we’re ensuring that all teams, regardless of budget, have access to the tools they need to secure their cloud native apps and infrastructure well before they are ever deployed in the cloud.

Release 1.1.0 works with k8s YAML and JSON configurations, and includes policies for security risks present in those files. Future releases will add support for k8s infrastructure managed through other IaC providers such as Terraform.

Using Terrascan with Kubernetes

Terrascan is usually run as a portable Go binary or a Docker container. Its command line interface can easily be adapted to run it from a terminal, a script, from within a pipeline, and numerous other contexts. To use it, simply run terrascan from a directory where your kubernetes project lives.

terrascan scan -t k8s

Terrascan defaults to scanning YAML and JSON files in the current directory and subdirectories. If your project spans multiple directories, you can use the -d option one or more times to specify which directories to scan.

By default, output is sent to the terminal in YAML format.

The structured output includes a summary of the results as well as the details needed to prioritize and fix the findings. It’s suitable for humans to read, and for programmatic processing.

We’re just getting started, and we’re excited about the opportunity to help teams secure their cloud native apps and infrastructure. Join us in the Community Discord for more Terrascan tips and tricks, and stay tuned for more exciting announcements about new technologies and policies that cover even more of the cloud native landscape.

Terrascan Leverages OPA to Make Policy as Code Extensible

I’m really excited about our release of Terrascan v1.0!

Brief history of Terrascan and Accurics

When I created Terrascan, I was working on a big cloud migration project, doing assessments on my employer’s cloud security posture. One of the most tedious parts of the job was manually reviewing Terraform to ensure it adhered to security best practices. My second child was born, and I was having sleepless nights during my paternity leave.

I kept thinking about the problem we had where developers relied on security experts to help them secure their Infrastructure as Code (IaC). I thought that there should be a way to automatically scan IaC similar to what we were doing for application code (e.g. Java, Python, C#, etc.), where we had static code analysis tools to give developers immediate feedback on security risks.

At the time, I couldn’t find any existing tools that could scan Terraform and meet the requirements I had. So I put something together with some Python packages that worked with Terraform HCL, some regexes, and that’s how Terrascan was born. The project was really useful and I decided that the best way to maintain a project like this would be to open source it.

A couple of months ago, I joined Accurics to start the next phase in Terrascan’s journey. We have a lot of exciting ideas for Terrascan, and perhaps a few surprises in store. The release of v1.0 is the first step on that path.

New features, Extensibility

Terrascan was initially designed to serve a specific need: static analysis of Terraform templates for the security risks my applications faced. A primary goal of Terrascan v1.0 is extensibility. We’ve introduced a pluggable architecture that can use the same approach to scan Terraform, AWS CloudFormation, Kubernetes and any other type of IaC tooling. We will be adding new configuration languages in the future, and it’s easy to extend to your needs.

In addition to allowing multiple input formats, we wanted to have a standardized way to create and apply policies across these IaC tools. So we replaced the regular expression based rules with the Open Policy Agent (OPA) engine from the CNCF. Using the Rego policy language it’s easy to create, modify, or extend the policies that apply to your specific needs.

The new architecture uses a common intermediate language for IaC with the idea being to be able to leverage the 500+ policies we’re initially releasing with v1.0 across AWS, GCP, and Azure in a provider agnostic way. This means, for example, that the policy we wrote to detect public S3 buckets can be leveraged when scanning Terraform, CloudFormation, or any other IaC language that provisions AWS resources.

With v1.0 we’re also introducing server mode. This allows you to run Terrascan as a server, where an API will give you the ability to scan any IaC being sent with the policies configured. With this capability, Terrascan can be used as the central hub of policy enforcement across your organization.

Given this new extensibility, we wanted to ensure that users have a place to share ideas and experience. So the release of Terrascan v1.0 is accompanied by the launch of the Accurics Community, a place for users of Terrascan and other Accurics solutions to discuss and collaborate. Please check it out, and remember that it’s only as useful as what you put into it.

Dedicated to open source, vision for future

Security is an important, foundational concern of any cloud project, and open source tools like Terrascan help to standardize and democratize security in a way that anyone can contribute to. It benefits all organizations, and the community itself, to have security policies exposed for everyone to look at so we can quickly identify the best practices, and then apply those consistently across all applications.

Be safe.

Securing Infrastructure as Code Using Terrascan

I remember one of my first public cloud projects. We created a cross functional team that included representatives from the business, developers, architects, security, and operations. The goal was to have a minimum viable product for an important customer facing system as our first cloud native deployment in 12 weeks.

At first the task seemed daunting. There was a lot to learn and implement in a short period of time, and as the representative of the security team, I wanted to make sure security was embedded into every decision we made.

That meant having a scalable way to review and provision network security settings and configuration, identity and access management policies, and ensuring that any cloud resource was configured following security best practices.

IaC Benefits

Around that time I discovered a tool called Terraform and the concept of Infrastructure as Code (IaC). Using Terraform we were able to quickly provision our infrastructure in a consistent manner where the code to provision our infrastructure lived side by side to our application code.

At the same time, using Terraform to provision and manage the security of our cloud environment meant that development teams had greater visibility into how the security of the infrastructure was configured, how it affected our application, and they were empowered to submit pull requests if there were any changes needed.

This was a huge benefit compared to the way things were done in our on-premises data center. Where we used ticketing systems to engage the security team and from the perspective of developers security was a black box that a siloed team handled.

The Challenge

Although IaC empowered our development teams to take ownership of their infrastructure and devops lifecycle, it also presented some challenges. Our architecture was increasingly complex due to being in a hybrid environment and the pace of change was increasing as we increased our cloud adoption.

Security defects in our IaC could be augmented and replicated through the environment if we didn’t have a way to review or control changes to prevent security defects. Issues like exposing your private network to the public internet, not encrypting any sensitive data at rest, or missing access logs could put the environment and business at risk.

What’s Terrascan?

As I thought about these issues I realized that the same techniques we were using for our application’s code like static code analysis could be used to identify security weaknesses in our IaC. This would ensure security best practices were embedded as early as possible into the development lifecycle.

To solve this I developed Terrascan. Terrascan is an open source static code analyzer for Terraform. It helps you test your Terraform code to find security weaknesses including:

• Server side encryption misconfigurations
• Using AWS Key Management Service (KMS) with Customer Managed Keys (CMS)
• Encryption in-transit SSL/TLS is not enabled and configured properly
• Security Groups open to the public internet
• Inadvertent public exposure of cloud services
• Access logs not enabled on resources that support them

Using Terrascan

To install Terrascan, you’ll need Python 3.6 or later installed in your system.

$ pip install terrascan
Collecting terrascan
  Downloading terrascan-0.2.1-py2.py3-none-any.whl (28 kB)
Requirement already satisfied: pyhcl>=0.4.4 in ./.pyenv/versions/3.7.5/envs/terrascan/lib/python3.7/site-packages (from terrascan) (0.4.4)
Installing collected packages: terrascan
Successfully installed terrascan-0.2.1

Now that you have Terrascan installed, lets scan some code. Here’s an example s3_bucket resource that’s missing encryption.

resource "aws_s3_bucket" "my_insecure_s3_bucket" {
  bucket = "my-insecure-s3-bucket"

  logging {
	target_bucket = "logging_bucket"
	target_prefix = "log/"
  }

  tags = {
	Name    	= "my-insecure-s3-bucket"
	Environment = "production"
  }
}

Here are the results of running Terrascan against that resource.

$ terrascan -l .
Logging level set to error.
........................................................................
----------------------------------------------------------------------
Ran 72 tests in 0.005s

OK

Processed 1 files in /Users/therasec/test/.

Processed on 06/20/2020 at 22:45
Results (took 0.26 seconds):

Failures: (1)
[high] [aws_s3_bucket.my_s3_bucket] should have property: 'server_side_encryption_configuration' in module ., file /Users/therasec/test/./s3.tf

Errors: (0)

As you can see, Terrascan detected that the s3 bucket resource is missing the “server_side_encrytpion_configuration”.

Terrascan can be installed as a pre-commit hook to help detect issues before code is pushed into your repository. It can also be integrated into your CI/CD pipeline. You can learn more about Terrascan or contribute at github.com/accurics/terrascan.

Accurics Commitment to Open Source

I am thrilled to join the Accurics team and continue to support Terrascan together. We’re also committed to increasing our contributions to the open source community - you can expect to see more projects from us in the future