SECA API¶

The Sovereign European Cloud API (SECA) is a new, open standard for cloud infrastructure management, specifically designed to foster digital sovereignty and interoperability within Europe. Initiated by a few European cloud providers like Aruba and IONOS, its core mission is to provide a powerful, well-documented, and production-ready API that allows businesses and public sector entities to manage cloud resources without vendor lock-in. By adhering to OpenAPI standards, SECA aims to create a unified ecosystem, paving the way for a “EuroStack” and ensuring that Europe remains competitive and in control of its digital future.

Key Architectural Concepts and Features¶

Declarative, Kubernetes-Inspired Model: SECA adopts a declarative resource model heavily inspired by Kubernetes. Users define the desired state of a resource in a spec section, and the cloud provider’s platform is responsible for reconciling the actual state, which is reflected in a read-only status section.
Clear Resource Organization: Resources are structured hierarchically within a Tenant, which represents an organization, and further grouped into Workspaces. This provides logical isolation for different projects or teams.
Control Plane vs. Data Plane: The API makes a clear architectural distinction between the Control Plane and the Data Plane. The SECA specification exclusively covers the Control Plane, which handles the creation, configuration, and management of resources. The Data Plane, which involves direct access to the provisioned resources (like uploading a file to object storage), is considered outside the scope of this standard.
Standardized Resource Providers: The API is modular, organized into “foundation” providers for core IaaS components (Compute, Storage, Network) and allows for “extension” providers (e.g., Kubernetes, Load Balancer). This provides a baseline for compliance while allowing for innovation.
Robust Access Control: Security is foundational, mandating JWT (JSON Web Token) for authentication. Authorization is managed through a sophisticated, Kubernetes-like Role-Based Access Control (RBAC) model, where Roles define permissions and RoleAssignments link them to users (subjects).
Asynchronous Operations: Recognizing that provisioning infrastructure takes time, long-running operations like creating a virtual machine are handled asynchronously. The API returns a 202 Accepted status, and the client can poll the resource’s status to track progress.

Comparison with Existing APIs and Models¶

SECA vs. Proprietary APIs (AWS, Azure, Google Cloud)¶

The primary distinction between SECA and the APIs from hyperscalers like AWS, Azure, and Google Cloud lies in philosophy and objective.

Aspect	SECA API	Proprietary APIs (AWS, Azure, etc.)
Primary Goal	Standardization & Sovereignty: To create an interoperable, multi-cloud standard across European providers, preventing vendor lock-in and ensuring data sovereignty.	Ecosystem Integration & Lock-in: To provide a comprehensive but proprietary set of tools that deeply integrate users into a single vendor’s ecosystem.
Resource Model	Standardized & Abstract: Defines common resource types like `seca.compute/instance` and `seca.storage/block-storage` that all compliant providers must implement.	Vendor-Specific & Expansive: Offers a vast and ever-growing portfolio of unique, branded services (e.g., AWS EC2, S3, Lambda; Azure Virtual Machines, Blob Storage, Functions).
Authentication	Standardized (JWT): Mandates the use of JSON Web Tokens for authentication across all providers.	Vendor-Specific: Each provider has its own primary mechanism (e.g., AWS uses Signature V4, Azure integrates deeply with Azure Active Directory and OAuth 2.0).
API Design	Common Conventions: Enforces consistent RESTful patterns, naming conventions (kebab-case), and a unified resource hierarchy (`tenants/.../workspaces/...`) for all providers.	Proprietary Conventions: While generally RESTful, each has its own unique resource identifiers (AWS ARNs, Azure Resource IDs) and slight variations in API patterns.
Extensibility	Open Development Model: Allows the community and providers to propose and add new “extension” providers beyond the core “foundation” set.	Vendor-Controlled: New services and features are developed and released exclusively by the vendor.

The ambition of SECA is to provide a European-led alternative to the dominance of hyperscalers, focusing on creating a shared, competitive ecosystem rather than a single, all-encompassing platform.

SECA vs. Existing Open Standards and Open Source Projects¶

SECA vs. OCCI (Open Cloud Computing Interface)¶

When looking for direct parallels, the most relevant (though now largely inactive) open standard for IaaS management is OCCI.

