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.

Cofide Native

The tpm Cofide SPIRE Agent plugin is a Cofide-native solution, integrating directly with your Connect control plane for scalable management of TPM-enabled node 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:

1. 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.

2. 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.

3. 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.

Connect Attestation Policies

As discussed in Concepts, an Attestation Policy maps a set of (node or workload) selectors provided by an attestor plugin to a SPIFFE ID, meaning that any workload which satisfies all of the selectors will be issued the corresponding identity document by SPIRE.

In Cofide Connect, there are three types of attestation policy:

Static Attestation Policies

Static attestation policies (APs) are the simplest class of AP in Connect. They map a static set of node or workload selectors to a fixed SPIFFE ID string with a particular parent SPIFFE ID. These policies are equivalent to SPIRE registration entries but are reusable across trust zones thanks to the separation of APs and attestation policy bindings in Connect.

See the Connect API reference for more details.

Kubernetes Attestation Policies

Kubernetes APs allow for a more dynamic configuration of workload attestation policies than the static equivalent. These policies require the Cofide Observer component to be installed on the workload Kubernetes cluster.

Instead of mapping directly onto SPIRE registration entries, these policies can use observed workload properties to dynamically create SPIRE registration entries. For example, creating a policy with

cofidectl attestation-policy add kubernetes --name foo --namespace bar

and binding it to one or more trust zones would enable any workload in namespace bar to be granted the SPIFFE ID spiffe://<trust-domain>/cluster/<cluster-name>/ns/bar/sa/<workload-service-account-name>.

It is also possible to customise the SPIFFE ID template granted to workloads which match Kubernetes APs by providing a Go template string to the --spiffeid-path-template argument. Valid template components are:

• .ClusterName
• .PodMeta.Namespace
• index .PodMeta.Labels “key” - Pod label value of a provided key
• index .PodMeta.Annotations “key” - Pod annotation value of a provided key
• .PodSpec.ServiceAccountName

The default SPIFFE ID path template is <trust-domain>/cluster/{{ .ClusterName }}/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}.

For more details on Kubernetes APs, see cofidectl attestation-policy add kubernetes -h or the Connect API reference.

TPM Node Attestation Policies

Trusted Platform Module (TPM) attestation policies are a Connect-native policy resource for onboarding bare-metal nodes into the Connect platform. For background see the above TPM attestation section or for more details on creating TPM policies in Connect, see cofidectl attestation-policy add tpm-node -h