Can OPA bridge the gaps between cloud security silos?
Infrastructure as Code (IaC) has been a chief catalyst for accelerating the adoption of cloud-native applications. IaC automation enables DevOps teams to iterate faster and ensures speed and consistency in deploying cloud infrastructure services. Businesses continue to increase their adoption of IaC templates each year, however, if left unchecked, it can introduce dangerous security and compliance risks within production cloud environments.
When it comes to assessing IaC security, many teams still rely on manual processes and a variety of open-source and developer-centric tools, which can be inconsistent across application teams. This can lead to fragmented data, complexity, and code sprawl. The reality is that security teams often struggle with little to no visibility over code development, and must navigate a growing and unwieldy range of policies and languages across the cloud stack. As a result, IaC security policies have to be written in different ways, depending on whether it’s Terraform, Pulumi, or another IaC type. Meanwhile, developers are increasingly working within decentralized application teams across the business, which can result in silos and friction between security and development teams.
Democratizing policy creation with OPA
Open Policy Agent (OPA) is an open-source project that uses a single policy language and policy engine to manage security policy as code. Its key advantages are:
- OPA is a framework that helps to translate written security policies into executable code that can be automatically assessed for every layer of the cloud stack.
- OPA provides a policy as code framework for treating policy as a first-class citizen.
- OPA enables policy to be decoupled from application code, so that policies can be updated without having to change or recompile an application.
As an open-source project, OPA is also supported by a growing ecosystem of contributors, users, and technology providers.
OPA provides developers, security, and other teams a centralized framework to manage and enforce both custom and industry standard best-practice policies across the organization. Teams can write policies via the Rego language – known for its simplicity – and consistently apply policy at every layer of the cloud-native stack. Using the OPA framework helps increase security through consistent policy validation, remove security friction via policy automation and independent lifecycle management, and improves operational efficiencies with centralized policy management.
That’s why Lacework is happy to announce that our industry-leading cloud-native application protection platform (CNAPP) now supports the OPA framework, featuring IaC as the first release.
Lacework welcomes OPA
Our OPA framework enables policy to be managed as a first-class citizen, like application code, through developer workflows in Git. As part of this framework, Lacework now enables teams to build custom IaC policies to meet the unique needs of a business, and address use cases that fall outside the scope of Lacework pre-built policies, derived from industry standard best practices. But how does it work?
To write custom policies, the policy is first authored in Rego, and using the CLI, committed into Git, and then uploaded into the Lacework platform, and visible in its GUI. Once Lacework is connected to a repository, or an on-demand assessment is initiated, we will automatically validate every policy against each commit, and pull request. Lacework returns the assessment results for each action back to the Git repository so developers receive findings within their existing Git tools and workflows. If violations are identified, teams have the option of either blocking the request, or allowing it to pass with notification of the found violations.
Block bad tags, and improve security hygiene
Let’s take a look at one of the key use cases. Lacework custom policies give developers a powerful means in which to enforce the proper tagging of IaC. Developers assign metadata to their cloud resources in the form of tags. For example, a CISO may mandate tags in Terraform for a database in Snowflake that houses sensitive financial information. These tags can indicate the business criticality of PCI data and should be labeled accordingly. Yet platform engineering, application developers, and security teams often use a variety of different nomenclature and tagging schemes.
With custom policies, the security team can spot any discrepancies in resources that may not have the appropriate tags for a particular project. Teams can write custom policies to ensure resources are properly tagged, and block code improperly tagged. In addition, organizations can create checks for items that fall outside of the security domain. Tagging is recommended as a best practice for cloud governance, and AWS, Microsoft Azure, and Google Cloud each provide their own guidance.
Centralized visibility into IaC security
We’re also excited to share that the IaC security technology from the Soluble acquisition has now been fully integrated into the Lacework platform. In unifying IaC security within the Lacework platform, we’ve aggregated all its data in one place, so developers, security, operations, and other teams can collaborate more efficiently. The Lacework UI provides centralized visibility into what IaC policies are applied, policy violations, suppressions, and the status of remediation efforts, so that teams can investigate and respond faster to IaC security risks that matter most.
With Lacework, teams can now easily assess the security of IaC within CI/CD services such as GitHub Actions, GitLab Pipelines, Jenkins, and CircleCI to ensure environmental parameters, like AWS us-west-1, are within policy.
With an OPA framework built into a single code to cloud security platform and a unified experience, Lacework is the connective tissue that empowers teams to transcend tech stack and operational silos to identify, investigate, and respond to cloud risk faster than ever before.
To learn more about Lacework and how you can secure your Infrastructure as Code, check out our solution brief.
Features referenced in this blog are now available to customers in preview.
Suggested for you