A97: xDS JWT Call Credentials #492
Conversation
There was a problem hiding this comment.
I'll let @howardjohn confirm, but I think this covers Istio functionality. For a sidecar, the service account token is mounted as "istio-token" JWT with a different audience.
|
Hey; may I ask what's needed to progress this proposal? 🙏 |
|
@dimpavloff Thanks for the ping! There's nothing blocking this other than finding the time to push it forward. :) Do you have a particular gRPC language in which you're waiting for this feature? |
Ah, I know the feeling :)
Yes. At my company we use Go and are keen to adopt gRPC proxyless but we hit istio/istio#53532 which is what led me here. |
|
|
||
| ### JwtTokenFileCallCredentials | ||
|
|
||
| Note: This section is intended for gRPC implementations that need to |
There was a problem hiding this comment.
Java implementation note: We can use JsonWebSignature.parse().getPayload().getExpirationTimeSeconds() to create an AccessToken with appropriate expiration. We could extend OAuth2Credentials and implement refreshAccessToken(). It takes care of stale vs expiration checking. Using JsonWebSignature is essentially re-implementing IdToken, which would probably work today, but technically this is not necessarily an IdToken so we should probably avoid the existing class.
This is the first part of implementing gRFC A97 (grpc/proposal#492). Closes #39769 COPYBARA_INTEGRATE_REVIEW=#39769 from markdroth:jwt_token_call_creds fd890a3 PiperOrigin-RevId: 772533750
This is the first part of implementing gRFC A97 (grpc/proposal#492). Closes grpc#39769 COPYBARA_INTEGRATE_REVIEW=grpc#39769 from markdroth:jwt_token_call_creds fd890a3 PiperOrigin-RevId: 772533750
…le call creds (#39772) This is the second half of gRFC A97 (grpc/proposal#492). Closes #39772 COPYBARA_INTEGRATE_REVIEW=#39772 from markdroth:jwt_token_call_creds2 727f770 PiperOrigin-RevId: 776233709
This is the first part of implementing gRFC A97 (grpc/proposal#492). Closes grpc#39769 COPYBARA_INTEGRATE_REVIEW=grpc#39769 from markdroth:jwt_token_call_creds fd890a3 PiperOrigin-RevId: 772533750
…le call creds (grpc#39772) This is the second half of gRFC A97 (grpc/proposal#492). Closes grpc#39772 COPYBARA_INTEGRATE_REVIEW=grpc#39772 from markdroth:jwt_token_call_creds2 727f770 PiperOrigin-RevId: 776233709
…7) (#8431) Part one for grpc/proposal#492 (A97). This is done in a new `credentials/jwt` package to provide file-based PerRPCCallCredentials. It can be used beyond XDS. The package handles token reloading, caching, and validation as per A97 . There will be a separate PR which uses it in `xds/bootstrap`. Whilst implementing the above, I considered `credentials/oauth` and `credentials/xds` packages instead of creating a new one. The former package has `NewJWTAccessFromKey` and `jwtAccess` which seem very relevant at first. However, I think the `jwtAccess` behaviour seems more tailored towards Google services. Also, the refresh, caching, and error behaviour for A97 is quite different than what's already there and therefore a separate implementation would have still made sense. WRT `credentials/xds`, it could have been extended to both handle transport and call credentials. However, this is a bit at odds with A97 which says that the implementation should be non-XDS specific and, from reading between the lines, usable beyond XDS. I think the current approach makes review easier but because of the similarities with the other two packages, it is a bit confusing to navigate. Please let me know whether the structure should change. Relates to istio/istio#53532 RELEASE NOTES: - credentials: Add `credentials/jwt` package providing file-based JWT PerRPCCredentials (A97).
No description provided.