Support SPIFFE identities for (m)TLS connections

[bcleenders]

Hi! Thanks for the project - I get a lot of use out of it!

I would like to see if you're open to supporting SPIFFE identities for (m)TLS connections. SPIFFE is a framework for providing identities, and those identities can be used to set up mTLS connections. It's part of CNCF, and has several integrations e.g. with Google Cloud (example for providing the identity) and AWS (example for using the identity).

I can send a PR, but wanted to gauge your interest first.

SPIFFE uses certificates (for either client or server) that encode an identity in the SAN.URI field. Currently grpcurl only validates the server identity based on the SAN.IP or the SAN.DNS field (because those are the only fields that the golang x509 library checks).

I would like to be able to validate the server identity based on its SPIFFE ID, e.g. I would like to be able to run this:

grpcurl -spiffe-id 'spiffe://my-project.svc.id.goog/ns/my-namespace/sa/default' \
  -cacert ./ca_certificates.pem \
  1.2.3.4:5990 whoami.v1.WhoAmIService/WhoAmI

My desired behavior for this call is to not validate the IP - it should only verify that the SAN.URI field matches the -spiffe-id value.

Optionally with prefix matching, and optionally providing a client certificate, e.g.:

grpcurl -spiffe-id 'spiffe://my-project.svc.id.goog/ns/my-namespace/sa/*' \
  -cacert ./ca_certificates.pem \
  -cert ./private_key.pem \
  1.2.3.4:5990 whoami.v1.WhoAmIService/WhoAmI

Just to make it a bit more concrete if you haven't used SPIFFE before; a certificate used by SPIFFE looks like (I removed a bunch of fields):

$ openssl x509 -in /secrets/spiffe-credentials/certificate.pem
Certificate:
    Data:
        [...]
        Validity
            Not Before: Feb  2 21:45:04 2026 GMT
            Not After : Feb  3 21:45:03 2026 GMT
        Subject:
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name: critical
                URI:spiffe://my-project.svc.id.goog/ns/my-namespace/sa/default       <-- this is the identity

(this example uses a certificate issued by GCP Managed Workload Identity, which is SPIFFE-compatible)

If this sounds good, I have one additional question: a common way to get the certificates when using SPIFFE is via the "workload API", which is typically exposed as a socket. So passing a -workload-api flag would replace the need for -ca-cert and -cert. If you're open to it, I could add support for the workload API, but then I would need to add a dependency on go-spiffe. It would be nice functionality to align with SPIFFE, but it's not critical for my usecase so I'd love to hear your preferences.

Let me know if this sounds good, and I can work on a PR if it does!