Introduction

With the recent pace of innovation in cloud and cloud-native adoption, there has been a huge technological shift in the way applications are developed and deployed. This technological shift requires provisioning, managing, securing, and scaling cloud infrastructure and cloud-native workloads continuously.

Kubernetes v1.25 marks a major milestone to provide pod security via Pod Security Admission (PSA) and deprecates the formerly used Pod Security Policy (PSP). PSA is the preferred pod security system due to PSP’s complexity and its limitation in validating security controls at the time of Pod creation.

What is PSA in Kubernetes?

Kubernetes’ official security feature, namely, PSA, is a type of Admission Controller. Admission time security in Kubernetes refers to the process of controlling access to resources in a Kubernetes cluster during the admission phase, which is when a new resource is created or updated. This can involve validating and mutating the resource request before it is admitted into the cluster. Kubernetes provides admission controllers to enforce admission policies and enforce security, such as namespaces, resource quotas, network policies, etc. Admission controllers run as part of the API server and have the ability to reject a request before it is processed and stored in the cluster.

The scope of Pod Security Admission, as the name implies, is purely at pod-level, and this also provides a way to ensure validating controls over Pods and their attributes. Thus, PSA is an upgrade from PSP but differs in the following ways:-

• PSA sets the restrictions according to the three levels of Pod Security Standards (privileged, baseline, and restricted), and the restrictions are applied at the namespace level
• PSA helps to enforce 3 different Policies as Pod Security Standards –
  1) Privileged; 2) Baseline; 3) Restricted
• PSA helps to enforce the above Pod Security Standards in the cluster in 3 modes: 1) Enforce; 2) Audit; 3) Warn

What is Kyverno?

Kyverno is a CNCF Open Source incubating project which is also based on Dynamic Admission Control and enables cluster administrators to define, implement, and manage policies for their Kubernetes cluster by validation and mutation abilities. Its scope is only the Kubernetes cluster.

Kubernetes admission controllers provide basic admission control functionality, while Kyverno provides a more powerful and flexible policy engine for securing and managing Kubernetes resources. Kyverno extends the capabilities of Kubernetes admission controllers, providing a centralized policy enforcement mechanism, policy templating, and centralized policy management.

Kyverno helps to enforce security policies such as network segmentation, resource creation constraints, and secret protection, and it also integrates with the CI/CD pipeline which makes it more relevant to have as a Policy Management Tool in comparison to PSA to assess and control pre-deployment best practices within a K8s cluster. Kyverno can configure, secure, and manage policies for a Kubernetes cluster to some extent; however, to provide an overall security posture, Kyverno does not help to achieve runtime protection on running clusters from unknown vulnerabilities.

Kyverno provides the following features & capabilities within a Kubernetes cluster:

• Validation, Mutation, Generation, or Cleanup of resources
• Sync configuration across Namespaces
• Block or report non-conformant resources using admission controls
• Manifest Verification (Sigstore)
• Policy as K8s resources, Policy Audit Feature
• OpenAPI validation schema
• Self-service Reports & exception

Why do you need Kyverno++

In admission controllers like Kyverno or PSA, once the pods are running and governed with static policies, there is no support to have an approach to be proactive and prevent any unknown attacks by detecting a dynamic change in application behavior and auto-update existing policies based on detected changes.

Kyverno can ensure security and configuration best practices for clusters and workload at the admission time and therefore leaves the gap to have vulnerability management, micro-segmentation, end-to-end security visibility, securing of underlying infrastructure such as k8s cluster, host os, etc., and dynamic application behavior control at runtime. This gap can be bridged by AccuKnox to provide a complete security footprint for CI/CD pipeline.

It can append the feature of Kyverno with the following key points –

• Usually, it’s an effort to support complex policies with Kyverno but with AccuKnox’s ability to have more granular control on the Policies and the capability to dynamically update the Policy through continuous monitoring change in-app behavior.
• Append the capability of Kyverno with runtime protection support from AccuKnox.
• Append the capability of Kyverno to have end-to-end visibility of the infrastructure, app behavior at runtime, and protection from zero-day vulnerabilities
• Append the capability of Kyverno to support proactive remediation of security incidents from Kyverno’s ability to be reactive to the incidents.

What is AccuKnox / KubeArmor?

KubeArmor, a CNCF-based sandbox project by AccuKnox, can help understand runtime application behavior and auto-recommend contextual security policies leveraging eBPF methods.

Therefore, AccuKnox improves and protects the security posture of the cloud-native infrastructure and workloads above and beyond the admission controllers in the following context:

• App Hardening – Protect critical paths such as cert bundles, Generate Hardening Policies based on MITRE, STIGs, NIST, CIS-based compliance framework, Secure access to DB tale
• Least Permissive Access – RBAC, process/network/file executions whitelisting
• Microsegmentation – Communication graph between services/pods, Generate K8s network policies, service-binds/Ingress/Egress connections whitelisting
• Protect pure-containerized, Edge, 5G-based workload
• It helps security teams to define, design, develop, and defend continuously against any security threats and misconfigurations.

Additionally, AccuKnox also helps in dynamically populating changes in recommended policies when a change in configuration or application behavior is detected. The policies are managed using approval mechanisms and GitOps for version controls. The recommendation of policies is based upon the following processes which are getting forked, network access getting executed, and file systems getting accessed. Whenever there is an attack or unknown process execution, it will get blocked before execution leveraging LSMs (AppArmor, SELinux, BPF-LSM) to do in-line mitigation for that specific unknown request; hence it does not affect the overall application functioning.

AccuKnox vs Kyverno Comparison

In Summary

Admission Controllers (like Kyverno) combined with a run-time security platform like AccuKnox/KubeArmor provide a very robust layered security approach and offer Defense in Depth to protect Cloud Assets from Advanced Zero Day attacks.

KubeArmor is very well established as the proven Zero Trust security platform for Kubernetes workloads in the Cloud and well poised to benefit from Kubernetes adjacencies in the Edge/IoT, Data on Kubernetes (DoK), and 5G control plane security.

Join the KubeArmor Slack channel to contribute & communicate with the KubeArmor open-source community.

AccuKnox delivers full Enterprise-ready features and this is depicted below.

Reach out to us and we will be glad to lend you a hand.

Learn more about AccuKnox:

• 🌍Website:  Zero Trust Cloud-Native Application Protection Platform
• 📄Help Docs: Intro – AccuKnox
• 📝Blogs:  Blog