Skip to main content

Terminology

This glossary defines key terms used throughout Defakto's documentation. Understanding these concepts is essential for implementing and managing workload identity in modern distributed systems.

Some important concepts to start with:

Click here for an introduction to workload identity.

Agent​

An Agent runs on every node on which an identified workload runs. The agent manages the lifecycle of workload identities (SVIDs) by performing the following tasks:

  • requests SVIDs from the Defakto Signer on behalf of workloads
  • exposes the SPIFFE Workload API to workloads on the node and attests the identity of workloads that call it
  • provides the identified workloads with their SVIDs and trust bundle.

Attestation​

Attestation is the process by which a workload proves its identity to the system by providing verifiable evidence about its properties, such as its running environment, process attributes, or cryptographic signatures. The Agent collects this evidence and presents it to the Signer.

Bundle​

Also known as a “trust bundle” or "SPIFFE bundle". An object containing the public keys for a trust domain. Clients use the trust bundle to verify the authenticity of SVIDs issued by the trust domain signers. The trust bundle contains at least one X.509 certificate or one JSON Web Key.

Cluster​

In Defakto, a cluster or node group within a trust domain defines the SPIFFE ID path template, X.509-SVID Subject template, and JWT-SVID customization for all the Agents within the cluster.

Most commonly a cluster corresponds to a Kubernetes cluster, but it can also control the configuration for a collection of Linux machines or Docker containers.

Certificate Authority​

A Certificate Authority (CA) is a trusted third-party organization that issues digital certificates, which verify the identity of entities such as websites, individuals, or devices. The CA validates the identity of certificate requesters through various verification processes before cryptographically signing their certificates with the CA's private key, creating a chain of trust. Browsers, operating systems, and applications maintain lists of trusted root CAs, allowing them to automatically trust any certificate signed by those authorities or their intermediaries.

Federation​

SPIFFE Federation enables the authentication of SVIDs across trust domains. Specifically, it is the act of obtaining the necessary SPIFFE bundle(s) to authenticate SVIDs issued by a different trust domain, and providing said bundles to the workloads performing the authentication.

JSON Web Key​

A JSON Web Key (JWK) is a JSON data structure that represents a cryptographic key, including both public and private keys used in various cryptographic operations. They're commonly used alongside JWTs and other web security protocols for tasks like signature verification and encryption. The standard is defined in RFC 7517.

JSON Web Token (JWT)​

A JWT (JSON Web Token) is commonly used for authentication and authorization in web applications, enabling stateless session management. It is a compact, URL-safe format defined in RFC 7519.

Node​

The environment within which a workload runs. This could be a bare-metal machine, a virtual machine, a container, or a Kubernetes node. Each Node is attested by a single Agent.

Node Group​

See Cluster.

Path Template​

Each cluster is configured with its own platform-dependent path template that determines how a SPIFFE ID is generated. A path template always starts with a / since it refers only to the path of the SPIFFE ID and is prefixed by the trust-domain name when rendered. The path template may include workload and platform specific attributes that will be replaced by the workload's corresponding values provided by the agent.

For example, the default path template for Kubernetes is:

/{{cluster.name}}/ns/{{kubernetes.pod.namespace}}/sa/{{kubernetes.pod.service_account}}

In this case, there are Kubernetes-specific attributes (e.g. kubernetes.pod.namespace, kubernetes.pod.service_account) that are used to generate the SPIFFE ID.

Assuming a trust domain of spirl.example.com, a cluster name of edge-global, a namespace of prod and a service account named nginx, this template is rendered as the following SPIFFE ID:

spiffe://spirl.example.com/edge-global/ns/prod/sa/nginx

Signer​

The Signer is responsible for managing and issuing all identities in its configured trust domain. It synchronizes configuration information with, and sends telemetry data to, the Defakto Control Plane. It also sends public key material to the SPIRL control plane for distribution to clients and servers that need to verify SVIDs.

Agents connect to the signer to retrieve identities for workloads. Also referred to as the Server, TD-Server, Trust Domain Server, or spirl-server.

SPIFFE​

Short for “Secure Production Identity Framework for Everyone.” SPIFFE is a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments. Systems that adopt SPIFFE can easily and reliably mutually authenticate wherever they are running, whether in the context of a cloud provider or on-premises.

SPIFFE ID​

A specially-formatted URI, starting with “spiffe://”, that uniquely identifies a workload. The general format is as follows:

spiffe://trust-domain/workload-identifier

The trust domain component corresponds to the trust domain of the signer, and the workload identifier is generated by the agent using the path template and the attributes of the workload.

SPIFFE Workload API​

The SPIFFE Workload API is a standardized API that provides workloads with their cryptographic identities and trust bundles without requiring them to manage secrets directly. The API automatically delivers SVIDs in either X.509 or JWT formats, along with trust bundles containing the public keys needed to validate other workloads' identities.

SVID​

Short for “SPIFFE Verifiable Identity Document”, SVIDs are the actual credentials issued by the Signer. For the purpose of interoperability, they take one of two forms: (1) An X.509 certificate and (2) a JSON Web Token (JWT).

Trust Domain​

The root authority for a set of SPIFFE identities. Trust domains establish security boundaries between workloads. Each trust domain has its own SPIFFE bundle containing the cryptographic materials needed to validate identities—ensuring that identities from one trust domain cannot be validated by another trust domain's bundle.

As per the SPIFFE specification, a trust domain name is a strict subset of a DNS name. An example valid trust domain name is “dev.defakto.security”.

A trust domain can span an entire organization, a sub-unit like a department, or a purpose like “production” or “development”. The number of trust domains and the boundaries that they draw are necessarily organization-dependent.

X.509 Certificate​

An X.509 certificate is a digital document that binds a public key to an identity (such as a person, organization, or device) using a digital signature from a trusted Certificate Authority (CA). The certificate contains information about the key owner, the public key itself, the issuer's identity, validity period, and other metadata, all structured in a standardized format. X.509 certificates are the foundation of PKI (Public Key Infrastructure) and are widely used for securing communications in TLS/SSL, email encryption, code signing, and authentication. The standard is defined in RFC 5280.

Workload​

Software deployed for a specific purpose, with a particular configuration. It may run as a single instance, or thousands. A service running in on a bare-metal host in a data center is a workload. An application running in Kubernetes is a workload. An AWS Lambda Function is also a workload.