Open Policy Agent as a Control Engine - DevSecOps Conf 2022 Recap

About

This content is brought to you by Jit - a platform that simplifies continuous security for developers, enabling dev teams to adopt a ‘minimal viable security’ mindset, and build secure cloud apps by design from day 0, progressing iteratively in a just-in-time manner.

‍

[The minimal viable security approach for developers; 4 critical controls; how to embed security controls into the CI/CD pipelines as code; OPA role and implementation demo]

JIT’s own CTO & Co-founder, David Melamed, had the opportunity to participate in KubeDaily’s DevSecOps Conf 2022 this weekend in partnership with Docker Bangalore and the CNCF, with a really great talk on Open Policy Agent as a Control Engine.

ICYMI, we have a really quick recap and highlights from the talk, and you can also watch it here (David’s talk starts at 55:00 minutes in):

This talk starts by introducing Open Policy Agent (AKA OPA) as a great tool you should have in your stack, particularly if you’re running a Kubernetes operation, which adds a layer of flexibility on top of common security controls in your CI/CD pipeline.

In this you will:

> Learn how to secure applications with a minimum-first approach (or what we call minimum viable security - MVS) and the most fundamental controls you’d need to get baseline security for your cloud native apps.

> Take a deep dive on these four critical controls:

• SAST - static application security testing
• SCA - security code analysis and third-party dependency checking
• Infrastructure as Code analysis
• DAST - dynamic application security testing, fuzzing, and app behavioral checks

> Watch a great demo on how to embed these security controls pretty simply into your CI/CD pipelines as code (at 1:04:45).

> Understand how OPA fits in, and can be added as a layer on top, to provide added control and flexibility.

TL;DW

The minimum viable security approach of embedding security controls as early as the first line of code was conceived to combat the accumulation of security debt from the very beginning.  If you’d ask a typical engineer what concerns them about their apps, they’ll usually place functional bugs and performance as their primary concerns, far before security.

This mindset is actually a byproduct of the perceived complexity around embedding security early, and knowing that it’s not just a one-off fix, that you can then forget about.  Security is a continuous journey and process.

That’s why the MVS approach was created, and it’s becoming an industry standard led by companies like Google, Slack & Salesforce, and Okta, and being practically applied through code with Jit.  MVS breaks down the daunting task of security into a small subset of controls that are easy to apply, and can be integrated as code from the very beginning.  This is in order to not overwhelm engineers with too much security overhead, and especially when these tools and controls are not inline with their typical workflow.

Once you implement these controls though, they don’t come without any cost - like any tools we add to our stack.  These tools are often are configured in different formats (JSON, XML, HTML, YAML…), are alert heavy leading to engineers ignoring “false positives'' through args and config files, each service has its own CI/CD pipeline, and not all findings require enforcement or a “control decision” - for example whether or not to fail a build based on the tool’s findings.

This talk provides an opportunity to learn about how OPA serves as an added control layer for centralized rules across your many services, and helps alleviate some of these challenges - all through live code examples.





Watch the OPA security demo to see how to leverage OPA for your microservices, and let us know what you think.