Minimize Kubernetes Compliance Audit Heartache

As Kubernetes matures and moves from exploration into production, we on the Styra and Open Policy Agent teams are starting to hear of a new trend. It’s part of any kind of operational lifecycle for many companies and it goes something like this:

DevOps: Our Kube environment is performant, secure, and compliant by design!

Auditor: K. Walk me through every line of code you typed since time began. 

Nobody ever said audits were fun, but they’re certainly easier when you can point to dedicated black boxes with big brand names that surround your infrastructure with policy. Auditors know what firewalls do. How VLANs help keep the wrong stuff out. They know a forward-proxy from a reverse-proxy. They know what RBAC means; they understand ACLs; and they know that there is likely a SecOps dashboard or 12 with red and green lights that help them understand what’s working and what’s not. Auditors have many, many years of experience looking at all that legacy IT Infrastructure Security stuff. (Heck, it’s all designed—at least in part—to be easy and clear for auditors to understand.)

… But auditors often don’t know how to code. 

And if they are made to bring in an expert, you’d better believe that the expert is going to pore through every line—for weeks—asking about intentions and demanding to prove them. It’s gonna be expensive, time consuming, and (if we are to believe the stories we hear every week) painful. (One SRE recently described it as “like going back to 1994, when everything was manually documented and audits took months.”)

Building compliance in to application environments is a good and positive trend. It’s definitely reached a high point. At the recent KubeCon, folks like ABN-AMRO bank took the stage to talk through the challenges of building—and sometimes proving—compliance. 

A theme at the show was: When the infrastructure is code, so too should policy be code. It’s the Right ThingTM. Moving to an “everything-as-code” mindset is truly better—better for devs, better for performance, and better for security, too. 

… But it isn’t yet better for auditors. 

In fact, without a way to prove that the underlying infrastructure policy is a) appropriate for the app and data being controlled, and b) “un-get-around-able” by internal and external parties, many enterprises are zipping forward with cloud-native environments only to hit a painful wall of compliance a few months later. Gone are the easily identified “security boxes” that auditors understand. Gone is the dashboard. Gone is the SecOps team to interview about how exceptions are handled and who signs off on them. In the new world, all of that has been replaced, and rightly so, with automation and with policy-as-code running right in the environment itself. Elegant. Simple. Portable. Immutable. 

… But to an auditor, it’s opaque, confusing, and intimidating.

We hear that it isn’t just external auditors who need a little boost here. It’s also internal IT security teams. These folks are experts at keeping threats at bay, monitoring and mitigating risk, and prioritizing where to invest in defenses, but they aren’t coders. These internal stakeholders’ jobs are literally on the line when a breach occurs. How can we assure them that our new app environments—containerized and virtualized ever further from their lines of defense—are indeed secure? How can we show that the services only do what they are intended to do—and no more? That only the right folks can access them and that they don’t run with too much privilege? That they can’t accidentally (or maliciously) steal traffic from other services or other apps? That they won’t grow and scale into stack overflow, or allow for remote compromise?

IT folks don’t need hand-holding. They don’t want to waste time having someone walk through lines of code explaining how things are architected to be secure. They just need testable, verifiable results of known good and known bad actions. They need to see that the expected, safe behavior is allowed and that anything else is stopped.

… But IT folks aren’t coders.

Like I said above, we hear these stories over and over from our community. DevOps wants to automate and simplify. Doing that means policy-as-code. Policy-as-code will eliminate the hassles of devs having to learn, remember, and write security into their apps. It will speed delivery and time to market. It will also be more secure, since the security is literally built into the environment and is much harder to thwart. 

So that’s all goodness—and that is all coding. The open source community is all over it. 

But when it comes time to sit across the table from a smart human with a different skillset, and explain how the security works and why it is compliant with specific regulations (internal or external), that pain can be real. 

Our customers are asking us to build a way to prove compliance to the less “code centric” members of our businesses. A way to show, in plain language, what the policy is meant to do. And, better still, a way to show (not read) that indeed it is working as planned. A way to test the code, without having to read or write the code. That’s why we are continually adding visualization and impact analysis to our code-centric solutions.

We know that coders don’t necessarily need GUIs to create and implement policy-as-code. But part of delivering quickly is being able to eliminate all potential areas of slowness; proving compliance with nothing but an IDE and a GitHub Repo certainly takes up an inordinate amount of time. We believe the value of policy extends beyond the developer; we’re glad that our Open Policy Agent community thinks that same way. That’s why Styra continues to invest our time in OPA, so developers can create the foundation of policy-as-code. We also provide Styra’s Declarative Authorization Service product—a turnkey solution that extends the value of policy to a broader set of users. We believe in everything-as-code and in the ability to prove it outside of code, as needed.

If you have to prove compliance and want to take some potential pain out of that game, let us show you how Styra’s Declarative Authorization Service can help build policy, and help prove its effectiveness as well!