Skip to main content
🎀 Speaking at KubeCon EU 2026 Lessons Learned Orchestrating Multi-Tenant GPUs on OpenShift AI View Session
🎀 Speaking at Red Hat Summit 2026 GPUs take flight: Safety-first multi-tenant Platform Engineering with NVIDIA and OpenShift AI Learn More
Making Your Kubernetes Platform CRA-Compliant
Platform Engineering

Making Your Kubernetes Platform CRA-Compliant

If you sell a Kubernetes-based platform, the CRA applies to your entire stack. How to achieve compliance for container orchestration products.

LB
Luca Berton
Β· 1 min read

CRA for Kubernetes Platforms

If you sell a Kubernetes-based platform β€” whether a distribution, managed service, or enterprise product β€” the CRA applies to your entire stack. Here’s what needs attention.

Your CRA Attack Surface

Your Kubernetes Product:
β”œβ”€β”€ Container Runtime (containerd/CRI-O) β†’ Class II (EN 304 635)
β”œβ”€β”€ Linux Kernel/OS β†’ Class I (EN 304 626)
β”œβ”€β”€ Networking Stack (CNI) β†’ Potentially Class I (EN 304 625)
β”œβ”€β”€ Ingress/Gateway β†’ Potentially Class I
β”œβ”€β”€ Security Components β†’ Potentially Class II
β”œβ”€β”€ Management UI β†’ Default Product
└── CLI Tools β†’ Default Product

The Manufacturer Question

You are the manufacturer if you:

  • Package and distribute the Kubernetes platform
  • Place it on the EU market under your brand
  • Provide commercial support

Even if 90% of your platform is upstream open source, YOU are responsible for CRA compliance of the complete product.

Key Compliance Areas

1. SBOM for the Entire Stack

# Generate SBOMs at every layer
# OS layer
syft registry.internal/platform-os:latest -o cyclonedx-json > os-sbom.json

# Kubernetes components
syft registry.internal/kube-apiserver:v1.32 -o cyclonedx-json > k8s-sbom.json

# Your application components
syft registry.internal/platform-console:v4.0 -o cyclonedx-json > console-sbom.json

# Merge into a single product SBOM
cyclonedx merge --input os-sbom.json k8s-sbom.json console-sbom.json --output product-sbom.json

2. Vulnerability Response Across Layers

class KubernetesPlatformVulnHandler:
    UPSTREAM_SOURCES = {
        "kubernetes": "https://kubernetes.io/docs/reference/issues-security/",
        "containerd": "https://github.com/containerd/containerd/security",
        "linux": "https://www.kernel.org/category/releases.html",
    }
    
    async def handle_upstream_cve(self, cve):
        # Determine which layer is affected
        layer = self.identify_affected_layer(cve)
        
        # Check if we've integrated the affected version
        our_version = await self.get_bundled_version(layer)
        
        if self.is_affected(our_version, cve):
            # Start CRA reporting clock if actively exploited
            if cve.is_exploited:
                await self.start_enisa_reporting(cve)
            
            # Build patched version
            await self.trigger_patch_build(layer, cve)

3. Security by Design for Platform Components

# Pod Security Standards (enforce on your platform pods)
apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: restricted
  enforce-version: latest
  audit: restricted
  audit-version: latest
exemptions:
  namespaces:
  - kube-system  # Platform components may need elevated privileges

Practical Steps

  1. Map your components to CRA classifications
  2. Identify your manufacturer role β€” are you the entity placing the product on the market?
  3. Build layered SBOMs β€” OS, runtime, K8s, your code
  4. Monitor ALL upstreams β€” Kubernetes, containerd, Linux kernel CVEs
  5. Document your security architecture β€” CRA requires technical documentation
  6. Plan for third-party assessment β€” Class II components may require it

Building a Kubernetes platform for the EU market? I help organizations navigate CRA compliance. Get in touch.

Luca Berton Ansible Pilot Ansible by Example Open Empower K8s Recipes Terraform Pilot CopyPasteLearn ProteinLens TechMeOut