This issue is to create a deployable, maintainable, scalable, fault-tolerant documented SPIRE reference architecture that relies on TPM as a root of trust for the sole purpose of node attestation. There are two forms that this documentation might take, one using TPM without the presence of Kubernetes, and one with the presence of Kubernetes. This issue only deals with the non-Kubernetes deployment.
Being a hardware based deployment, the helm chart project cannot be a component of one form of this documentation.
The goals of this effort is to provide
- One example, from the ground up, that establishes a redundant SPIRE cluster using the boxboat TPM node attestor.
- Procedures around establishing the initial trust for node attestation.
- Procedures around re-establishing trust for nodes down for a short period of time.
- Procedures around re-establishing trust for nodes down for extended (certificate expiring) periods of time.
- Procedures for scaling up to an additional SPIRE server
- Procedures for scaling down, removing a SPIRE server
As a side effect of this documentation, a number of follow-on issues will likely be drafted to facilitate the ease of deployment.
Where possible, the documentation should focus on fast recovery of outage events. A nonfunctional requirement of the documentation should be to minimize the effort for supporting a 100 or 1000+ node data center.
This issue is to create a deployable, maintainable, scalable, fault-tolerant documented SPIRE reference architecture that relies on TPM as a root of trust for the sole purpose of node attestation. There are two forms that this documentation might take, one using TPM without the presence of Kubernetes, and one with the presence of Kubernetes. This issue only deals with the non-Kubernetes deployment.
Being a hardware based deployment, the helm chart project cannot be a component of one form of this documentation.
The goals of this effort is to provide
As a side effect of this documentation, a number of follow-on issues will likely be drafted to facilitate the ease of deployment.
Where possible, the documentation should focus on fast recovery of outage events. A nonfunctional requirement of the documentation should be to minimize the effort for supporting a 100 or 1000+ node data center.