Modern PKI at LinkedIn: Anchored in hardware and designed for scale

In modern secure computing environments, ensuring strong, verifiable identity for workloads is critical to prevent impersonation, unauthorized access, and supply chain attacks that could damage members’ trust in LinkedIn. 

We have the unique opportunity to secure the entire trust chain – from the hardware up to the application – as part of our infrastructure foundations. To do so, we use an internal Public Key Infrastructure (PKI) architecture that extends and integrates with the SPIRE framework (an open source implementation of the SPIFFE Runtime Environment).This framework provides secure identity that powers Kubernetes control plane communications, whose security hinges on the trustworthiness of the underlying node identity.

In this blog, we'll discuss how we built our next-generation PKI to keep LinkedIn secure for our members and customers. We'll explore how we scaled SPIRE, and extended it to provide cryptographic attestation, secure key storage and trust key origin to ensure end-to-end security across LinkedIn’s ecosystem.

Background and challenges

SPIRE is an open source implementation of the SPIFFE framework that securely issues identities to workloads and nodes. It consists of: 

1. SPIRE Server: responsible for issuing identities.
2. SPIRE Agent: runs on individual nodes and handles the process of verifying (attesting) workloads before issuing and managing their identities.. 

Once the SPIRE Agent is attested by the SPIRE Server, it can securely issue and manage identities for workloads running on that node. This process generates a SPIFFE Verifiable Identity Document (SVID) in the form of a public key pair/certificate for the SPIRE agent. Alongside this, a private key is created for the SPIRE agent. The SVID and private key provide strong cryptographic proofs of the node’s identity. 

LinkedIn’s PKI team leverages SPIRE for identity management and further enhances the open-source SPIRE stack to ensure a secure foundational layer to address some of the most pressing challenges in modern distributed systems.

The first challenge is bootstrapping nodes with identities that are strongly attestable. Attestation is a core property of SPIRE, enabling the system to validate a node or workload’s identity, using available information as evidence. Attestation is traditionally difficult as it ultimately boils down to the problem of what attests the attester. Tying attestation to static attributes such as IP addresses and hostnames no longer hold in dynamic modern cloud native environments. Attributes such as hardware backed cryptographic keys and validation of firmware/microcode state are more durable and provide better assurance in cloud native environments.     

Second, protecting the identity credentials such as private keys from disclosure in memory and on disk. 

A third challenge is constraining the use of credentials to an attested host.This prevents a stolen private key from being used elsewhere on a different host and thereby prevents lateral movement attacks.

LinkedIn’s servers leverage Trusted Platform Module (TPM) hardware modules by default, which provides two critical functionalities:

1. Isolated environment for key management: TPMs create a secure environment for generating, storing, and operating cryptographic keys, including key signing. This ensures confidentiality and integrity of key material, even if the host operating system is compromised or targeted by root-level attackers.
2. Remote node attestation: TPMs enable a device to verify its hardware and software are in a known, trusted state during boot. This is a pre-requisite to issue a valid node identity that can then be used to ensure that only authorized nodes are allowed to join a cluster.

To anchor node identity in hardware-rooted trust, LinkedIn integrates SPIRE with TPM. This integration ensures cryptographic attestation of node identity at boot time.

The root of trust is established using the TPM Endorsement Key (EK), a non-migratable, device-specific key pair embedded in the TPM during manufacturing. The EK is a public key securely provisioned to an inventory server—an integral part of the attestation workflow— during node registration, establishing trust in the hardware. Meanwhile the EK private key remains securely stored within the TPM. 

When a node attempts to join a cluster, the node attestation process utilizes a credential activation protocol with the EK key pair to verify proof of possession. This ensures only authorized nodes gain access, forming a strong foundation for LinkedIn's secure infrastructure.

This base integration ensures nodes are bootstrapped with identities that are strongly attested. In the rest of this post, we cover how we hardened this further to address protecting the identity credentials and constraining their use to the attested host.  

Hardening the SPIRE integration with TPM 

To secure SPIRE agent credentials and tie it down to a specific node, we bind the SPIRE agent key to the TPM. This process leverages remote attestation to verify node integrity and enables hardware-backed workload identity issuance. 

