ApeiroRA

Blog ​

  • From Urgency to Reality: Building the Crypto Broker

    · 12 min read

    In late 2022 we published "On the Urgency of Crypto-Agility" [^1], arguing that the quantum threat, together with NIST's then-unfinished Post-Quantum Cryptography (PQC) standardization, meant applications had to change how they consume cryptography. The argument came down to one rule: applications should not call cryptographic algorithms by name. They should delegate cryptographic operations to a configurable broker that can be updated without touching application code.

    Since then the deadline has moved closer. NIST finalized ML-KEM (formerly KYBER), ML-DSA (formerly DILITHIUM), and SLH-DSA (formerly SPHINCS+) in 2024 [^2], and organizations now face regulatory timelines for PQC migration. The whiteboard concept from 2022 is now a working open-source implementation, the Crypto Broker.

  • Sovereign Cloud Needs More Than a Region. It Needs Key Control.

    · 9 min read

    Sovereign cloud is one of the most overused terms in enterprise technology. It has been applied to everything from a datacenter in a specific country to a fully air-gapped, customer-operated deployment where no data or key material ever crosses an organizational boundary. The gap between those two definitions is enormous, and most organizations are sitting somewhere in the middle - believing they have sovereignty when what they actually have is geographic proximity.

    Regulators are tightening. NIS2 and DORA are pushing organizations to demonstrate not just that data is protected, but that they can prove it and act on it unilaterally. Customers are asking harder questions before signing contracts. Governments are mandating that critical infrastructure runs on infrastructure they control, not infrastructure they rent.

    The pressure is real. But the solutions being offered often fall short. A sovereign cloud label on a hyperscaler region. A compliance certificate that says the right things without changing who actually has access. Encryption that is on by default but governed by someone else.

    True sovereignty is not about where a server is located. It is about who holds the keys.

  • Workload Identity Should Come With the Cluster

    · 5 min read

    "Never trust, always verify", the zero-trust claim, has become the default advice for securing communication between workloads: assume the network is untrusted and authenticate every connection, even in-cluster. While it is good advice, it quietly assumes something that isn't always solved at scale: that every workload already has a verifiable and attested identity.

    Without a verifiable identity per workload, zero trust has nothing to check against. This post argues that instead of leaving this to individual teams, it should be a default capability of a managed Kubernetes offering.

  • Immersive Data Center Management: Advancing Sustainability and Operational Excellence

    · 9 min read

    Data center management is evolving rapidly, influenced by multiple forces, including the growing demand for operational transparency and the pursuit of measurable sustainability. As digital infrastructure becomes ever more critical to economic and societal functions, the expectations placed on data centers have evolved. No longer is it sufficient to focus solely on uptime and capacity; today's operators must also demonstrate environmental responsibility, regulatory compliance, and the ability to adapt to rapidly changing business and technology requirements. Apeiro's methodology, incorporating open reference architectures, semantic interoperability, and the integration of immersive technologies, constitutes a comprehensive framework designed to address emerging challenges and to advance the development of sustainable digital infrastructure standards.

  • AI Conformant Cloud Operating System for a Sovereign Europe

    · 5 min read

    We are thrilled to announce that Apeiro with its project Gardener is one of the first reference architectures to achieve official Kubernetes AI Conformance, as defined by the Cloud Native Computing Foundation. This significant milestone underscores our commitment to providing a robust, scalable, and reliable blueprint for running modern, resource-intensive AI and machine learning (ML) workloads in a sovereign European cloud-edge continuum.

  • Garden Linux: Enabling AI on Kubernetes with NVIDIA GPUs

    · 8 min read

    Artificial Intelligence (AI) has become essential for business innovation, enabling companies to unlock new revenue streams, automate processes, and make data-driven decisions automatically and at scale.

    There is industry-wide agreement that Kubernetes provides an ideal platform for running AI workloads (see Cloud Native AI Whitepaper). Furthermore, the CNCF community is in the process of defining infrastructure level AI Conformance which will make Kubernetes ubiquitous for AI workloads.

    But for Kubernetes to support GPUs, you need the worker nodes' operating systems enabled with the right GPU drivers and associated access frameworks.

  • From Desired State to the Status of a Resource

    · 13 min read

    In the last blog, we looked into the heart of Kubernetes' functionality, its API centric core model only dealing with the CRUD of typed documents, the externalized business logic in reconciling controllers, and their archetypes. In this blog, we will discuss the layout and specifics of Custom Resource Definitions (CRDs) used to extend the Kubernetes Resource Model.

  • Kubernetes API Server and Controller Archetypes

    · 14 min read

    Why is the status of a resource in Kubernetes so difficult to determine? Hard to believe, since we are talking about Kubernetes, the orchestration platform which made it so easy to deploy, scale and manage containerized applications. In the next few blog posts we will make a journey, starting to explore the Kubernetes Resource Model, the heart of Kubernetes' functionality. We will discover its responsibility and its declarative nature, visit afterwards the controllers and at the end will look at the resource manifests, where the users define the desired state but also the status has his home. When extending Kubernetes you are responsible in making the status meaningful, therefore we look at the end at some best practices for the status subresource.

  • Open Resource Discovery (ORD): A New Open Standard for Discovering Services, Events, and Data Products

    · 5 min read

    In complex enterprise environments, knowing which digital services, events, and data products are available — and how to integrate with them — is a well-known challenge. As businesses evolve, the ability to discover, understand, and consume digital offerings becomes increasingly critical. Open Resource Discovery (ORD), now an independent open standard under the Linux Foundation (via the NeoNephos Foundation), was designed to solve this challenge. It provides a standard, automated way for industries to describe and publish services, events, and data products directly from their source systems, making it an ideal foundation for digital collaboration and integration across platforms.

  • Security Compliance Automation

    · 14 min read

    Security compliance in Apeiro is built around continuous, automated evidence generation rather than manual point-in-time assessments. The foundation is the Open Component Model (OCM) as a shared coordinate system, giving every software component a unique, stable identity. Once every tool in the delivery chain uses the same component identity, vulnerability findings, deployment records, compliance evidence, and provenance data can be correlated automatically across the full software lifecycle.

  • Namespace Support in OpenBao: A Key Building Block for Apeiro Security Architecture

    · 3 min read

    The OpenBao project has just published the 2.3 Beta release with support for namespaces, a feature that introduces logical isolation within a single deployment. This enhancement allows the Apeiro Reference Architecture to securely separate sensitive information from different operator groups and trust domains across layers of the Apeiro stack.

    Major parts of the namespace feature were contributed by members of the Apeiro project, providing a solid foundation for multi-tenancy that spans beyond use cases of the multi-provider cloud-edge continuum.

  • The End of Kubernetes as We Know It: A New Era of Multi‑Tenant Control Planes

    · 13 min read

    Kubernetes is evolving. For nearly a decade, it has been the default choice to deploy and manage containers at scale – the go-to platform for container orchestration. However, Kubernetes today is no longer just a container orchestrator; it has grown into a foundational technology for modern infrastructure. While some people still try to create unified cloud standards or agree on some shared communication protocols[^10], they ignore the fact we already have this standard. Not by explicit choice, but by its success and adoption. Industry experts foresee Kubernetes becoming the common control plane spanning clouds, datacenters, and the edge​[^1]. This means Kubernetes provides a consistent way to manage containers and all kinds of workloads and resources across diverse environments, becoming de-facto the most widely adopted standard to manage services and resources.

    This transformation didn't happen overnight. The Kubernetes API and its resource model - often called the Kubernetes Resource Model (KRM) - have become an industry standard for declarative infrastructure management. Many open-source projects now extend Kubernetes well beyond running containers. For example, Crossplane, a Cloud Native Computing Foundation (CNCF) project, builds on Kubernetes to orchestrate "anything… not just containers"[^2], leveraging Kubernetes' reliability and integration capabilities with other tools​. Likewise, projects for certificates (cert-manager), secrets management, databases, and more are leveraging Kubernetes as a universal automation engine. The message is clear: Kubernetes has grown into a powerful general-purpose platform API for infrastructure.

    So what's the catch? As organizations embrace Kubernetes for more use cases, new challenges have surfaced with how we traditionally run Kubernetes.

  • Lifecycle Management - Configuration and Installation Reconsidered

    · 23 min read

    Software configuration and procedures, practices, and tools for (first time) installation, patching, or updating are at the heart of software lifecycle management.

    Generally, lifecycle management involves the parametrization and adaptation of a generic (installation) procedure. There are plenty of popular practices, tools, and environments, like Terraform, Chef, Ansible, package managers like APT, Crossplane or even Kubernetes (we will see later why this appears in this list). Configuration is then used to adapt the installation procedure to the needs of particular applications or their installations.

    There are several approaches to simplifying the description of controlling the installation procedure. From templating that leverages patterns and rules to avoid duplicate information, to complete general or product-specific Domain Specific Languages (DSL) that express complex configuration descriptions tighter to the problem domain than simple value structures. Those DSLs can be generalized by frameworks to shift the installer development from a general-purpose language to the composition of DSL elements.

    In the following, we will systematically describe what configurations look like and how they work together with installation and update procedures.

    While complex initial installations may be covered by the approach, we conclude with the argument that the optimization of configurations and configuration DSLs will not solve the automation problem for complex updates. Instead, the crucial aspect is the abstraction level between the configuration elements focusing on the problem domain and the finally maintained elements in their target environment. Complex updates require problem domain-specific flexible coding.

Funded by the European Union, NextGenerationEU; Supported by Federal Ministry of Economic Affairs and Energy on the basis of a decision by the German Bundestag

Funded by the European Union – NextGenerationEU.

The views and opinions expressed are solely those of the author(s) and do not necessarily reflect the views of the European Union or the European Commission. Neither the European Union nor the European Commission can be held responsible for them.

© 2024-2026 SAP SE or an SAP affiliate company. All rights reserved.

Logo of SAP SELogo of the Apeiro Reference ArchitectureLogo of the NeoNephos foundation
Want to connect? Reach out to us at apeiro@sap.com.
Legal Disclosure