You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While Vitess offers mTLS authentication support, its mechanism for validating client certificates is limited. It only supports substring searches of the CN (Common Name). I was tempted to extend support to subjectAltName extension using dnsNames, but Vitess uses this to extract security group information for the mTLS auth plugin.
Instead of looking at other approaches to extend the mTLS auth plugin, I think it might be worth supporting an existing, open standard like SPIFFE. It is widely used and is built to solve just these sorts of authentication problems between parts of a distributed system.
As a CNCF graduated project, we can have some confidence that the standard will be around for a while and that it is stable.
Use Case(s)
SPIFFE, through X.509 SVIDs, is essentially a specific use of mTLS.
Initially, this could be used for gRPC (between vtgates and vttablets, for example). By defining a Trust Domain for a Vitess Cluster, it would be possible to automatically generate trusted keys whose use would be limited to vttablets and the like that are a part of that cluster.
SPIFFE supports federating Trust Domains, so as long as they are issued by a CA that Vitess server components trust, it should be possible to provide a list of Trust Domains.
Essentially, SPIFFE brings to bear all the benefits of mTLS with the benefit of providing a standard for its implementation (which most generic mTLS authentication approaches -- including Vitess -- lack).
Extending SPIFFE beyond gRPC would take some thought since SPIFFE IDs are not guaranteed to be in a format that would work for authentication end-to-end (they're URIs that contain useful information; we'd have to decide which URI components should be extracted to form the Caller ID, if any).
The text was updated successfully, but these errors were encountered:
Feature Description
While Vitess offers mTLS authentication support, its mechanism for validating client certificates is limited. It only supports substring searches of the
CN
(Common Name). I was tempted to extend support tosubjectAltName
extension usingdnsNames
, but Vitess uses this to extract security group information for the mTLS auth plugin.Instead of looking at other approaches to extend the mTLS auth plugin, I think it might be worth supporting an existing, open standard like SPIFFE. It is widely used and is built to solve just these sorts of authentication problems between parts of a distributed system.
As a CNCF graduated project, we can have some confidence that the standard will be around for a while and that it is stable.
Use Case(s)
SPIFFE, through X.509 SVIDs, is essentially a specific use of mTLS.
Initially, this could be used for gRPC (between vtgates and vttablets, for example). By defining a Trust Domain for a Vitess Cluster, it would be possible to automatically generate trusted keys whose use would be limited to vttablets and the like that are a part of that cluster.
SPIFFE supports federating Trust Domains, so as long as they are issued by a CA that Vitess server components trust, it should be possible to provide a list of Trust Domains.
Essentially, SPIFFE brings to bear all the benefits of mTLS with the benefit of providing a standard for its implementation (which most generic mTLS authentication approaches -- including Vitess -- lack).
Extending SPIFFE beyond gRPC would take some thought since SPIFFE IDs are not guaranteed to be in a format that would work for authentication end-to-end (they're URIs that contain useful information; we'd have to decide which URI components should be extracted to form the Caller ID, if any).
The text was updated successfully, but these errors were encountered: