feat: add experimental s2a-go integration #1874
Conversation
quartzmo
added
the
needs more info
|
Hi @xmenxk, Thank you for opening this pull request! Can you please open a feature request issue explaining the motivation for this feature (the benefits for users) and providing some background on the stability of s2a-go and how it will work in the context of this HTTP client? |
|
thanks @quartzmo for the response. Both touch the transport layer code, as far as I can tell, they are for different use cases. #1886 looks like it's specifically for allowing configuring a http-client to talk to oauth2's mtls endpoint. The s2a integration this PR adds is a way for cloud workloads to talk to all google apis using MTLS, in a transparent way. It only runs when no other MTLS approach is specified, so there should't be any conflict. |
xmenxk
force-pushed
the
zatar-mtls
branch
2 times, most recently
from
6859717 to
983292e
Compare
Hi @codyoss, could you take a look at the PR? thanks :) |
noahdietz
removed
the
needs more info
I've added @codyoss as a reviewer. I'm on rotation this week but I'd feel better with Cody reviewing this change anyways :) |
|
Added cody back to reviewers |
internal/cba.go
Outdated
| @@ -41,10 +52,12 @@ const ( | |||
| mTLSModeAuto = "auto" | |||
| ) | |||
|
|
|||
| // GetClientCertificateSourceAndEndpoint is a convenience function that invokes | |||
| var useS2A = flag.Bool("use_s2a", false, "Experimental: if true, the code will try MTLS with S2A as the default for transport security.") | |||
There was a problem hiding this comment.
I agree that I think a envvar would be preferable here.
codyoss
added
the
kokoro:force-run
kokoro-team
removed
the
kokoro:force-run
Head branch was pushed to by a user without write access
codyoss
added
the
kokoro:force-run
kokoro-team
removed
the
kokoro:force-run
…port (#3326) Modify the Client Libraries gRPC Channel builder to use mTLS via S2A if the experimental environment variable is set, S2A is available (We check this by using utility added in googleapis/google-auth-library-java#1400), and a few more conditions (see `shouldUseS2A`). Following https://google.aip.dev/auth/4115, Only attempt to use S2A after DirectPath and DCA (https://google.aip.dev/auth/4114) are ruled out as options. If conditions to use S2A are not met (env variable not set, or S2A is not running in environment, etc (`shouldUseS2A` returns false)), fall back to default TLS connection. When we are creating S2A-enabled Grpc Channel Credentials, we first try to secure the connection between the client and the S2A via MTLS, using [MTLS-MDS](https://cloud.google.com/compute/docs/metadata/overview#https-mds) credentials. If MTLS-MDS credentials can't be loaded, then we fallback to a plaintext connection between the client and S2A. The parallel go implementation : googleapis/google-api-go-client#1874 (now lives here: https://github.com/googleapis/google-cloud-go/blob/main/auth/internal/transport/cba.go) S2A Java client: https://github.com/grpc/grpc-java/tree/master/s2a Resolving b/376258193 means that S2A.java is no longer experimental --------- Co-authored-by: blakeli <[email protected]>
s2a integration with grpc and http transport code.
With this change, client library will try establishing mtls with the google api's mtls endpoint, using credentials held by s2a.
The added code only changes the default behavior in a way that's transparent to customers; if other mtls approach is specified, e.g. DCA, this code will not run.