SPIFFE Workload Server can be Single Point of Failure? about spiffe HOT 5 CLOSED

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.

from spiffe.

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.

from spiffe.

@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.

from spiffe.

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.

from spiffe.

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.

from spiffe.