Feature Request: need support for spire agent CSR verification

[jzeng4]

Hi we use spire+TPM for host identity. Spire follows the zero trust networking security model, which assumes that network communication is inherently untrustworthy or potentially fully compromised. However, it also assumes that the hardware running SPIRE components can be trusted. In our threat model, we don't fully trust the host (e.g. running the spire agent) and are trying to leveraging hardware elements (HSM, TPM etc.) to protect keys.

One of the problem is to implement one feature called spire agent key binding. In particular,

• The spire agent key is stored in TPM (we call it TPM agent key).
• The spire server issues the agent certificate only if the CSR is signed by the TPM agent key in the same TPM as TPM EK and AK.

For 1, we think Spire has very good support. For 2, we tried to verify whether CSR is signed by the TPM agent key in Spire server in node attestation (we set reattestable to true). Specifically, we attach "evidence" in the node attestation payload which is combined with CSRs for the verification. However,

1. This verification part is not customizable (like plugins).
2. Another way is to let Node attestation plugin verify the CSR. However, the plugin can only access the payload which is not including CSR.

We mixed tow agent plugins together (key manager and node attestation) to solve key binding problem. We would like to know if it is the right way to leverage Spire node attestation to solve key binding problem. If not, any suggestions? Thank you!

[jzeng4]

Hi Team,

Could you please help prioritize this? Our company heavily relies on SPIRE for host identity across hundreds of thousands of hosts. Your early feedback on this is crucial to help unblock our technical decisions.

Thank you!

[evan2645]

Hi @jzeng4 - thank you for the poke and for your patience.

Is it absolutely necessary for your threat model to distrust the host? We can certainly talk about binding agent private keys to TPM residency however those keys are only a stepping stone to the workload keys, for which there is no support for hardware backing. Furthermore, the entire workload attestation subsystem in the agent relies on data from various parts of the host. Hiding the agent's private key is not enough to meet the threat model you're describing.

My recommendation is to adopt a threat model that recognizes security boundaries within the host, which better aligns with the SPIRE threat model. Workloads and other host processes are wholly untrusted, however root level access is trusted for the scope of that node. If this is an acceptable posture, we can make some further recommendations on how to meet it. But if it is not, then I believe there are many other issues to address beyond agent key TPM residency.

[jzeng4]

Hi @evan2645 Thank you for your informative reply!

Is it absolutely necessary for your threat model to distrust the host?

This is our current thread model that we try to targeting. Because we have deployed SPIRE agent on hundreds of thousands of nodes. Any of them might suffer from compromises (due to vulnerabilities and/or misconfigurations) to get root privileges.

workload keys, for which there is no support for hardware backing.

That is right. We have been thinking about what techniques can be leveraged to meet our threat-model (e.g. SGX). I understand that SPIRE trusts root level access and so it makes sense to store workload key in memory. I wonder it is possible to provide a new type of plugin (like "keystore") to specify how to store workload keys (by default it is memory)?

Furthermore, the entire workload attestation subsystem in the agent relies on data from various parts of the host.

We are planning to combine TPM measured boot with SELinux to ensure the integrity and trustworthiness of the host system's data during initial boot up and runtime.

Do you think it's feasible to extend SPIRE (through plugins or other means) for user to enhance the threat model over the long term?

If this is an acceptable posture, we can make some further recommendations on how to meet it.

Also would love to learn more details on this.

Thank you!