Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for new setAllowHardBoundTokens field. #3467

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

rmehta19
Copy link
Contributor

@rmehta19 rmehta19 commented Dec 14, 2024

Introduce new setAllowHardBoundTokens field.

@product-auto-label product-auto-label bot added the size: m Pull request size is medium. label Dec 14, 2024
@rmehta19
Copy link
Contributor Author

rmehta19 commented Jan 7, 2025

@lqiu96 , @blakeli0 , @zhumin8, please review, thanks!

@rmehta19
Copy link
Contributor Author

rmehta19 commented Jan 8, 2025

cc: @rockspore

Copy link

@rockspore rockspore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR, Riya! Not up to me but LGTM.

@@ -126,6 +127,7 @@ public final class InstantiatingGrpcChannelProvider implements TransportChannelP
@Nullable private final Boolean allowNonDefaultServiceAccount;
@VisibleForTesting final ImmutableMap<String, ?> directPathServiceConfig;
@Nullable private final MtlsProvider mtlsProvider;
@Nullable private final ArrayList<String> allowedValues;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this variable name be more specific? Reading it alone doesn't tell you where these values will be used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for calling this out! I updated this variable name to allowedHardBoundTokenTypes, WDYT?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks.

@rmehta19
Copy link
Contributor Author

Friendly ping @lqiu96 , @blakeli0 , @zhumin8. Thanks!

@blakeli0
Copy link
Collaborator

What is the usage of this new allowHardBoundTokens field? Do you mind providing more background info?

@@ -97,6 +98,9 @@ public interface TransportChannelProvider {
*/
TransportChannelProvider withEndpoint(String endpoint);

/** Sets the allowed hard bound token types. */
TransportChannelProvider setAllowHardBoundTokens(ArrayList<String> allowedValues);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this field is going to be only used by gRPC transport per the internal doc? And the teams that would use it are all handwritten libraries? If that's the case, I think they are likely going to initialize an InstantiatingGrpcChannelProvider in their repo directly and pass it to Gax, so can we only add this to InstantiatingGrpcChannelProvider?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this field is going to be only used by gRPC transport per the internal doc?

That is correct, hard bound tokens is only for gRPC.

I think they are likely going to initialize an InstantiatingGrpcChannelProvider in their repo directly and pass it to Gax, so can we only add this to InstantiatingGrpcChannelProvider?

I think this will work since I believe the libraries separate their logic for HTTP and gRPC, so they don't end up using the interface TransportChannelProvider. Looking at GCS for example, this is the case

@rockspore can you confirm that the places you want to use this setting are using the InstantiatingGrpcChannelProvider directly, not the interface TransportChannelProvider?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For Cloud Spanner, I found this so it seems to be the case too, although I don't see where it gets called by default.

So yeah it should be good if we only do this in InstantiatingGrpcChannelProvider, as long as we have a way to set these default values eventually to all auto-generated clients.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rockspore The link you referred to is a generated default instance of InstantiatingGrpcChannelProvider, which I believe will be overridden later in their handwritten code.
Either way, they are using InstantiatingGrpcChannelProvider directly not the interface. And since it is used within InstantiatingGrpcChannelProvider only, we don't need to expose a getter for it either. Hence it should be fine if we only add it to InstantiatingGrpcChannelProvider.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the details! It makes perfect sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks all for the discussion! Done in 60dafd0

@rmehta19
Copy link
Contributor Author

What is the usage of this new allowHardBoundTokens field? Do you mind providing more background info?

I believe we discussed this in the chat offline. To summarize it'll be used by clients (libraries) to indicate if they want MTLS / Directpath bound tokens. Please let me know if there is anything we can make more clear.

@product-auto-label product-auto-label bot added size: s Pull request size is small. and removed size: m Pull request size is medium. labels Jan 16, 2025
@@ -700,6 +708,11 @@ public Builder setEndpoint(String endpoint) {
return this;
}

public Builder setAllowHardBoundTokenTypes(ArrayList<String> allowedValues) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we expect customers to set this? Or only internal teams like Spanner/Storage to set it? If it is the latter, can we mark this method as @InternalApi?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right we don't want external customers to set it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only expect internal teams to set this field, marked as @InternalApi in e193cc9

@product-auto-label product-auto-label bot added size: xs Pull request size is extra small. and removed size: s Pull request size is small. labels Jan 16, 2025
@@ -700,6 +703,12 @@ public Builder setEndpoint(String endpoint) {
return this;
}

@InternalApi
public Builder setAllowHardBoundTokenTypes(List<String> allowedValues) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the possible values of allowedValues? I think there are only two possible values so far per internal doc, if that's the case, can they be Enums so it's less error prone?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we can capture the allowed values in an enum. Done in 0e40f22

@product-auto-label product-auto-label bot added size: s Pull request size is small. and removed size: xs Pull request size is extra small. labels Jan 16, 2025
Copy link
Contributor

@zhumin8 zhumin8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please also add some test coverage for this change?

Comment on lines +727 to +736
* <p>allowedValues is {HardBoundTokenTypes.ALTS}: If DirectPath is used to create the channel,
* use hard ALTS-bound tokens for requests sent on that channel.
*
* <p>allowedValues is {HardBoundTokenTypes.MTLS_S2A}: If MTLS via S2A is used to create the
* channel, use hard MTLS-bound tokens for requests sent on that channel.
*
* <p>allowedValues is {HardBoundTokenTypes.ALTS, HardBoundTokenTypes.MTLS_S2A}: if DirectPath
* is used to create the channel, use hard ALTS-bound tokens for requests sent on that channel.
* If MTLS via S2A is used to create the channel, use hard MTLS-bound tokens for requests sent
* on that channel.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These logic is not part of this setter, I suppose is part of a subsequent PR? Perhaps move this explanation there. In the future, if this logic changes, it is easy to miss updating here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree that maybe the detailed explanation can be moved to the subsequent PR. The public doc for this method should be more like "What is HardBoundTokenTypes?", not "What would happen if we set HardBoundTokenTypes to different values?". But if listing the different behavior is the best way to explain "What is HardBoundTokenTypes?", I think this is OK too.

* or S2A is used to estabilsh a connection to Google APIs.
*
*/
public enum HardBoundTokenTypes {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to also mark this as internal?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree on making this internal as well.
Thinking twice about it though, I see that it is an Experimental feature, is it that we will always set the tokens to certain values? Or it's just this feature is not stable yet, internal teams could still set this to different values? If it's the former, then we don't have to introduce another public enum since they would be obsolete soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size: s Pull request size is small.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants