1
votes

This article explains how to handle authentication from an end-user with Identity Platform.

The crux seems to be that the client should authenticate with Identity Platform to get a token. That's straightforward enough and I've been able to retrieve the token from the client side code. The server side should receive the token from the client in a request header. But the article doesn't seem to explain what to do after this point. We can get the user with the Identity Platform SDK, but what if the token is invalid? Should we just throw an exception so that the gRPC call errors out?

There is a Java sample and you can that is what it does here. In the sample it returns a Forbidden 403 HTTP status.

But, my assumption is that Cloud Run would have a more automatic level of integration than this. This requires the Cloud Run gateway to send a request to the gRPC service, and get the response. Theoretically, that would allow a malicious actor to continuously hit the gateway with spam tokens that could potentially cost money. If we simply return an error, how are we protected from malicious actors pounding our services? Does the gateway automatically block the IP address if the gRPC service returns too many errors? How does it know which errors should trigger this? A HTTP error of 403 could alert the gateway that the endpoint is getting attacked, but what about gRPC?

1
If you have enabled IAP on Cloud Run, then IAP verifies the identity token before forwarding the request to your service. Hackers can send all the fake tokens they want and they will not get through to your service or incur charges. Edit your question with details on how Cloud Run is set up for authorization.John Hanley

1 Answers

2
votes

Part I.

So lets clarify some facts to realize why you need another layer.

Cloud Run is just the HTTP service. And as you mentioned, if you let the traffic hit it, you will pay all the traffic, that's why you need another layer before "that's designed" for a specific purpose. There are other layers that can be placed before like Cloud Armor, Load Balancer, Identity-Aware-Proxy. Those are standalone products, with their own docs/config, and their own pay per use model.

Part II.

Also look into API Gateway for gRPC, you can use the API management capabilities of API Gateway to add monitoring, hosting, tracing, authentication, and more to your gRPC services on Cloud Run.

In addition, once you specify special mapping rules, API Gateway translates RESTful JSON over HTTP into gRPC requests. This means that you can deploy a gRPC server managed by API Gateway and call its API using a gRPC or JSON/HTTP client, giving you much more flexibility and ease of integration with other systems.

You can create gRPC services for API Gateway in any gRPC-supported language.