Styra today announced it has extended the Styra Declarative Authorization Service (DAS) for automating compliance management to now include support for both microservices and the service mesh platforms that are relied on to manage them.
Company CTO Tim Hinrichs says Styra Declarative Authorization Service can now be employed to ensure compliance by attaching open source Open Policy Agent (OPA) software on which Styra DAS relies as a sidecar using containers.
That approach enables IT teams to attach policies more easily to an entire microservice, notes Hinrichs. That capability extends an existing ability to attach compliance policies to Kubernetes clusters using the Styra DAS cloud service that was launched last year.
Styra DAS applies controls to which application programming interfaces (APIs) can be executed on which services on both ingress and egress. That capability goes beyond what a service mesh currently provides by allowing more compliance context to be incorporated, notes Hinrichs.
OPA, which is now an incubation-level project being developed under the auspices of the Cloud Native Computing Foundation (CNCF), has been at the forefront of an effort to manage compliance as code within containerized applications for several years. Styra, which drove the original development of OPA, is now extending its software-as-a-service (SaaS) platform to apply policies based on OPA to both Kubernetes and the microservices deployed on a cluster.
That approach allows developers to programmatically achieve compliance without having to wait for a compliance team to make controls available. Instead, the compliance team simply needs to verify the proper controls are in place. In addition, because it’s now easier to document which controls have been applied by developers, the audit process becomes much smoother, Hinrichs notes. In fact, he adds, because the time required to conduct those audits is sharply reduced, most organizations reduce their compliance costs when responsibility for controls is shifted further left.
Shifting responsibility for compliance controls to the left also enables DevOps teams to better understand which controls are foundational to most applications versus which controls might be specific to particular compliance regulations. As a result, the development and deployment of compliant applications accelerate over time as DevOps teams become more familiar with which controls to apply in specific circumstances.
It’s not clear yet just how far left responsibility for compliance will shift left alongside security. However, given the fact that compliance is widely considered a baseline for achieving security, it’s probable DevOps teams will address both requirements within the same set of DevSecOps best practices. That’s especially critical as organizations adopt microservices-based applications that, while more flexible, are inherently more difficult to manage and update.
As always, however, the biggest issue is not so much getting everyone to agree to the need for those practices as much as it is simply getting the tools needed to achieve those goals into the hands of developers who, in many cases, would just as soon implement controls themselves instead of waiting for someone else to get around to it.