Shared Goal: Both OCCI and SECA were created to be universal, RESTful APIs for cloud infrastructure management to promote interoperability and prevent vendor lock-in.
Key Difference - Modernization: OCCI was a product of an earlier cloud era. SECA represents a significant evolution, heavily influenced by the success of the Kubernetes API. SECA’s adoption of a declarative spec/status resource model is its core architectural advantage, aligning it with modern infrastructure-as-code and GitOps practices, a paradigm not present when OCCI was developed.

SECA vs. TOSCA (Topology and Orchestration Specification for Cloud Applications)¶

SECA and TOSCA are not competitors; they are complementary standards operating at different layers.

TOSCA is a modeling language that defines what an application’s infrastructure topology should look like.
SECA is the runtime API that an orchestrator would use to actually build the infrastructure described in a TOSCA file on a compliant cloud.

SECA vs. OpenStack¶

While SECA is a standard, OpenStack is a complete open source IaaS platform whose APIs have become a de facto standard in the private cloud space.

Shared Goal: Both provide APIs for managing core infrastructure components like compute, storage, and networking.
Key Difference - Spec vs. Implementation: SECA is a lightweight specification that any provider can implement, while OpenStack is a large, complex platform that one deploys. SECA’s Kubernetes-inspired design offers a more modern API experience compared to the more traditional architecture of the OpenStack APIs.

More Detailed Comparisons¶

1. Detailed Comparison: SECA vs. OCCI¶

While both standards aimed for a universal IaaS API, their design philosophies reflect the different eras in which they were created.

Feature / Concept	SECA Approach	OCCI Approach
Core API Paradigm	Declarative: The user defines the desired state in the `spec`. The server is responsible for making the actual state (in `status`) match the desired state. This is a reconciliation loop model (from Kubernetes).	Imperative & Action-Based: The user issues explicit commands (actions) to a resource (e.g., POST to `/compute/instance-1?action=start`). The API is a series of verbs acting on nouns.
State Management	Explicit `spec` and `status` objects: The difference between the user’s intent and the system’s reality is always clear and present in the resource model.	Implicit State: The state of a resource was simply its current set of attributes. There was no formal distinction between “desired” and “actual” state in the API model itself.
Authorization Model	Built-in RBAC: Specifies a detailed, Kubernetes-like Role-Based Access Control model with `Roles` and `RoleAssignments` as first-class API resources.	Implementation-Dependent: OCCI did not standardize an authorization model. It was left to the underlying cloud provider to implement and expose its own security mechanisms.
Extensibility	Resource Providers: The model is extended by adding new “foundation” or “extension” providers (e.g., `seca.compute`, `extensions.kubernetes`), which define new resource kinds.	Mixins: Extensibility was achieved via “mixins,” which were collections of attributes that could be dynamically applied to resources to add capabilities (e.g., adding an OS template mixin to a generic compute resource).
Resource Hierarchy	Opinionated and Structured: Mandates a `Tenant` -> `Workspace` hierarchy for clear multi-tenancy and project isolation.	Flatter and More Flexible: The core model was a collection of resources (e.g., compute, storage, network) without a strictly enforced grouping hierarchy in the specification itself.
Data Format	Strictly `application/json`: Aligns with modern web API development practices.	Multiple Formats: Supported various formats, including a unique `text/occi` representation and the ability to interact via HTTP headers, which offered flexibility but added complexity.

In summary, what does SECA have that OCCI lacks?

A declarative, state-driven API model (spec/status).
A built-in, standardized, and granular RBAC authorization framework.
A formal, structured hierarchy for multi-tenancy (Tenant/Workspace).

What did OCCI have that SECA handles differently?

OCCI had a very strong focus on HATEOAS (Hypermedia as the Engine of Application State), with a formal discovery mechanism where clients could query the root of the server (/-/) to discover all available resource types, mixins, and actions. While SECA is RESTful, its Kubernetes-inspired model relies less on hypermedia for discovery and more on the client having knowledge of the resource kinds from the OpenAPI specification.
- Open question: is this a good thing or a bad thing?

2. SECA API vs. OpenStack API¶

This is a direct comparison of the API specifications (SECA) versus the de facto standard APIs provided by the OpenStack project.

