At Aqua, we believe that cloud native is an opportunity to do security right. With the release of our Terraform Provider, we’ve added another tool to do security the cloud native way. With Aqua Terraform Provider, security teams can easily adopt DevOps processes and infrastructure as code (IaC) to consistently automate how they deploy and update Aqua components as resources, with a governance overlay for peer reviews, code checks, and attestation of changes for audit and compliance.
Management of Aqua resources using Terraform Provider in concert with CI/CD tools allows for automation of updates. It also enables the application of different sets of policies through pipeline branching and the governance of configuration changes to ensure that security teams can document and audit controls. Teams can also reduce the risk from potential misconfigurations (identified by both the US National Security Agency and the UK’s National Cyber Security Centre as critical security concerns) by using IaC patterns to ensure repeatable, desired builds.
Security teams can make it easier to implement preventative controls with a declarative pipeline for Aqua resources and enforcement policies. At the same time, they can enforce peer review practices and approval gates in the CI/CD pipeline before changes are committed to meet compliance and risk management needs for maximum scrutiny.
Terraform Provider provides the missing link for cloud native security maturity with configuration as code.
What is Terraform Provider?
Terraform is one of the most commonly used tools for software-defined infrastructure and is the foundation of many organizations’ IaC initiatives.
With integrated support of the leading open source IaC parser tfsec as part of the Aqua-maintained Trivy scanner, Aqua Security helps developers identify vulnerabilities and misconfigurations in their Terraform templates.
With the release of Terraform Provider, users can now automate the deployment of their Aqua infrastructure using Terraform, as well as manage security changes through version control and CI/CD workflows.
Why configuration as code for security resources?
Security teams at our customers have asked us to support Terraform Provider to declaratively define the configuration of the Aqua Enterprise platform. Security teams want to automate the build and deployment of our security components through CI/CD pipelines, treating security components as resources, for a range of reasons.
- They want to leverage configuration-as-code patterns to minimize operational overhead for deployment, upgrades, and change management and to ensure consistency. Pushing out policy changes using a declarative pipeline facilitates the deployment of security resources into production environments and allows teams to implement preventative controls more systematically.
- Security teams are looking for ways to formalize and document how policy changes to production environments are implemented and to programmatically manage not just who is authorized to make changes to security infrastructure and policies, but also how.
- For security teams to adjust to the velocity of cloud native, they need more efficient processes to manage changes that are both high-frequency and high-risk, such as changes to runtime enforcement policies. Security teams also are looking for ways to automate pre-approved policy changes, such as defined limits on CPU resource usage and least privilege.
The benefits for security of configuration as code
The impact of the adoption of cloud native architectures extends beyond what needs to be secured—such as the software supply chain, the Kubernetes infrastructure, and containerized workloads in production—to how the infrastructure and processes are secured. The trend toward “shift left” exemplifies how this impact has played out for DevOps pipelines. Aqua’s Terraform Provider is intended to bring cloud native DevOps patterns to security, mirroring how DevOps functions to operate at the same pace.
Using configuration as code, security teams can take advantage of the same automation, ease of committing change and versioning benefits as DevOps in order to embrace and operationalize DevSecOps. By using declarative pipelines to standardize operations through configurations as code, companies can reduce the friction and inefficiencies between teams to ensure they’re running on the latest version.
Using Aqua based on IaC patterns with built in oversight gates prevents even users with authorized access from making unwanted changes, since each commit is fully audited and subject to peer review.
The risks of configuration as code
Security teams, especially in regulated industries, are required to implement, document and audit change controls for their security infrastructure. By automating changes without checks, teams can lose sight of when and why changes were made.
And without role-based access controls (RBAC) and governance gates like approval checks, declarative pipelines can be exploited by malicious actors or can propagate unapproved changes that bring down production environments, and leave applications exposed for extended periods of time.
For instance, a malicious actor could turn off a policy that would otherwise stop his bad code, and then turn it back on again, without the changes being documented.
Likewise, a security analyst with the right level of permissions could turn a policy on to “enforce” with unintended consequences for production environments. If it takes weeks to fix a change to production environments, the potential impact to the business of a breach could be less than the cost of the downtime required to effect policy change.
How to navigate the risks and benefits for DevSecOps maturity
We developed Aqua Terraform Provider as a means to leverage IaC practices in a DevSecOps context. Terraform Provider permits creation, removal, updating, and deletion of policies through the Terraform console, as well as wider policy-management actions.
Teams are also able to implement RBAC practices and principles of least-privilege access to the full Aqua UI, to better secure changes in policy and limit the potential for unapproved changes.
By running Aqua configuration in a CI/CD pipeline, the potential risks of declarative pipelines are reduced. Also, the governed process produces an audit trail of what changes are made and by whom, and subsequently makes those actions subject to scrutiny when hitting approval gates.
This makes it easier for our customers in their pursuit of a full spectrum of security controls across prevention, detection, and correction, balancing the needs to mirror the pace of cloud native DevOps, maintain visibility and transparency into the change management process and govern how policy changes are made.
Configuration and policy-change branch permissions can be set to restrict unauthorized changes, while approval policies and integration testing can be enforced via pull/merge requests. All requests, merges, code check-in, and changes are easily accessible and traceable via commit history.
The process below is based on the minimum stages and steps required to initiate, deploy, and manage change in AquaSec. Terraform Provider has been built to manage all changes that would affect a production version of Aqua.
Conclusion
Deployment through declarative configuration as code in the form of a Terraform Provider allows security teams to scale their operations and ensure that the Aqua components, like our Enforcer, are integrated into standard build workflows. By reducing operational overhead and managing change through a defined process with gates, security teams can use configuration as code to deploy Aqua more broadly, get better visibility, and react more quickly with greater clarity when a run time issue arises.
To learn more about Aqua Terraform Provider, check out our GitHub repo and our listing on the Terraform Provider registry.