In 2026, Kubernetes has solidified its position as the de facto operating system for cloud-native applications. According to the CNCF Annual Survey 2024, a staggering 84% of organizations now run Kubernetes in production, with 90% leveraging containers. While this widespread adoption fuels innovation, it also magnifies the importance of robust security architectures. As a senior technical expert at Nuvelia, I frequently encounter organizations grappling with the complexities of securing their Kubernetes environments against an ever-evolving threat landscape. This article delves into three critical components of a modern Kubernetes security strategy: Pod Security Admission (PSA), OPA Gatekeeper, and Falco, providing a comprehensive guide for DevSecOps engineers, architects, and CTOs.

Securing Kubernetes is not a one-time task but a continuous journey demanding a layered defense-in-depth approach. Admission controllers provide a crucial line of defense at deployment time, while runtime security offers essential visibility into ongoing operations. Understanding how these tools complement each other is paramount for building resilient, compliant, and cost-optimized Kubernetes deployments. Nuvelia, specialized in Kubernetes deployments and security, helps organizations navigate these complexities, ensuring their infrastructure meets the highest standards.

The Foundation: Pod Security Admission (PSA)

Pod Security Admission (PSA) is a built-in Kubernetes admission controller that enforces baseline pod security standards. Introduced to replace the deprecated Pod Security Policies (PSPs), PSA offers a simpler, more streamlined approach to enforcing security best practices for pods.

From PSP to PSA: A Necessary Evolution

Pod Security Policies (PSPs) were powerful but notoriously complex to manage. Their cluster-wide nature, coupled with intricate RBAC requirements for binding, often led to operational overhead and misconfigurations. Kubernetes 1.25 officially removed PSPs, marking PSA as the standard for pod security enforcement. PSA simplifies this by applying Pod Security Standards (PSS) directly to namespaces via labels, making enforcement much more intuitive and auditable. PSS defines three security levels: Privileged, Baseline, and Restricted.

• Privileged: Unrestricted policies, allowing known escalations.
• Baseline: Minimally restrictive, preventing known privilege escalations.
• Restricted: Heavily restricted, enforcing current hardening best practices.

PSA Modes and Enforcement

PSA operates in three distinct modes, which can be applied independently to a namespace:

• enforce: Pods violating the policy are rejected.
• audit: Violations trigger an audit event but pods are still allowed. Useful for testing policies.
• warn: Violations generate a user-facing warning but pods are still allowed. Also useful for testing.

You define the desired PSS level and mode on a namespace using specific labels. For example, to enforce the restricted profile and audit baseline violations in a namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: secure-app-ns
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/audit-version: latest
    pod-security.kubernetes.io/warn: baseline
    pod-security.kubernetes.io/warn-version: latest

Implementing PSA: Practical Steps

To implement PSA, follow these steps:

1. Evaluate existing workloads: Start by applying audit or warn modes to namespaces to identify violations without disrupting services.
2. Update pod manifests: Adjust your pod specifications to comply with the chosen PSS level (e.g., set runAsNonRoot: true, remove host path mounts).
3. Enforce gradually: Begin with the baseline profile for most applications, then move to restricted for critical workloads.
4. Monitor: Regularly check audit logs for violations and adjust policies or pod manifests as needed.

For applications handling sensitive data, such as those processing electronic signatures or banking transactions, enforcing the restricted profile is often a regulatory requirement and a critical security measure. Compliance with evolving regulations like eIDAS 2.0 and its European Digital Identity Wallet initiatives necessitates stringent security controls at every layer of the stack.

Policy-as-Code with OPA Gatekeeper

While PSA provides a robust baseline for pod security, many organizations require more granular, custom, and dynamic policy enforcement across their Kubernetes clusters. This is where Open Policy Agent (OPA) Gatekeeper shines, offering a flexible policy-as-code solution.

Why OPA Gatekeeper? Beyond PSA

OPA Gatekeeper is an admission controller that leverages the Open Policy Agent (OPA) engine to enforce policies across a Kubernetes cluster. Unlike PSA, which is limited to predefined Pod Security Standards, Gatekeeper allows you to define custom policies using Rego, OPA’s declarative policy language. This enables:

