Attestation

This section outlines the types of attestation (both node and workload) that Cofide Connect supports.

Node Attestation

The following node attestation methods are currently supported in Connect:

Kubernetes

The k8s_psat (Kubernetes Projected Service Account Token) plugin attests nodes running inside Kubernetes clusters. The Cofide SPIRE agent presents a signed projected service account token mounted on the node, which the server validates against the Kubernetes API. This is the recommended attestation method for Kubernetes workloads.

SPIFFE ID format: spiffe://trust-domain/spire/agent/k8s_psat/CLUSTER/NODE_UID

Cloud Providers

Cofide SPIRE supports the OSS implementations of attestors for each of the major cloud providers, allowing for platform-issued tokens and metadata to be used to verify the identity of a VM scheduled on public cloud.

Plugin	Platform	SPIFFE ID format
`aws_iid`	Amazon Web Services	`spiffe://trust-domain/spire/agent/aws_iid/ACCOUNT_ID/REGION/INSTANCE_ID`
`azure_msi`	Microsoft Azure	`spiffe://trust-domain/spire/agent/azure_msi/TENANT_ID/PRINCIPAL_ID`
`gcp_iit`	Google Cloud Platform	`spiffe://trust-domain/spire/agent/gcp_iit/PROJECT_ID/INSTANCE_ID`

TPM Attestation

Trusted Platform Module (TPM) attestation provides hardware-rooted node identity, suitable for environments where strong cryptographic proof of node identity is required without an orchestration- or platform-layer. Common use cases include bare-metal, edge, and IoT deployments.

TPM attestation

How it works

TPM attestation relies on two cryptographic keys that the TPM manages:

Endorsement Key (EK): a keypair provisioned on the chip during manufacture. The private EK never leaves the TPM: only the public EK is shared. It serves as the hardware’s permanent, immutable identity.
Attestation Key (AK) : a temporary keypair generated on-demand inside the TPM by the Cofide SPIRE Agent at the start of each attestation cycle.

Attestation proceeds in three phases:

Key generation: The Cofide SPIRE Agent generates a fresh AK within the TPM and sends both the public AK and public EK to the Cofide SPIRE Server.
Challenge (MakeCredential): The Cofide SPIRE Server looks up the public EK hash against the Attestation Policies registered in the Connect control plane for the given Trust Zone. If a matching policy exists, the Cofide SPIRE Server uses the public EK to encrypt a secret nonce and mathematically binds the encrypted package to the public AK. This bound package is then returned to the Cofide SPIRE Agent.
Response (ActivateCredential): The Cofide SPIRE Agent passes the encrypted package to the TPM. To recover the nonce, the TPM must use both its private EK and private AK to decrypt the message. Successful recovery provides two guarantees: the hardware is genuine (only the true TPM holds the private EK), and the AK is bound to that specific node. The decrypted secret is returned to the Cofide SPIRE Server, which verifies it matches the original.

Once the nonce is verified, the Cofide SPIRE Server issues the node its SVID with the selector values defined in the matching Attestation Policy.

SPIFFE ID format: spiffe://trust-domain/spire/agent/tpm/EK_HASH

Workload Attestation

Workload attestation determines the identity of individual processes or containers on an already-attested node. These plugins run on the Cofide SPIRE Agent and interrogate the local runtime to produce selectors. More details on the upstream implementation of workload attestors can be found in the SPIRE documentation.

Plugin	Runtime	Example selectors
`k8s`	Kubernetes (via kubelet)	Namespace, pod name/UID, service account, container image, pod labels, node name
`unix`	Unix processes	UID, GID, username, group, binary path, SHA256 hash
`docker`	Docker containers	Container labels, image name
`systemd`	systemd units	Unit name, slice
`windows`	Windows processes	User SID, path

Workload selectors are combined with Attestation Policies to determine which SPIFFE ID a workload is issued. See Attestation Policies for more.