Skip to content
Aether Platform

Workload Identity (SPIFFE)

Aether Platform natively supports the SPIFFE (Secure Production Identity Framework for Everyone) standard. This provides a mechanism for microservices and AI agents (workloads) to securely authenticate with each other without using passwords or shared keys, complementing user (human) authentication.

What is Workload Identity?

In cloud-native environments, the lifespan of containers and Pods is short, and IP addresses change dynamically. Traditional authentication methods like “IP whitelisting” or “static API keys” are difficult to manage and pose high security risks.

SPIFFE is a standard protocol that defines “who (Identity)” a workload is, acting as a “Universal Passport for Multi-Cloud Environments.”

In Aether, every IDE workspace and agent execution environment is automatically issued an X.509 certificate called an SVID (SPIFFE Verifiable Identity Document) upon startup.

Implementation in Aether (Identity Runtime)

Aether integrates a high-reliability Identity Runtime in the backend and executes the following processes fully automatically:

  1. Workload Attestation: When a Pod starts, it verifies information such as Node ID, Namespace, and ServiceAccount to ensure it is a legitimate workload.
  2. SVID Issuance: Once verified, a short-lived X.509 certificate (SVID) is issued.
  3. Automatic Rotation: Certificates are automatically renewed (rotated) in the background, so developers do not need to worry about certificate expiration.

How to Use

Within the workspace, the certificate and private key are automatically mounted to specific directories via the CSI (Container Storage Interface) driver.

Getting Certificates

You can use standard SPIFFE-compliant libraries (such as go-spiffe) or read directly from the mounted paths.

  • Socket Path: /run/identity/sockets/agent.sock
  • Mount Path: /var/run/secrets/aether.io/

Example of Inter-Service Communication (mTLS)

NCS (Network Connectivity Service) leverages this SPIFFE ID to establish mTLS (mutual TLS) communication.

sequenceDiagram
    participant A as Service A (Frontend)
    participant B as Service B (Backend)
    participant S as Identity Server

    A->>S: Request ID (SVID)
    S-->>A: Distribute X.509 Cert
    B->>S: Request ID (SVID)
    S-->>B: Distribute X.509 Cert
    
    A->>B: Connection Request (mTLS)
    Note over A,B: Verify each other's certs
    A-->>B: Establish secure communication

Benefits

  • No Secrets: Eliminates the need to store API keys or passwords in source code or environment variables.
  • Fine-grained Authz: Strictly controls “which service can access which service” at the identity level, rather than just the network level.
  • Zero Trust: Does not trust proxies or infrastructure; enforces end-to-end encryption and authentication.

Detailed Identity Runtime Implementation

In the Aether Platform, the standard workload identity management functions are deployed in the EKS/NCS environment as follows:

Components

  1. Identity Server:
    • Acts as the Root of Trust.
    • Includes a built-in OIDC Discovery Provider, allowing external IdPs like AWS IAM to trust identities issued by the platform.
  2. Identity Agent:
    • Runs as a DaemonSet on each Kubernetes node.
    • Attests workloads (Pods) on the node and distributes SVIDs via a local Unix domain socket.
  3. CSI Driver:
    • Securely mounts SVIDs (certificates and keys) directly into the Pod’s file system.

Internal IdP Integration and Identity Brokering

The ID propagation flow that informs external IAM of “which user’s permissions the Pod is running under” is as follows:

  1. Attestation:
    • When a Pod starts, the Identity Runtime interacts with the Kubernetes API to verify its Namespace, ServiceAccount, and which user (Internal IdP ID) authorized its launch.
  2. ID Mapping:
    • The Identity Runtime issues an SVID containing the user attributes as part of the SPIFFE ID (or SANs).
  3. Identity Brokering to AWS:
    • The Internal IdP (or Identity Runtime) is registered as an OIDC Identity Provider in AWS IAM.
    • The workload inside the Pod uses its SVID to call AWS STS AssumeRoleWithWebIdentity to obtain a temporary IAM Role.
    • This enables access to remote tenant resources (e.g., S3 or other services) based on the user’s platform permissions.
graph TD
    User((User)) -->|Login| IdP[Internal IdP]
    IdP -->|Token| Aether[Aether Orchestrator]
    Aether -->|Launch| Pod[Workload Pod]
    
    subgraph "Aether Platform / EKS"
        Pod <--> Agent[Identity Agent]
        Agent <--> Server[Identity Server]
        Server -.->|Trust| IdP
    end
    
    Pod -->|AssumeRole| STS[AWS STS]
    STS -->|IAM Role| Target[External Resource / IAM]
    
    Server -.->|OIDC Federation| STS

Multi-Tenant Workload Identity

Based on the SPIFFE standard, it is technically possible for a single user (or a single workload) to hold permissions for multiple tenants. Aether achieves this through the following methods:

1. SPIFFE Federation

Establish mutual trust between different tenants (trust domains).

  • For example, Tenant B can be configured to trust SVIDs issued by Tenant A.
  • This allows a workload from Tenant A to access resources in Tenant B while maintaining its original identity.

2. Multiple SVIDs

The Identity Runtime can simultaneously provide multiple valid identities (SVIDs) to a Pod.

  • If a user belongs to multiple tenants, the Pod can obtain both a “Tenant A identity” and a “Tenant B identity,” switching between them based on the context.

3. Attribute-Based Access

Access decisions by downstream services or AWS IAM can be made based on attributes embedded within the SVID (e.g., a list of the user’s affiliated tenants).

To leverage advanced ID propagation via Identity Runtime, the Built-in IdP functionality must be set up beforehand.

  • Role of SCIM: Syncs user information from external IdPs (like Okta/Entra ID) to Aether, providing the platform with a “Source of Truth” for authorized users.
  • Role of Identity Runtime: Based on the synced user data, it issues an SVID to running Pods, certifying that “this Pod belongs to User A.”

Consequently, the operational procedure should follow the order of “IdP Integration via SCIM” → “Workload ID Management via Identity Runtime.” This ensures that human authentication and machine authentication are unified under a single identity fabric.

Conclusion: SPIFFE as a Multi-Cloud Identity

The true power of SPIFFE lies in its ability to function as a vendor-neutral Universal Control Plane that does not depend on a specific cloud provider (AWS, Azure, GCP, etc.).

  • Eliminating Vendor Lock-in: Enables service authentication across multi-cloud environments using a common certificate format, instead of being tied to specific AWS IAM or Azure Entra ID implementations.
  • Securing Hybrid Environments: Allows secure authentication using a common SPIFFE ID even when a cloud-based Pod is accessing an on-premises database.