Defakto and Workload Identity

Introduction

Defakto provides each of your workloads with a SPIFFE Verifiable Identity Document (SVID) that represents the workload's identity. This identity remains consistent regardless of where your workload runs—whether you change runtime platforms, migrate between cloud providers, or scale across different infrastructure environments, your SPIFFE IDs can remain the same.

An SVID is a cryptographic document that uniquely identifies your workload and enables secure, authenticated communication with other services. Rather than relying on static credentials, provider-specific service accounts, or network-based security, this approach provides workloads with portable identities that are automatically rotated.

How Workload Identity Works

Before issuing an identity to any workload, the system must solve a fundamental security problem: how do we know who should receive an SVID? If identities are issued to the wrong party, they could impersonate legitimate workloads and compromise your system.

In workload environments, establishing this trust chains back to the underlying infrastructure platform itself. Every compute environment—whether it's an AWS EC2 instance, a Kubernetes pod, or a serverless function—can provide cryptographic evidence about what it is and where it's running. This evidence is called attestation.

Defakto Architecture

Defakto Control Plane

This is a cloud service that acts as the administrative interface and dashboard for the Defakto workload identity system. It distributes public key material and synchronizes configuration to the Trust Domain Servers. The control plane is highly available, and existing Servers and agents are resilient to a control plane outage or network partition.

The primary method of interacting with the control plane is the spirlctl command-line tool. Defakto also supports a Terraform provider that allows you to define your architecture in code.

Trust Domain

Each workload identity is issued for a specific trust domain. You can think of a trust domain as the root authority for a set of workload identities. A trust domain can span an entire organization, a sub-unit like a department, or a purpose like “production” or “development”. A workload that validates the workload identity of another workload typically requires the identity to be issued by a particular trust domain. Therefore, trust domains help segment your workload identities.

As an analogy, a trust domain is like a country that issues a passport, or a state or province that issues a driver’s license.

Trust Domain Deployment and Server

For each trust domain, a set of trust domain servers are deployed. The job of a trust domain server is to issue cryptographically signed SVIDs using keys under control of the server. Trust domain servers can only issue workload identities for their associated trust domain.

To ensure workloads can always obtain identities, trust domain servers should be deployed with high availability. Trust domain servers can be deployed across multiple regions in an active-active deployment. Each installation of trust domain servers is called a trust domain deployment, and each trust domain deployment can have multiple trust domain server replicas. Trust Domain Server replicas in a trust domain deployment share the same signing key and read their configuration from a single copy. The Defakto Control Plane gathers the public key material from all trust domain deployments into a global trust bundle for the trust domain. The global trust bundle makes it possible to validate the SVID of any workload in the trust domain regardless of the trust domain server and the trust domain deployment where it was issued.

Defakto Cluster

A Defakto Cluster is an environment where workloads run. The environment could be a Kubernetes cluster, a group of VM nodes, or a set of serverless functions.

Most Defakto clusters deploy an agent alongside the workloads on each node in the environment. The agent gathers information about the workloads and their environment (attestation), and sends this to the trust domain server for use in creating SVIDs. It presents a local API to the workloads so that they can request SVIDs.

In a serverless environment no agent is installed. Instead the serverless workload connects to the trust domain server directly to request an SVID. To attest the workload, the server expects the workload to present an identity proof usually signed by the underlying platform.

The lifecycle of an SVID

The SVID is the foundational document that workloads use to authenticate with services and each other. Workloads (or helper code) request an SVID from the Agent, which in turn communicates with a remote Trust Domain Server. The Agent gathers information about the workload and its platform, and sends that to the Server, which generates the workload’s SPIFFE ID and SVIDs.