Binding the SPIRE agent key to TPM and leveraging remote attestation prevents lateral movement of an attested agent after the attestation process is complete. As a result, only strongly attested nodes participate in control plane communications, forming a critical step for securing large-scale, distributed systems under LinkedIn’s zero trust model. 

Key plugins extended from SPIRE

To achieve the above, we extended two critical plugins from SPIRE:

1. SPIRE node attestation plugin This validates that a node is legitimate before assigning it a SPIFFE ID. This ensures that only trusted nodes can participate in workload identity issuance.
2. SPIRE key manager plugin This plugin manages and securely stores the cryptographic keys used by the SPIRE Agent for workload identity signing.

Security-hardened node attestation workflow

The steps to achieve security-hardened node attestation in SPIRE involves leveraging TPM and extending SPIRE’s capabilities to ensure robust authentication and prevent unauthorized access. Here’s the workflow:

1. Key generation using TPM: When the SPIRE agent starts, it invokes the Key Manager Plugin to generate an agent key pair. The plugin interacts with the TPM to securely create the key pair, ensuring the private key remains protected within the TPM. The agent receives both the public key and a handle for the private key.
2. Secure connection establishment: To establish a secure connection with the SPIRE server, the agent uses Transport Layer Security (TLS). It leverages the TPM-protected key for signing operations during the TLS handshake, ensuring that communications are secure from the outset.
3. Certificate Signing Request (CSR) creation and attestation: The SPIRE agent generates a Certificate Signing Request (CSR), which is signed using the private key securely stored in the TPM. The signed CSR, along with the TPM-generated attestation data, is included in the attestation payload and sent to the SPIRE server.
4. Remote node attestation and validation: Upon receiving the payload, the SPIRE server conducts multiple security validations::
   1. Key certification validation: Ensures the agent’s key is certified by the TPM’s Attestation Key (AK) and confirms it belongs to the same TPM as the Endorsement Key (EK) and AK.
   2. CSR integrity check: Verifies that the CSR is signed by the private key tied to the TPM.
5. Issuance of SVID: Upon successful validation, the SPIRE server issues an SVID . This certificate enables the agent to securely participate in control plane communications. For example, mTLS (mutual TLS) authentication is used between the Kubernetes components (eg. kubelet to kube-apiserver) to prevent unauthorized nodes from joining the system.

Conclusion

In this blog post, we detailed LinkedIn’s approach to anchoring node identity in hardware using TPM-backed keys within the open source SPIRE framework.This integration establishes the TPM as a hardware root of trust, ensuring that node identities are securely generated, remain confidential, can be independently verified, and are bound to specific hosts.

The integration of SPIRE with TPM provides the following security benefits:

• Key confidentiality – The SPIRE agent key is protected within the hardware, eliminating the risk of exposure.
• Provenance – Only TPM-certified keys can be used, preventing even privileged attackers from forging credentials.
• Host binding – The SPIRE agent key remains tied to the host where attestation occurred, providing strong provenance and integrity.
  

This integration lays a robust foundation for implementing secure workload identity, allowing a zero trust system to be realized in practice. By embedding cryptographic safeguards at the hardware level, organizations can strengthen trust in their infrastructure, mitigate key compromise risks, and enhance overall system resilience. Stay tuned for future posts, where we’ll dive deeper into how we build secure workload identity management. We’re excited to share more insights soon!

Acknowledgements

This security infrastructure foundational work would not have been possible without the tireless and dedicated work of our team members: Junyuan Zeng, Rahul Godha, Ruihan Guan, Wei Zhang, Yogesh Patil and the entire LinkedIn PKI team. 

Thanks to our TPM partner Raghu Dharani, the Hardware Engineering, Production Systems Software Engineering, and Compute Infra teams for being able partners in driving this cross organizational initiative. 

Special thanks to those who gave their time to review and edit this blog: Michael Leong, Omkhar Arasaratnam and Wei Zhang.

We would like to thank the contributions from all the individuals towards this specific initiative including our LinkedIn alumni, Alex Tcherniakovski, Priya Ayyagari, and Sergei Rousakov. 

Finally, we would like to thank our engineering leaders: Omkhar Arasaratnam, Lea Kissner and Sabry Tozin for their strong support throughout this journey.