Styra Adds Declarative Tool to Generate Authorization Policies
Styra this week launched a declarative tool that enables cybersecurity teams to generate authorization policies that can be implemented programmatically by a DevOps team.
Company CEO Bill Mann said Rego Policy Builder for the Styra Declarative Authorization Service (DAS) is intended to help organizations bridge the divide between cybersecurity teams that define policies and developers that are increasingly being tasked with implementing them.
Rego is the native query language for open source Open Policy Agent (OPA) software, a general-purpose policy agent created by Styra that is now being developed under the auspices of the Cloud Native Computing Foundation (CNCF). Styra DAS provides a repository for policies that can be applied to Kubernetes environments. However, any policy created using Rego Policy Builder can be applied to any microservices or monolithic application that has embedded OPA. Those policies can also be stored and shared via Styra DAS.
OPA has already gained a significant amount of traction among DevOps teams looking to programmatically implement compliance and security policies. Rego Policy Builder provides a means for cybersecurity teams to leverage that work by employing a tool that allows them to declaratively define policies without requiring programming expertise. As such, it becomes simpler for cybersecurity and DevOps teams to collaborate while also maintaining a clear separation of concerns and responsibilities, noted Mann.
While there’s no doubt cybersecurity and DevOps teams need to collaborate more, getting the right tools in the hands of respective team members has been a challenge for many organizations. Styra is trying to bridge that gap in a way that enables organizations to construct an integrated set of DevSecOps workflows more easily, he said.
The advantage Styra brings to DevSecOps is that it’s easier to bridge the historic cultural divide between cybersecurity and developers now that OPA is starting to achieve a level of critical mass in terms of support among developers, Mann noted, adding it’s always easier to change the culture of an organization from the bottom up than from the top down.
Of course, each cybersecurity team will need to decide to what degree they will trust developers to implement policy controls. Developers often tend to overlook potential cybersecurity issues anytime application delivery deadlines become compressed, much to the indignation of cybersecurity teams, who later need to compile a list of known issues after an application has been deployed in a production environment. Of course, getting developers to focus on those issues when there are other applications to be built can also be quite problematic.
In the meantime, it’s clear cybersecurity teams need a faster way to generate policies if they hope to keep pace with the rate at which applications are now being built and deployed in the age of DevOps. DevOps teams won’t wait on cybersecurity teams to make available a cybersecurity policy. The expectation is the policy should be created as quickly as the code it is meant to secure. In the absence of that policy being readily available, DevOps teams will assume someone will add those policies during some future update cycle after the application is deployed regardless of whether the cybersecurity team agrees.
