Choosing a Kubernetes Policy Engine: OPA/Gatekeeper vs Kyverno vs Pod Security Admission

Choosing a Kubernetes Policy Engine#

Kubernetes does not enforce security best practices by default. A freshly deployed cluster allows containers to run as root, pull images from any registry, mount the host filesystem, and use the host network. Policy engines close this gap by intercepting API requests through admission webhooks and rejecting or modifying resources that violate your rules.

The three main options – Pod Security Admission (built-in), OPA Gatekeeper, and Kyverno – serve different needs. Choosing the wrong one leads to either insufficient enforcement or unnecessary operational burden.

Data Classification and Handling: Labeling, Encryption Tiers, Retention Policies, and DLP Patterns

Data Classification and Handling#

Data classification assigns sensitivity levels to data and maps those levels to specific handling requirements — who can access it, how it is encrypted, where it can be stored, how long it is retained, and how it is disposed of. Without classification, every piece of data gets the same (usually insufficient) protection, or security is applied inconsistently based on individual judgment.

Defining Classification Tiers#

Most organizations need four tiers. Fewer leads to overly broad categories. More leads to confusion about which tier applies.

Data Sovereignty and Residency: Jurisdictional Requirements, GDPR, and Multi-Region Architecture

Data Sovereignty and Residency#

Data sovereignty is the principle that data is subject to the laws of the country where it is stored or processed. Data residency is the requirement to keep data within a specific geographic boundary. These are not abstract legal concepts — they dictate where you deploy infrastructure, how you replicate data, and what services you can use.

Get this wrong and the consequences are regulatory fines, contract violations, and loss of customer trust. GDPR fines alone have exceeded billions of euros since enforcement began.

FIPS 140 Compliance: Validated Cryptography, FIPS-Enabled Runtimes, and Kubernetes Deployment

FIPS 140 Compliance#

FIPS 140 (Federal Information Processing Standard 140) is a US and Canadian government standard for cryptographic modules. If you sell software to US federal agencies, process federal data, or operate under FedRAMP, you must use FIPS 140-validated cryptographic modules. Many regulated industries (finance, healthcare, defense) also require or strongly prefer FIPS compliance.

FIPS 140 does not tell you which algorithms to use — it validates that a specific implementation of those algorithms has been tested and certified by an accredited lab (CMVP — Cryptographic Module Validation Program).

Infrastructure Security Testing Approaches

Choosing the Right Testing Approach#

Infrastructure security testing is not one activity. It is a spectrum from fully automated scanning to manual adversarial testing. Each approach has different costs, coverage, and compliance implications. Choosing wrong wastes budget on low-value scans or leaves critical gaps unexamined.

The core decision is: what are you trying to learn, and what constraints do you operate under?

Decision Matrix#

Question Automated Scanning Kubernetes-Specific Testing Network Scanning Manual Penetration Testing
What does it find? Known CVEs, misconfigurations, missing patches K8s-specific misconfigurations, RBAC issues, pod security gaps Open ports, exposed services, protocol weaknesses Business logic flaws, chained exploits, privilege escalation paths
How often? Continuous or daily Every cluster change, weekly minimum Weekly to monthly Annually or after major architecture changes
Who runs it? Automated pipeline or security team Platform/SRE team Security team or automated Specialized pentest firm or red team
Cost Low (tooling cost only) Low (open-source tools) Low to medium High ($20k-$100k+ per engagement)
False positive rate Medium to high Low Medium Very low
Compliance fit PCI-DSS 11.2, SOC2 CC7.1 CIS Kubernetes Benchmark PCI-DSS 11.2, NIST 800-53 PCI-DSS 11.3, SOC2 CC4.1

When to Use Each Approach#

Use automated scanning when you need continuous visibility into known vulnerabilities across your infrastructure. This is the baseline. Every organization should run automated scans regardless of what other testing they do.

Kubernetes Audit Logging: Tracking API Activity for Security and Compliance

Kubernetes Audit Logging: Tracking API Activity for Security and Compliance#

Audit logging records every request to the Kubernetes API server. Every kubectl command, every controller reconciliation, every kubelet heartbeat, every admission webhook call – all of it can be captured with the requester’s identity, the target resource, the timestamp, and optionally the full request and response bodies. Without audit logging, you have no record of who did what in your cluster. With it, you can trace security incidents, satisfy compliance requirements, and debug access control issues.

Regulatory Compliance Frameworks: HIPAA, FedRAMP, ITAR, and SOX Technical Controls

Regulatory Compliance Frameworks#

Regulatory compliance translates legal requirements into technical controls. Understanding which regulations apply to your system and mapping them to infrastructure and application design is a core engineering responsibility in regulated industries.

This guide covers four major frameworks and their practical implications for software architecture. These are not exhaustive compliance guides — they map the most impactful technical controls for each framework.

HIPAA (Health Insurance Portability and Accountability Act)#

HIPAA applies to organizations handling Protected Health Information (PHI) — any data that can identify a patient and relates to their health condition, treatment, or payment.

Security Compliance and Benchmarks

Why Benchmarks Matter#

Security benchmarks translate “harden the cluster” into specific, testable checks. Run a scan, get a pass/fail report, fix what failed. CIS publishes the most widely adopted benchmarks for Kubernetes and Docker. NSA/CISA provide additional Kubernetes-specific threat guidance.

CIS Kubernetes Benchmark with kube-bench#

kube-bench runs CIS Kubernetes Benchmark checks against cluster nodes, testing API server flags, etcd configuration, kubelet settings, and control plane security:

# Run on a master node
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-master.yaml

# Run on worker nodes
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-node.yaml

# Read results
kubectl logs job/kube-bench

Or run directly on a node: