SPIFFE support

[jsturtevant]

Root issue for SPIFFE Support (created from research in #4750

spiffe integration in OSM

Pros and cons comparing SPIFFE to the current service identity mechanism 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:

• By adhering to specifications it enables integrations with rest of eco system (see "Who uses SPIFFE?" at https://spiffe.io/). Once able to use the specification things like OPA integrations and OIDC integrations become options
• Opens the door for integrations with SPIRE. Spire has a few advantages that would likely be worth exploring further like workload attestation plugins, federation, certification rotation. Attestation could be a big draw here.
• potential for a way to reason about using across multiple types of workload beyond kubernetes. Though the naming schema is still left up to the implementors. Our current schema might work but needs some additional thought.

Especially explore the scenario if they are used in multi-cluster environment

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

Rough task list if we migrate from current service identity component to SPIFFE.

• [x] document current osm Identity solution #5004
• [x] Switch from MatchSubjectAltNames to MatchTypedSubjectAltNames in Envoy config #5019
• [x] #5022
• [x] #5023
• [x] #5024
  • [x] #5095
• [x] #5025
• [x] #5026
• [x] Enable control plane certificates issue x509 SVIDS (optional)
• [ ] Implement bundle API for federation with other systems (optional)
• [ ] Integrate envoy certificate validator (optional)
• [x] #5027
• [x] #5033
• [x] #5034
• [x] #5093

[jsturtevant]

This work is required for Spire support #5031

[jsturtevant]

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.

[jsturtevant]

A document outlining the work required: https://docs.google.com/document/d/1WSneAPSUeZOSJLhSzGXogVLxLXCqI_NRououxdxFAl4/edit?usp=sharing

[keithmattix]

@jsturtevant It feels safe to assume that full SPIFFE support isn't part of this milestone (v1.3) correct?

[jsturtevant]

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.

[github-actions[bot]]

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.

[jsturtevant]

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