Aspect	SECA API	OpenStack API
API Paradigm	Declarative: A single `PUT` request defines or updates a resource’s desired state. The system handles the convergence.	Imperative: A series of explicit calls is needed to manage a resource’s lifecycle (e.g., `POST` to create, `GET` to check status, `PUT`/`PATCH` to modify, `DELETE` to remove).
API Structure	Unified Resource Model: Aims for a consistent feel across all resource providers, all sharing the `metadata`/`spec`/`status` structure.	Federated, Service-Oriented APIs: OpenStack is a collection of distinct services, each with its own API (Nova for compute, Cinder for storage, Neutron for networking, Keystone for identity). While integrated, they have different resource models and conventions.
State Management	`spec`/`status` Reconciliation: The API object itself is the source of truth for both desired and observed state.	Polling and Status Fields: A client creates a resource and then typically polls its `status` field (e.g., `BUILD`, `ACTIVE`, `ERROR`) to track its progress. The state is a simple attribute, not a rich object.
Authentication	Standardized (JWT): Every compliant provider must accept JWT Bearer tokens. Token issuance is handled by the provider.	Keystone-centric: Relies on a dedicated identity service, Keystone, which issues scoped tokens for authentication against other service APIs.
Versioning	Path-based: Versions are part of the URL (e.g., `/v1/`, `/v1beta1/`), applying to a whole resource provider.	Microversions: A more granular system where clients can request specific API feature sets via an HTTP header (e.g., `OpenStack-API-Version: compute 2.79`). This allows for non-breaking additions to be introduced and consumed incrementally.

The key difference is philosophical: SECA’s declarative model is designed for infrastructure-as-code and automated reconciliation, whereas the OpenStack API is a more traditional, imperative REST API well-suited for building workflows and user-facing dashboards.

3. How SECA and TOSCA Could Work Together¶

SECA and TOSCA are highly complementary, potentially forming a powerful stack for multi-cloud application deployment. TOSCA would define the “what” (the application blueprint), and SECA provides the standard API for the “how” (the infrastructure execution).

Here is a hypothetical workflow demonstrating their integration:

Step 1: Modeling the Application (TOSCA)¶

An application architect defines the entire application topology in a portable YAML file called a Service Template. This template would use custom TOSCA node types that directly map to SECA resource kinds.

service_template.yaml (simplified example):

tosca_definitions_version: tosca_simple_yaml_1_3

node_types:
  # Define a custom type that maps to a SECA instance
  tosca.nodes.SECA.Compute.Instance:
    derived_from: tosca.nodes.Compute
    properties:
      skuRef: { type: string }
      primaryNicRef: { type: string }
      # ... other SECA spec properties

topology_template:
  node_templates:
    my_network:
      type: tosca.nodes.SECA.Network # Custom type mapping to seca.network/network
      properties:
        cidr: { ipv4: "10.0.0.0/16" }
        skuRef: "skus/seca.n1k"

    my_vm:
      type: tosca.nodes.SECA.Compute.Instance
      properties:
        skuRef: "skus/seca.dm"
        primaryNicRef: "nics/my_vm_nic"
      requirements:
        - network:
            node: my_network

Step 2: Orchestration Engine Intake¶

A DevOps engineer submits this service_template.yaml to a TOSCA-compliant orchestration engine (e.g., Cloudify, or a custom-built orchestrator).

Step 3: Parsing and Execution Plan¶

The orchestrator parses the template, understands the resources (my_network, my_vm), their properties, and their relationships (the VM requires the network). It builds a dependency graph and creates an execution plan.

Step 4: Execution via SECA API¶

The orchestrator’s “SECA plugin” translates the plan into a sequence of SECA API calls to the target cloud provider:

It first issues a PUT /.../networks/my_network call with the specified spec.
It polls the status of the my_network resource until its state becomes active.
Once the network is ready, it issues a PUT /.../instances/my_vm call, referencing the now-created network.
It continues to monitor the status of all resources until the entire deployment is active.

Step 5: Day 2 Operations and Portability¶

The TOSCA template remains the single source of truth.

Scaling: To add another VM, the engineer updates the template, and the orchestrator makes the necessary PUT call.
Portability: To deploy the exact same application on a different SECA-compliant provider, the engineer simply points the orchestrator to the new provider’s SECA API endpoint. No changes to the blueprint are needed.

This workflow shows that TOSCA provides the high-level, portable application blueprint, while SECA offers the standardized, low-level API hooks that allow any compliant cloud to execute that blueprint consistently.

Page last modified: 2025-09-09 11:27:08