If you look at the recent history of security breaches, the vast majority are caused by configuration errors. This should be alarming for the Kubernetes community, because it is incredibly easy for configuration errors to slip into production in a containerized system. 

One of the reasons companies use Kubernetes is to take advantage of the platform’s flexibility and its declarative configuration management capabilities. But flexibility is not unambiguously a good thing: The vast number of knobs that users can adjust in a Kubernetes deployment make it easy to make mistakes, especially as organizations struggle to get their engineers past the Kubernetes skills gap. 

On the other hand, the declarative nature of Kubernetes offers a way to prevent mistakes. Kubernetes allows users to declare how they would like the system to be configured, and then Kubernetes will work to bring the system in line with the user’s intent. This is extremely powerful, and is what allows policy engines like Kyverno to work seamlessly with Kubernetes controllers. The problem is that without a policy engine on top of Kubernetes, the risk of a configuration error sneaking into production is high. 

Insecure by default

Both Docker containers and Kubernetes itself are insecure by default. The default configurations allow for root access, have lax access controls and don’t take advantage of RBAC, for example. This makes it easier for developers to get their code to run — but can have disastrous implications for security if not addressed. Hardening the environment involves changing the configurations — actually, changing an entire checklist of configurations. Particularly at scale, it is very easy for mistakes to happen. 

This is especially true if developers are made responsible for ensuring secure configurations. Developers aren’t security experts, and they aren’t usually evaluated based on how secure their applications are. That’s usually the responsibility of security or ops teams — and those teams should be able to directly control configurations. Otherwise, expecting them to ensure security is unreasonable. 

The role of policy engines

With a policy engine, it’s easier to apply blanket policies to all the Kubernetes clusters, reducing the risk of errors. A policy engine like Kyverno can validate configurations, both during development and runtime, but also generate and mutate configurations as well. Kubernetes is not only complex, it is also constantly changing. As the application runs, preventing configuration drift is important — and only possible with a policy engine that can not only validate configurations but also mutate them to ensure constant compliance with security policies. 

Generating new configurations on the fly

There are a number of situations in which new configurations have to be generated, and you want the configurations to be managed in a consistent, secure way every time. For example, there are configurations to manage every time a new namespace is created and many of those configurations are going to be the same every time. 

With a policy engine, admins don’t have to manually adjust configurations — instead, the policy engine will automatically generate configurations to handle access controls, network policies, resource usage limits and more. This takes responsibility for ensuring secure configurations away from developers and other users, allowing them to focus on delivering applications. Just as importantly, it gives security experts better control over security-related configurations, and changes the ‘default’ for namespaces in the organization from insecure to secure. It reduces the likelihood that inexperience, carelessness or simple error will cause a user to let an insecurely configured resource into production. 

Responding during runtime

Another way policy engines can help organizations improve their security postures is by reacting to pre-set triggers in the runtime environment. Humans will never have their eyes on the system 24 hours a day — and even if they did, Kubernetes generates so much information that without additional tools, it would be impossible for an operator to spot most signs of a security issue. With a policy engine like Kyverno, it’s possible to set up specific event-based triggers to ensure that the system can react automatically to signs of a security incident. 

Kyverno can watch for runtime triggers, like when a specific API request is made, when there’s an update or a status change, and react when necessary. This is already how Kubernetes manages scaling. When a predetermined threshold is met, the system knows to automatically add new pods and new resources to handle the increased traffic. With Kyverno, you can set policies based on a wide range of triggers that could indicate a security event and allow the policy engine to take action based on those triggers. This makes it easier to respond faster to potential incidents. By the time the system is sending an alert to an operator, it has already taken some action to neutralize the potential threat. 

Using a policy engine like Kyverno can help ensure configurations are as tight as possible, give more control over security to the organization’s security experts and help organizations respond instantly to anomalous behavior. Try it out now.