IT Briefcase Exclusive Interview: How DevOps Teams Can Leverage Policy-as-Code to Scale Kubernetes

Kubernetes and containerization make application delivery much faster. But DevOps professionals hit a brick wall when they have to prove compliance to non-coders. In this QA, Styra security strategist Chris Webber talks to us from KubeCon in San Diego on how to bridge the communication gap between DevOps and Security/Compliance professionals.

• Q. What are the trends driving the move to cloud-native application architectures?

A. The business motivation for the move to cloud-native is a dramatically accelerated time-to-market for applications. Applications and updates can ship within hours, instead of months.

The technological motivation is a combination of elements. First, cloud-native application architectures provide specialization for developers; decoupling allows developers to focus only on the code that is relevant to their part of the application. Second, automation eliminates repetitive work and reduces human error. Finally, continuous integration and continuous delivery (CICD) facilitates peer review, agile development, analysis, rollback, and overall transparency.

• Q. How is security changing, or how should it change, to keep up with cloud-native trends?

A. The new developer world is more automated than ever with multiple releases a day and new code being added constantly. It’s also more complex than ever; even a single application requires countless containers and databases to interact properly, and to not allow unintended access. No human can keep up. No static policy can address the new world. There are infinite ways that things can go wrong and only a few ways they can go right.

These complexities can’t be addressed externally. The policy must be built into the infrastructure (the application components) itself. Infrastructure must be policy controlled, meaning it can only do what’s right. For example:

■       Only allow approved workloads to run in production,
■       Only allow the correct access between services, based on current context,
■       Only allow specific data to move between a given database and a given service, and
■       Require specific security config every time a new container is deployed.

• Q. How do evolving data privacy standards and laws play a role?

A. Consumers are becoming ever more aware of their online presence and the risks associated with it. We’re already seeing more regulation to protect identities and to limit the scope of what data can be accessed. The responsibility of businesses to protect personal data is only going to grow; as every company becomes an “app company,” the places where personal data resides is scaling incredibly quickly. Trying to enumerate every access possibility simply cannot be done at today’s cloud scale. Instead, the infrastructure must be built to only allow the correct access, at the correct time, based on the context. Everything else is simply blocked; that’s fundamentally what the Styra founders set out to achieve. We build the policy layer that works within the new cloud-native environment.

• Q. What are some of the challenges using Kubernetes at scale in the enterprise?

A. Kubernetes is moving from experimentation to production. The merits for control and reliability are clear. But any application —regardless of architecture or technology—has to be shown to be secure. It has to stand up to scrutiny by both internal and external stakeholders, whether that’s through some kind of internal compliance or mandated external regulation.

Our customers and our community have shown us that Kubernetes and cloud-native architectures add a new layer of new complexity here. Since these new architectures are software-defined and “everything-as-code,” the security and policy is also deployed as code. Auditors and IT security or compliance teams aren’t coders, though. Proving security for these new environments makes DevOps teams take a step backward; while the environment itself is highly automated and well understood by Devs and DevOps, it takes manual time and effort to prove how policy/security is implemented, since the audit and security people can’t read through the code and must be stepped through. We’ve heard horror stories of 60–90 day cycles sitting with auditors, just to walk through how all of the code has been designed to address policy. This manual effort and wasted time runs counter to the speed and automation that Kubernetes brings to development cycles.

• Q. In this evolving ecosystem, how are developers, compliance, and security teams going to be impacted? What advice do you have for them?

A. It is more critical than ever to work together to try and find a common point of view. Security folks might not be coders, but they know how attacks work. They know what has been proven in the past. Coders need to push applications out quickly and know how to build amazing experiences and reliability. Both sides must come to the middle—towards DevSecOps—and bring their strong expertise into a new policy-as-code model that will speed application development, free developers to focus on experience, and ensure security policy is applied more effectively than ever before.

To aid this, solutions like Open Policy Agent are already helping DevOps codify security and implement it as policy-as-code. Styra’s Declarative Authorization Service (DAS) makes it even easier to create those rules—from a built-in library or “policy pack” of rules that address specific requirements, such as PCI compliance. Equally critical, Styra DAS provides tooling to test, monitor, and prove the effectiveness of those rules—with simple graphical results—to show what’s allowed, what’d denied, and whether or not apps are indeed secure and/or compliant.

• Q. What improvements in compliance and policy governance will we see in 2020?

A. We’ll see a few improvements here:

■ Security engineering, or DevSecOps, will write more code, as opposed to manually validating or using “black boxes” and legacy tools for security and compliance checks;
■ More Kubernetes workloads will move into production, resulting in a lot of lessons learned and best practices for security and governance as the “new stack” becomes de-facto; and
■ Open source will rise in the minds of security practitioners, as CICD and peer review processes will add the transparency required to help to build end-user confidence.

About the Author

Security strategist Chris Webber specializes in cloud, network, and application security, mobility, virtualization, network architecture, and product go-to-market. Previously at SafeBreach and Centrify, Chris is VP of Marketing at Styra.