Kubernetes policy management: I - Lay of the land

This is the first post of the series about Kubernetes policy management tools

Other parts:
II - OPA Gatekeeper
III - Kyverno
IV - jsPolicy

Setting the context
Managing Kubernetes configurations can be complex. Policies provide a way to define standards and best practice, and ensure consistent configurations across multiple clusters.
Though Kubernetes has several built-in mechanisms to ensure security, it is inherently not fully secure and lacks several aspects of security. For enterprise-grade security capabilities, Kubernetes infrastructure requires external security and lockdown capabilities such as access policies for individual pods, network policies, RBAC, and namespace access policies.

Policy Management
Kubernetes provides a declarative management interface. Users can specify the desired state of the system using API definitions, and Kubernetes controllers then work to make the current state match the desired state. This approach is used for managing cluster nodes and services as well as for managing application workloads.

A policy typically represents required configurations. Kubernetes natively provides inbuilt policies such as:

• Network Policies: to secure network traffic to and from pods (eg: no egress traffic out of DB pods)
• Pod Security Policy: to control privilege and access profiles for pods (eg: when using privileged pods)
• Quotas and Limit Range: to manage resource utilization and fairness (eg: number of pods per namespace)

These policies are helpful, but not straight forward to configure and there are situations where the pod specification needs finer level of vigil over individual options (eg: only pull images from internal registry, no latest tag ..))

What are the options?

• OPA Gatekeeper
  is an open source, general purpose policy engine. OPA decouples policy decisions from other responsibilities of an application, like those commonly referred to as business logic. OPA works equally well making decisions for Kubernetes, Microservices, functional application authorization and more, thanks to its single unified policy language.

• Kyverno is a policy engine that was designed with simplicity and Kubernetes in mind. It allows for the user to define a set of policies as Kubernetes resources, and can be used to validate, mutate, and generate additional Kubernetes resources. Plus, these policies don't require the user to learn a new programming language as they're written in YAML or JSON.

• jsPolicy a first-of-its-kind policy engine based on JavaScript, jsPolicy makes policies in Kubernetes clusters easier to manage and maintain, while also making them understandable and transparent.

Under the hood
Policy managers rely on the admission webhooks in the API request flow and use their internal engines to PASS or FAIL the request (or mutate as per the policy in case of a mutating webhook)

Who should enforce it
The platform team provides Kubernetes services and solutions to product development teams within the enterprise. The platform team would also be responsible for setting the policies for the security and proper configuration and operations of Kubernetes clusters and workloads – for example, by mandating that resource quotas are required on all shared clusters.

To scale Kubernetes usage, it is necessary that a central team is responsible for ensuring proper configuration of Kubernetes policies, and validation of other best practice guidelines, This is why policy management is becoming increasingly important for enterprise Kubernetes.