Using Open Policy Agent to Safeguard Kubernetes

Open Policy Agent addresses Kubernetes authorization challenges with a full toolkit for integrating declarative policies into any number of application and infrastructure components.

As more and more organizations move containerized applications into production,  Kubernetes  has become the de facto approach for managing those applications in private, public and hybrid cloud settings. In fact, at least 84% of organizations already use containers in production, and 78% leverage Kubernetes to deploy them, according to the Cloud Native Computing Foundation.

Part of the power and allure of Kubernetes is that, unlike most modern APIs, the Kubernetes API is intent-based, meaning that people using it only need to think about what they want Kubernetes to do — specifying the “desired state” of the Kubernetes object — not how they want Kubernetes to achieve that goal. The result is an incredibly extensible, resilient, powerful, and hence popular system. The long and short of it: Kubernetes speeds app delivery.

However, changes in a cloud-native environment are constant by design, which means that runtime is extremely dynamic. Speed plus dynamism plus scale is a proven recipe for risk, and today’s modern environments do indeed introduce new security, operational and compliance challenges. Consider this: How do you control the privilege level of a workload when it only exists for microseconds? How do you control which services can access the internet — or be accessed — when they are all built dynamically and only as needed? Where is your perimeter in a hybrid cloud environment? Because cloud-native apps are ephemeral and dynamic, the attack surface and the requirements for securing it are considerably more complex.

Moreover, Kubernetes presents unique challenges regarding authorization. In the past, just that simple word, “authorization” brought up the concept of which people can perform which actions, or “who can do what.” But in containerized apps, that concept has greatly expanded to also include the concept of which software or which machines can perform which actions, aka “what can do what.” Some analysts are starting to use the term “business authorization” to refer to account-centric rules, and “infrastructure authorization” for everything else. And when a given app has a team of, say, 15 developers, but is made up of dozens of clusters, with thousands of services, and countless connections between them, it’s clear that “what can do what” rules are more important that ever — and that developers need tools for creating, managing and scaling these rules in Kubernetes.

Because the Kubernetes API is YAML-based, authorization decisions require analyzing an arbitrary chunk of YAML to make a decision. Those chunks of YAML should define the configuration for each workload. For instance, enforcing a policy, such as “ensure all images come from a trusted repository,” requires scanning the YAML to find a list of all containers, iterating on that list, extracting the particular image name, and string-parsing that image name. Another policy might be, for example, “prevent a service from running as root,” which would require scanning the YAML to find the list of containers, iterating on that list to check for any container-specific security setting, and then combining those settings with global security parameters. Unfortunately, no legacy “business authorization” access control solutions — think role-based or attribute-based access controls, IAM policies, and so on — are powerful enough to enforce policies as basic as the one above, or even things as simple as changing the labels on a pod. They simply were not designed to do so.

Even in the rapidly evolving world of containers, one thing that has remained constant: Security is often pushed out to the end. Today, DevOps and DevSecOps teams are striving to shift security left in development cycles, but, without the proper tools, are often left to identify and remediate challenges and compliance issues much later on. Indeed, to truly meet the time-to-market goals of a DevOps process, security and compliance policy must be implemented much earlier in the pipeline. It’s been proven that security policy works best when risk is eliminated in the early phases of development, meaning it’s less likely that security concerns will arise toward the end of the delivery pipeline. 

Yet, not all developers are security experts, and manual reviews of all YAML configurations is a guaranteed path to failure for already overburdened DevOps teams. But you shouldn’t have to sacrifice security for efficiency. Developers need appropriate security tooling that speeds development by implementing hard guardrails that eliminate missteps and risk — ensuring that their Kubernetes deployments are in compliance. What’s needed is a way to improve the overall process that is beneficial to developers, operations, security teams, and the business itself. The great news is there are solutions built to work with modern pipeline automation and “as-code” models that reduce both error and exhaustion.

Deploying OPA at scale? Check out Styra Declarative Authorization Service for turnkey policy authoring, distribution and monitoring for Kubernetes security and compliance.

This article first appeared in InfoWorld on September 9, 2020.