---
title: 'Keylime: Kubernetes Attestation & Trust'
url: https://www.emergentmind.com/topics/keylime
type: topic
---

# Keylime: Kubernetes Attestation & Trust

Keylime is an open-source framework used as an attestation workflow, trust-state management, policy enforcement, and integration layer between a verifier, attestation agents, and TPM-backed evidence in Kubernetes-based systems. In recent arXiv literature, it is presented both as the orchestration layer that turns TPM 2.0 and Linux Integrity Measurement Architecture (IMA) from low-level trusted-computing primitives into a practical, continuous attestation system for 5G network functions running as Kubernetes pods, and as the attestation and secure-enrollment backbone for bringing physically exposed edge devices into a Kubernetes cluster as trusted worker nodes [2510.03219; 2405.10131]. Across these settings, the defining premise is that a node or workload should not be trusted merely because it was authenticated at startup; instead, trust is continuously re-evaluated at runtime in alignment with Zero Trust principles of “never trust, always verify.”

## 1. Functional role in Kubernetes-centric trust architectures

In its standard form, Keylime is designed for node-level trust management. A tenant defines policies and allowlists, a verifier periodically challenges attested machines, and an agent on each node gathers evidence from the TPM and IMA and returns it to the verifier. This organization makes Keylime the mechanism that operationalizes remote attestation as an ongoing control process rather than as a one-time bootstrap check [2510.03219].

The two cited deployments place Keylime in distinct but related roles. In the 5G VNF setting, it is the continuous verification mechanism for cloud-native telecom workloads, with the verifier deciding not only whether a worker node is healthy but also whether the specific pods running on that node match their expected integrity baseline. In the cloud-native edge setting, it is the attestation and secure-enrollment backbone through which an edge device proves boot integrity through TPM-rooted attestation before it is granted a unique Kubernetes identity and role-based access control (RBAC) permissions; if attestation later fails, those permissions are revoked [2405.10131].

A common misconception is that authenticated admission is equivalent to ongoing trust. The 5G study explicitly rejects that assumption: current 5G security specifications focus on communication security and assume that network functions remain trustworthy after authentication, consequently lacking mechanisms to continuously validate the integrity of VNFs at runtime. Keylime is valuable in that context because it supplies the missing continuous verification layer.

## 2. TPM, IMA, and the evidence model

The TPM 2.0 integration supplies the hardware root of trust. The TPM maintains Platform Configuration Registers (PCRs), which hold cumulative digests of measured software and boot components. During boot, the firmware, BIOS, bootloader, and kernel are measured into PCRs, establishing a trusted boot chain. At runtime, Linux IMA extends this chain by measuring executables and other critical files and extending their hashes into PCR 10. The TPM also provides an Attestation Key (AK), a non-migratable signing key used to quote PCR values, and in the edge-enrollment workflow the endorsement key (EK) certificate signed by the TPM manufacturer is used for identity verification [2510.03219; 2405.10131].

IMA provides the runtime measurement evidence through the Measurement List (ML), an append-only log of file and executable hashes collected as they are accessed or loaded. Each ML entry is produced according to the active IMA template, and the digest of the template entry is extended into PCR 10. The verifier therefore checks two things at once: first, that the quoted PCR 10 is valid and signed by the TPM; and second, that the ML re-hashes to the same PCR 10 value. If those match, the measurement log is cryptographically bound to the platform state. The entries themselves are then compared against a whitelist of known-good digests to determine whether the software state is expected [2510.03219].

The edge-enrollment work explicitly distinguishes measured boot from secure boot. Measured boot extends digests of boot components into TPM PCRs, creating a record an external verifier can inspect, whereas secure boot verifies signatures and stops the boot if a signature is invalid. The architecture relies on measured boot because attestation must be externally verifiable. The boot chain is anchored in the CRTM (core root of trust for measurement), which is treated as the immutable root, and the absence of a proper CRTM is identified as a limitation on many edge devices [2405.10131].

## 3. Attestation workflow and trust-state semantics

The generic remote attestation workflow is nonce-based. The verifier sends a challenge, the agent retrieves the TPM quote and IMA log, and the verifier validates the quote, recomputes the measurement log digest, and checks the measurements against the whitelist. Formally, the attestation logic can be summarized as follows: the verifier sends a challenge nonce and requests a quote over selected PCRs; the agent returns `quote + IMA ML + nonce`; the verifier checks the signature on the quote, recomputes the digest of the IMA measurement list, verifies that the recomputed digest matches the quoted PCR 10 value, and then compares the measurement entries against approved allowlists. If any of these checks fail, the relevant trust state becomes `Untrusted` [2510.03219].

