Closed jsturtevant closed 1 year ago
This work is required for Spire support #5031
A proto-type of this work can be found at https://github.com/openservicemesh/osm/compare/main...jsturtevant:osm:spiffeid?expand=1. This could be used to do spire prototype.
A document outlining the work required: https://docs.google.com/document/d/1WSneAPSUeZOSJLhSzGXogVLxLXCqI_NRououxdxFAl4/edit?usp=sharing
@jsturtevant It feels safe to assume that full SPIFFE support isn't part of this milestone (v1.3) correct?
SPIFFE support could make it, depending on timeline for #5131 merging which is ready for review. There is one more PR after that for the functionality to use the SPIFFE ID in the certs (#5025 and #5023) which I should be able to get implemented next week. This would not include SPIRE support which requires a few refactors and Ingress work.
This issue will be closed due to a long period of inactivity. If you would like this issue to remain open then please comment or update.
spiffe certificates are now generated and used if enabled in MRC. There are a few items in #5031 that would be needed to support SPIRE completely
Root issue for SPIFFE Support (created from research in #4750
spiffe integration in OSM
The aspects of SPIFFE that we are primarily interested in are the x509 SVIDs and the Spiffe ID. In the future we may be interested in a few the other APIs specified but not required initially.
The SPIFFE specs doesn't specify how you use this identity just how it is encoded in the x509 certificate. In our case we have an existing abstraction around identity. We don't really need to change our identity mechanism but instead make it compatible with the SPIFFE specs. For more information on OSM identity see identity PR
Some of the benefits I see for this are:
At this point I believe SPIFFE isn't a requirement for multi-cluster. It could provide a way to simplify federation and allow for Attestation across different platforms. I would need to dive into the multi-cluster world more to understand what is really needed. Federation could be something really useful here.
tasks list
MatchSubjectAltNames
toMatchTypedSubjectAltNames
in Envoy config #5019