Is your Cloud infrastructure securely configured? Does your DevSecOps pipeline integrate ibm-terraform compliance checks? – IBM Developer

Join the Digital Developer Conference: AIOps & Integration to propel your AI-powered automation skills Register for free

IBM Developer Blog

Follow the latest happenings with IBM Developer and stay in the know.

Does your DevSecOps pipeline integrate ibm-terraform compliance checks?

The trend toward deploying security as part of the DevOps process has been shifting left the security and compliance processes. The DevSecOps practices have introduced processes to inspect application-code, Docker, and Kubernetes. These practices have allowed teams to detect and fix security issues faster and provide high-quality and compliant code.

Still, many admins of Cloud accounts are securing account configuration by configuring an account via a UI, running a configuration assessment scan, and then fixing any issues found. While this might lead eventually to a securely configured account, they are essentially experimenting with an account until it becomes secure.

Can you afford this type of experimentation? Can you afford having an account exposed for some time until you figure out security? Why don’t you apply DevSecOps to account configuration? If you are in a highly regulated industry, you cannot afford to experiment like this when you know that compromised credentials and cloud misconfigurations are often responsible for the malicious security breaches. And, attackers are constantly scanning for such exposures.

The professional and compliant solution for achieving a secure configuration is to codify all the planned configuration and to check those configurations before they are deployed to an account. Codifying cloud account configuration has been solved by infrastructure-as-code (IaC) solutions like Terraform, Red Hat Ansible, and AWS CloudFormation.

The codification of cloud account configurations in the form of IaC presents a great opportunity to control this highly critical infrastructure’s code via DevOps pipelines, just like any other code. It allows for reuse of IaC for multi-regions, reuse across accounts, reuse of IaC modules, and allows for creating a single representation of the infrastructure. Now, DevSecOps holds a highly critical responsibility of preventing misconfiguration of cloud accounts and compliance with regulations through scanning of IaC before it is deployed.

In November of 2020, IBM announced the release of Code Risk Analyzer (CRA), a component of IBM Cloud Continuous Delivery. We are expanding CRA to shift-left compliance check for infrastructure-as-code (IaC). The new IaC scanning analyzes ibm-terraform files and helps you ensure that your ibm-terraform meets NIST regulations. Today, it supports 56 compliance goals, covering 18 NIST controls, and the list is growing. This new component is built into a DevOps toolchain and can be controlled via toolchain environment variables.

With this new component, you can now scan the compliance of your infrastructure-as-code and make sure that any planned changes to your account are compliant with NIST regulations. You can control this process from Continuous Delivery toolchains and consume the output both in your git repository and in Continuous Delivery dashboard. You can create gates that block the deployment of the IaC when misconfigurations are found and remediate misconfigurations as soon as they are created.

terraform compliance checks

Getting started today

To start using this feature immediately, setup Code Risk Analyzer and add to your trigger properties a tf-dir variable with a value of the terraform directory within your repository.

screen shot of defining the tl-dr property

Use the Configuring Code Risk Analyzer tutorial in the Continuous Delivery docs to set up your own toolchain.

Best practices

Many terraform users are deploying terraform into their account using a script that deploys the resources gradually. While this is a common practice that is used to allow the control of the deployment process, you should not ignore the need to have a single point of reference of the IaC. Instead, you should create an entry directory for the IaC and create a terraform file that describes the fullly planed deployment, regardless of the deployment mechanism. You can think about this as a bill-of-materials file, like a package-lock.json, for example.

The great majority of the IaC compliance checks are also implemented as compliance goals in IBM Cloud Security and Compliance Center (SCC). You should use the IaC compliance checks as CI/CD gateways for terraform deployment and periodically check the SCC scan results after deployment. In the future, Code Risk Analyzer will support all SCC goals and enhance the integration with SCC.

Some of these compliance goals can be parametrized by adding a customization json file to the IaC repo and pointing to it using the policy-config-json environment variable. An example of this customization json is as follows:

"max_cos_managers": 2,
"max_global_admins": 2,
"max_account_managers": 2,
"max_all_resources_managers": 2,
"max_all_resources_readers": 2,
"max_iam_admins": 2,
"max_kms_managers": 2

screen capture of pipeline runs

Looking forward

Going forward, we will be supporting more controls in the DevSecOps pipeline, and will add auto-remediation capabilities to fix IaC issues. We will provide a strong integration in the Security and Compliance Center (SCC) by posting evidence to SCC, pulling the SCC profile into the pipeline, and closing the loop from SCC to DevOps. This will allow better collaboration between the compliance teams and the DevOps team. Also, we will support scanning of multi-cloud provider’s IaC.

In addition, we are planning to add a mechanism to support user provided rules. Our policies are implemented in Rego, the policy language used by the Open Policy Agent (OPA). They are leveraging the terraform-opa-ibm that provides an abstraction of a terraform plan for Rego. We plan to allow users to craft their own rules based on this library.