In the 5G deployment, the workflow is layered. Each worker node registers with Keylime’s registrar using TPM credentials such as EK and AK certificates or public keys. The tenant supplies the verifier with a node allowlist, pod-specific allowlists, optional exclusions, and TPM policy parameters like the PCR mask. During each continuous attestation cycle, the verifier issues a nonce challenge, the agent on the worker node requests a TPM quote over PCR 10, collects the current IMA measurement list, and returns an integrity report containing the quote, the ML, and the nonce over mTLS. The paper describes trust states such as `Start`, `Trusted`, and `Untrusted`. If all measurements match the baseline, the pod or node is marked `Trusted`; if an unknown pod appears or a registered pod deviates from its whitelist, that pod is marked `Untrusted` [2510.03219].

In the edge-enrollment architecture, Kubernetes-native lifecycle states are used instead: `unregistered`, `registered`, `attested`, and `unattested`. The `EdgeNode` custom resource stores the TPM identity and reference measurements, and its status transitions drive the process. After successful registration with the registrar, the status becomes `registered`; after successful attestation it becomes `attested`; if attestation later fails, it becomes `unattested`, which triggers revocation of permissions [2405.10131].

The difference in state vocabularies reflects different control objectives. In one case the emphasis is continuous integrity classification for nodes and pods; in the other, the emphasis is admission and authorization control for an edge worker’s cluster identity. A plausible implication is that Keylime’s architecture is not tied to a single trust-state ontology, provided that the verifier’s judgment can be propagated into the surrounding control plane.

## 4. Pod-aware extensions for 5G VNFs on Kubernetes

The 5G study’s distinctive contribution is a custom IMA template that isolates pod-level measurements. By default, IMA produces a single measurement log per node, which mixes host and container activity and therefore cannot distinguish which pod caused a given measurement. The authors solve this by extending the IMA template with a `cgpath` field that records the cgroup path associated with each process. In k3s, Kubernetes pod cgroups have recognizable path prefixes such as `kubepods` and `/rancher/k3s`, which lets the verifier map each measurement entry to a specific pod UID. This mapping is used to bind measurements to pod UIDs and to separate system-level entries from pod-level entries, enabling different allowlists and different trust labels for each [2510.03219].

This extension changes the granularity of attestation. Rather than merely asserting that a worker node is trusted, the verifier can determine whether specific pods such as AMF, SMF, and UPF are trusted or untrusted. Importantly, the node may still remain trusted even if one pod fails attestation, which enables layered containment rather than whole-node failure. That behavior is central to the paper’s Zero Trust framing because enforcement becomes targeted rather than blunt.

The deployment is a concrete k3s-based prototype. The cluster consists of one master and two worker nodes running Ubuntu 20.04.6 with an IMA-enabled custom Linux kernel and discrete TPM 2.0 devices. The 5G core is built from the OpenAirInterface implementation and deployed as Kubernetes pods. The master node runs Keylime’s verifier, tenant, and registrar alongside the standard Kubernetes control-plane services. Worker 1 hosts support and control functions such as MySQL, NRF, AUSF, and UDR. Worker 2 hosts the main 5G core network functions AMF, SMF, and UPF. Each worker node includes a TPM 2.0 device, IMA, and a Keylime agent. Kubernetes components such as kubelet, kube-proxy, and the CRI manage pod execution, while the verifier continuously attests both node- and pod-level integrity [2510.03219].

The selective validation experiment shows the operational consequences of pod-aware attestation. The verifier was configured to monitor files under `/usr/bin`, so that unexpected binaries would be easy to spot. On Worker 1, most pods remained `Trusted`, but the AUSF pod was flagged `Untrusted` because the measurement log contained binaries that were not in its allowlist, including `/bin/cat`, `/pause`, `/bin/busybox`, and `/usr/bin/curl`. On Worker 2, AMF, SMF, and UPF all remained `Trusted`, showing that compliant pods continue operating normally while a compromised pod is isolated by policy. The verifier output provides forensic detail about the exact binaries or files that caused the violation, and Kubernetes can reschedule the compromised pod with a fresh Pod UID, restoring a clean state without disrupting trusted workloads [2510.03219].

## 5. Edge-worker enrollment, controller integration, and RBAC gating

The cloud-native edge architecture inserts a Kubernetes-native controller between the cluster and a modified Keylime deployment. The edge device remains outside the cluster until trust is established, but the cloud-side Keylime components and the controller cooperate to manage the node’s lifecycle. The custom `EdgeNode` Kubernetes resource is the pivot, storing the TPM identity and reference boot state and receiving status updates from modified Keylime components [2405.10131].

Several practical modifications are made to Keylime. A REST API is added on top of the tenant so the Kubernetes controller can invoke it directly, avoiding manual command-line operation, external bash scripts, and repeated disk read or write cycles. The verifier is extended with a third notification mode, native Kubernetes revocation, using the Kubernetes Python client to patch the `EdgeNode` resource to `unattested` on failure. The registrar is also modified so that after it validates device identity, it can patch the `EdgeNode` resource to `registered`. These changes tightly integrate Keylime into Kubernetes’ object and status model, enabling automation and lifecycle management [2405.10131].

