As more and more organizations move containerized applications into production, has become the de facto approach for managing those applications in private, public and hybrid cloud settings. In fact, at least 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.
Kubernetes authorization challenges
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 has remained constant: Security is often pushed out to the end. Today, and 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.
(OPA). OPA is an open-source policy engine, created by Styra, that provides a . Developers often find OPA to be a perfect match for Kubernetes because it was designed around the premise that sometimes you need to write and enforce access control policies — and plenty of other policies — over arbitrary JSON/YAML. As a policy-as-code tool, OPA leads to increased speed and automation in Kubernetes development, while improving security and reducing risk.
, which helps to validate OPA security policies in pre-runtime to see their impact, distribute them to any number of Kubernetes clusters, and then continuously monitor policies to ensure they’re having their intended effect.
project and CTO of . Before that, he co-founded the OpenStack Congress project and was a software engineer at VMware. Tim spent the last 18 years developing declarative languages for different domains such as cloud computing, software-defined networking, configuration management, web security, and access-control. He received his Ph.D. in Computer Science from Stanford University in 2008.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to .
Copyright © 2020 IDG Communications, Inc.