SPIFFE Workload Server can be Single Point of Failure?

[savankumargudaas]

I have questions on base assumptions of The SPIFFE Workload API server/client. Can someone please clarify?

1. Based on the document, the Workload server potentially a Single Point of Failure (SPF), as workload clients always assume that the server is up and running. In a distributed system, if all compute nodes depend on workload server, it has a high blast radius. The document needs to mention whether the server is SPF or not. Can there be any alternatives to avoid SPF? Doc needs to clarify the basic requirements of the server.
2. Workload API document doesn't even recommend about storage requirements of the server. If single storage is been shared among multiple instances, again storage can be SPF. Requirements on storage requirements to be added.
3. SPIFFE expects the entire infrastructure to follow the specification, but in reality, it doesn't work. The document doesn't mention, whether it's possible to run a hybrid approach.

[spikecurtis]

1. Whether the infrastructure that implements the server-side of the API is a single point of failure depends on the implementation details of the control plane. It is certainly possible to build an implementation that is not a single point of failure. The API spec is just that: details of the API, not how the control plane is implemented.
2. Again, those are implementation details of the control plane and don't belong in the API spec.
3. SPIFFE specs are designed for interoperability with existing cryptographic systems. For example, x509 SVIDs can be processed by standard TLS and x509 libraries. We believe hybrid approaches are possible and understand that operators will not be able to do an instantaneous switch to SPIFFE/ Designing a hybrid approach in detail will obviously depend on the exact circumstances of the legacy environment, so isn't a good candidate for specifications. But, I'd encourage you to join one of the community mailing lists or the Slack to discuss how people are deploying SPIFFE in their environments.

[savankumargudaas]

1 & 2. I'm sorry, but I beg to disagree. There are 3 reasons to mention server spec in The SPIFFE Workload API.

• SPIFEE API is strongly (space and time) coupled with server (or control plane) implementation.
• The server is critical for infrastructure, as bootstrapping of any compute node depends on the server.
• The upper bound availability of SPIFFE complied distributed system is limited by server's availability.
  Though implementation details not necessary, the spec of server needs to be mentioned.

3. hybrid approach in detail will obviously depend on the exact circumstances
   I agree with you. Thanks for sharing community information.

[spikecurtis]

@savankumargudaas I'm not really sure at this point whether this is just commentary, or if there is a particular "issue" you'd like to see addressed. If there is an issue you'd like to see addressed, can you try to state the problem as plainly as you can (and proposed solutions, if you have ideas there)?

If there isn't an issue, please close this ticket.

[savankumargudaas]

As mentioned reasons in my last comment, server is a critical part of SPIFFE, hence server spec needs to mention in SPIFFE doc to avoid SPF.

Issuing certificate during bootstrap is the core cause of SPF, because availablity of server is mandatory.

In a distributed system, there are enough probems, SPF is something which need to be avoided. IMO compling with SPIFFE spec should not add a critical piece of infra, rather it need to be non-critical and compliment exising distributed system with additional layer of security/identity. How it can be achieved? it's something which need to be discussed and need to be adressed.

[spikecurtis]

I don't think we can really be responsive to this issue in its current form without compromising on the core principles of SPIFFE. @savankumargudaas if you have specific suggestions for concrete changes to SPIFFE specs, please open a PR.

Happy to discuss more on the mailing list; GitHub issues aren't the best format for general discussion.