How do I apply a `io.grpc.CallCredentials` to `ServiceOptions`?

[Capstan]

I have a private class that generates io.grpc.CallCredentials to authorize to Cloud Spanner. Apparently the ServiceOptions.Builder.setCredentials only knows about com.google.auth.Credentials. I know that the Cloud Spanner communication is done over gRPC. Is there a way to apply my CallCredentials?

[olavloite]

I assume that you are using the Spanner client library, as you are referencing the ServiceOptions.Builder.setCredentials method.

The short answer for the Spanner client library is: No, that is currently not possible.

The slightly longer answer:
io.grpc.CallCredentials can be used to specify credentials per gRPC call. The Spanner client library currently only supports using one set of credentials that will be used for all gRPC calls that will be executed by a com.google.cloud.spanner.Spanner instance, as the actual gRPC calls are hidden from the user. Calling the method com.google.cloud.spanner.DatabaseClient.readWriteTransaction() could for example trigger several gRPC calls to create a session and start the actual transaction before control is handed back to the caller. The client library therefore expects the user to supply a static set of credentials when the com.google.cloud.spanner.Spanner instance is created.

Based on your question however, I do assume that it is not your goal specify different credentials per gRPC call, but that you would just like to use the io.grpc.CallCredentials that you already have to create a com.google.cloud.spanner.Spanner instance. Is that assumption correct? Or do you actually want to use different credentials for different gRPC calls?

[Capstan]

Your assumption is correct. It's a static principal, but not a static set of credentials, since refreshing may occur between underlying retries behind the gRPC stub.

[olavloite]

I'm not sure I understand what you mean with your last comment. If you provide credentials through the normal SpannerOptions#setCredentials(Credentials) method, the client library will take care of refreshing any access tokens when that is necessary, so as a consumer of the library you don't have to worry about this.

Could you explain a little bit more in detail what the reason is that you want to use io.grpc.CallCredentials instead of just supplying a static set of credentials?

[Capstan]

There are several bespoke things going on here, primarily in Google's monorepo:

• Since we're primarily a direct RPC-using shop, we support extensions to the default gRPC stubs that allow configurable behavior that happens below the stub for all stubs. This includes things like retry policies, shedding load based on server monitoring, request hedging. These are stock behaviors before anyone piles on thick clients, e.g., Cloud Spanner, on top of RPC servers.
• Google, internally, has a slightly different authentication system, so OAuth tokens aren't what we're using, and we take care to ensure people aren't using OAuth for non-public APIs.
• Between these two, the RPC stub extension mechanism is very restrictive about what kinds of creds it supports, e.g., so clients don't pass in some static, non-refreshable token, and that they don't pass in the wrong type of auth. This is done by type checking and bazel BUILD visibility limits to ensure reviews occur.

So, whether or not a client library does some intelligence above the gRPC stub, we still are limited in what the underlying substrate will accept. What we have is an internal type that passes the type check and supports io.grpc.CallCredentials, and there's no current way to assign that credential in to the spanner client.

I've not been able to track how a GoogleDefaultCredentials eventually gets exchanged into a io.grpc.auth.GoogleAuthLibraryCallCredentials, but if I knew how that worked, I could likely build the equivalent for our Guarded CallCredentials that would be built via a new Guarded Credentials which would implement com.google.auth.Credentials.

[Capstan]

This might be a byproduct of MoreCallCredentials.from, which as a static method, doesn't allow the Credentials to determine anything about the final type.

[olavloite]

@Capstan Would the proposed change in googleapis/google-cloud-java#6426 solve your problem? It adds the possibility of setting a CallCredentialsProvider on the SpannerOptions. See L348 of GapicSpannerRpcTest for an example on how to use it.

[Capstan]

That looks good, yes. I need to forward this to my colleague who'd be consuming it.

[Capstan]

/cc @tsalomie

[olavloite]

/cc @Capstan Could you (and your colleague) have a look at #26?