The enrollment workflow is conditional on attestation success. After the registrar validates the device identity, the controller verifies that the registered device matches the one described in the custom resource, generates a fresh key pair, requests a Kubernetes-signed certificate, and creates a dedicated Kubernetes `Role` and `RoleBinding` so that the resulting user receives only the permissions needed to enroll and operate as a worker node. The controller then packages the credential payload into a ZIP archive, combines it with the reference boot state, and sends both to the tenant through the tenant’s REST endpoint. The tenant encrypts the payload with a composite `U-key`, defined as the bitwise XOR of the `K-key` and `V-key`, contacts the registrar to fetch device information, contacts the agent and re-verifies EK ownership, sends the encrypted payload and `U-key` to the edge device, and forwards the `K-key` and the reference state to the verifier to set up continuous attestation. After the verifier validates the PCRs and boot record, it delivers the final key material to the agent, which decrypts and executes the payload. That payload starts the Fledge service and enrolls the node as a worker [2405.10131].

RBAC is not treated as a static configuration but as part of the attestation policy. Each edge device gets unique Kubernetes credentials rather than shared cluster-wide permissions. Registered but not yet attested nodes do not get full access, attested nodes receive the required permissions to function as edge workers, and unattested nodes have permissions revoked. This architecture therefore combines hardware-rooted trust, external verification, secure enrollment, least privilege, and dynamic revocation in a single control loop [2405.10131].

## 6. Performance, operational behavior, and stated limitations

The 5G prototype reports that the performance cost of continuous attestation is negligible. Worker node CPU utilization increased by only a tiny amount with Keylime running, and the Keylime agent itself consumed around 0.08% of CPU on average, with brief 1–2% spikes at quote intervals. Because attestation is not on the data path, it does not add meaningful latency to 5G signaling or user traffic. The same study emphasizes operationally useful outputs beyond binary pass or fail: trust labels, detailed audit logs, and forensic detail about the precise files or binaries that caused an integrity violation [2510.03219].

The edge-enrollment study reports a different performance profile because it measures startup and onboarding rather than steady-state runtime cost. Its quantitative evaluation reflects an average of 10.28 seconds delay incurred on the startup time of the edge node due to attestation for a total average enrollment time of 20.91 seconds. Baseline Fledge startup was 10.52 seconds, so attestation roughly doubled startup time. The evaluation also reports that successful initial attestation happened about 11 seconds after first contact in one scenario, a failed attestation was detected and communicated within 7 seconds, and continuous monitoring caught a later compromise and revoked permissions [2405.10131].

The two evaluations therefore illuminate different operational regimes. In the 5G case, the primary question is whether continuous runtime verification can be sustained without perturbing telecom workloads, and the reported answer is affirmative. In the edge-worker case, the primary question is whether trust-gated admission and ongoing monitoring can be integrated with cluster enrollment at acceptable latency, and the reported answer is that the mechanism is practical but introduces noticeable startup latency.

Both works make their limitations explicit. The edge study states that the system administrator is fully trusted and defines the reference state, that the EK certificate is trusted as manufacturer-signed, and that the design assumes the TPM and boot chain are properly rooted in a CRTM. It also identifies the binary nature of attestation as too rigid for edge deployments and notes that network access is not yet managed; the node currently has broad network access via VPN, and future work should limit network connectivity based on attestation state as well [2405.10131]. The 5G study, by contrast, shows that fine-grained containment is possible at pod level, but its evidence and policies remain grounded in allowlists and whitelist matching, which suggests that policy expressiveness is bounded by the quality and completeness of those baselines [2510.03219].

## 7. Terminological ambiguity and unrelated “key-lock” usage

“Keylime” in these systems refers to the attestation framework and its verifier, tenant, registrar, and agent architecture. It should not be conflated with unrelated uses of similar language in other fields. A separate arXiv paper, “Key-Lock Colloids in a Nematic Liquid Crystal,” studies a spherical “key” colloidal particle and a dimpled “lock” particle in a nematic liquid crystal; the details explicitly note that the word “Keylime” is not a term used in that paper and that the closest relevant concept is the key-lock geometry [1611.07714].

That distinction matters because the lexical similarity can create indexing or search ambiguity. In the colloid context, “key” and “lock” denote shape-complementary particles, topological defects, anchoring conditions, and Landau-de Gennes free-energy minimization. In the computing context, Keylime denotes a software framework for TPM-rooted remote attestation, continuous verification, and policy-driven trust management. The two usages share terminology but not subject matter.

Source: https://www.emergentmind.com/topics/keylime