• Custom policy enforcement: Beyond pod security, enforce policies on ingresses, services, namespaces, RBAC, and more.
• Contextual policies: Policies can consider labels, annotations, resource requests/limits, and even external data sources.
• Centralized policy management: Manage all your cluster policies from a single Git repository, aligning with GitOps principles.
• Audit and enforcement: Gatekeeper can audit existing resources for compliance and enforce policies on new or updated resources.

For organizations running Kubernetes on bare metal or managed cloud services like EKS/GKE/AKS, maintaining consistent security policies across diverse environments is a significant challenge that Gatekeeper addresses effectively.

Gatekeeper Architecture and Rego Policies

Gatekeeper works by deploying OPA as an admission webhook. When a resource (e.g., Pod, Deployment, Service) is created, updated, or deleted, the Kubernetes API server sends an admission request to Gatekeeper. Gatekeeper then evaluates this request against a set of policies written in Rego. If a policy violation is detected, the request can be mutated, audited, or rejected.

Policies in Gatekeeper are defined using two custom resource definitions (CRDs):

• ConstraintTemplate: Defines the schema and Rego logic for a class of constraints.
• Constraint: An instance of a ConstraintTemplate, specifying parameters and enforcement scope.

Practical Gatekeeper Policy Example

Let’s create a policy that mandates all pods to have CPU and memory requests and limits defined, a crucial practice for preventing noisy neighbors and ensuring resource predictability. This aligns with Kubernetes security best practices 2026: RBAC, NetworkPolicy, and image scanning, where resource management is key.

1. Define a ConstraintTemplate (e.g., k8srequiredresources.yaml):

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredresources
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredResources
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego:
        package: k8srequiredresources
        # Rego policy logic to check for resource requests/limits
        # This simplified example checks for existence, more complex logic can check values
        # We are checking for both requests and limits for CPU and Memory
        regoSourceCode: |
          package k8srequiredresources
          violation[{"msg": msg}] {
            container := input.review.object.spec.containers[_]
            not container.resources.requests.cpu
            msg := sprintf("Container %v in pod %v must have CPU requests", [container.name, input.review.object.metadata.name])
          }
          violation[{"msg": msg}] {
            container := input.review.object.spec.containers[_]
            not container.resources.requests.memory
            msg := sprintf("Container %v in pod %v must have memory requests", [container.name, input.review.object.metadata.name])
          }
          violation[{"msg": msg}] {
            container := input.review.object.spec.containers[_]
            not container.resources.limits.cpu
            msg := sprintf("Container %v in pod %v must have CPU limits", [container.name, input.review.object.metadata.name])
          }
          violation[{"msg": msg}] {
            container := input.review.object.spec.containers[_]
            not container.resources.limits.memory
            msg := sprintf("Container %v in pod %v must have memory limits", [container.name, input.review.object.metadata.name])
          }

Apply this template: kubectl apply -f k8srequiredresources.yaml

2. Create a Constraint (e.g., pod-resource-limits.yaml):

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredResources
metadata:
  name: pod-must-have-resources
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - default
  parameters:
    # No specific parameters for this simple example, as the logic is in the template
    # For more complex templates, parameters would be defined here to customize behavior

Apply this constraint: kubectl apply -f pod-resource-limits.yaml

Now, any pod deployed to the default namespace without defined CPU and memory requests/limits will be blocked by Gatekeeper. This level of granular control is essential for organizations seeking to optimize K8s cost and security, a service Nuvelia offers through its Thalaxo platform.

Runtime Threat Detection with Falco

Admission controllers like PSA and OPA Gatekeeper are powerful for preventing insecure configurations at deployment time. However, they cannot detect threats that emerge during runtime – after a pod has been admitted and is operational. This is where Falco, a CNCF graduated project, becomes indispensable for real-time threat detection.

The Need for Runtime Security in 2026

Even with stringent admission controls, a compromised application, a zero-day exploit, or an insider threat can lead to malicious activity within a running container. Traditional perimeter security tools often lack visibility into the granular process and system calls happening inside containers. Runtime security tools like Falco fill this gap by monitoring container behavior and alerting on suspicious activities. This is particularly crucial for financial services applications or those requiring advanced Strong Customer Authentication (SCA) under PSD2, where real-time anomaly detection is paramount.

How Falco Works: eBPF/Kernel Modules and Rules

Falco operates by observing system calls from the kernel, providing deep visibility into container activity without requiring modifications to the containers themselves. It achieves this through two primary drivers:

• eBPF Probe: The preferred, modern approach, leveraging eBPF to attach probes to kernel functions, offering high performance and safety.
• Kernel Module: A traditional approach, installing a kernel module to intercept system calls.

Falco then uses a powerful rule engine to compare observed behavior against a set of predefined or custom rules. These rules are written in YAML and can detect a wide range of suspicious activities, such as:

• A shell running inside a container.
• Sensitive files being read or modified.
• Outbound network connections to suspicious IPs.
• Unexpected process execution.
• Privilege escalation attempts.

Crafting Falco Rules for Critical Alerts

Falco comes with a rich set of default rules, but custom rules are essential for tailoring detection to your specific applications and threat model. Let’s look at a simple custom rule to detect if a shell is run inside a non-privileged container.

# /etc/falco/falco_rules.local.yaml

- rule: Detect Shell in Non-Privileged Container
  desc: A shell was spawned in a container that is not privileged.
  condition: >
    spawned_process and container and not container.privileged and 
    (proc.name in (shell_binaries)) and 
    not user_expected_shell_activity
  output: >
    Shell spawned in non-privileged container (user=%user.name 
    shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline 
    container_id=%container.id container_name=%container.name 
    image=%container.image.repository:%container.image.tag)
  priority: CRITICAL
  tags: [container, shell, security]

This rule leverages Falco’s rich set of fields (proc.name, container.privileged) and macros (shell_binaries) to define a precise condition. When this condition is met, Falco generates an alert with detailed context, which can then be forwarded to SIEM systems, Slack, or other incident response platforms. Implementing such fine-grained detection is a cornerstone of modern Kubernetes security best practices 2026.

A Layered Security Approach: PSA, Gatekeeper, and Falco

The true power of PSA, OPA Gatekeeper, and Falco lies in their combined application. They form a robust, multi-layered defense strategy, each covering different stages of the application lifecycle and addressing distinct security concerns.

Complementary Strengths for Defense in Depth

• PSA: Provides a standardized, easy-to-implement baseline for pod security, ensuring fundamental hardening at the namespace level. It’s the first line of defense for preventing common misconfigurations.
• OPA Gatekeeper: Extends admission control with highly customizable, policy-as-code capabilities. It enforces organizational-specific policies, compliance requirements, and resource governance across all Kubernetes resources, addressing complex security and operational needs beyond what PSA offers.
• Falco: Offers crucial runtime threat detection, acting as a security camera for your running containers. It catches anomalous behavior, privilege escalations, and potential breaches that bypass admission controls, providing real-time alerts for incident response.

Together, these tools create a comprehensive security posture:

1. Prevent: PSA and Gatekeeper prevent insecure configurations from ever being deployed.
2. Detect: Falco detects suspicious activities in real-time within running workloads.
3. Respond: Alerts from Falco integrate with incident response workflows, allowing for rapid mitigation.

This layered approach is critical for any organization operating Kubernetes in production today. Nuvelia offers expert Kubernetes security audits to assess your current posture and implement these advanced controls, ensuring your infrastructure is resilient against evolving threats.

Conclusion: Securing Kubernetes in a Dynamic Landscape

As Kubernetes environments continue to grow in complexity and criticality, adopting a proactive and multi-faceted security strategy is non-negotiable. Pod Security Admission provides the essential foundation, OPA Gatekeeper offers unparalleled flexibility for custom policy enforcement, and Falco delivers vital runtime threat detection. By integrating these powerful tools, DevSecOps teams can build and maintain secure, compliant, and observable Kubernetes clusters, confidently deploying and managing their applications in 2026 and beyond.

At Nuvelia, we help organizations not only secure their Kubernetes infrastructure but also optimize its performance and cost. Our expertise, including solutions like K8s cost and security optimization with Thalaxo, ensures that your cloud-native investments yield maximum value while maintaining an ironclad security posture. Navigating the nuances of these technologies requires deep expertise, and we are here to support your journey towards a more secure cloud-native future.