SuperFetch is a proxy for UrlFetchApp with additional features – see SuperFetch – a proxy enhancement to Apps Script UrlFetch for how it works and what it does. In this article I’ll cover how to use the SuperFetch api plugin to access IAM Service Account Credentials to authenticate with Cloud Run.
First though, let’s look at in general, how Cloud Run authentication works.
Cloud Run and Cloud Function Authentication with IAM
Both of these need a JWT Id token – not the usual access token that we can easily get from ScriptApp.getOAuthToken() to access most APIs, but the kind of token returned by ScriptApp.getIdentityToken() to identify the current Apps Script user.
This will work for Cloud Functions, but Cloud Run is looking for the identity token of a Service Account. So we need to find a way of generating one of those.
Service Account key files
One way is to use a service account key file (there are plenty of examples of using Service Account with my cGoa library on this site, for example Using a service account) and also creating JWT tokens from Apps Script (for example JWT tokens)
However all of that is a lot of work. Guillaume’s post pointed the way to using Service Accounts without the need for a key file.
Generating an idToken on behald of a Service account with IAM
It turns out that we can use the IAM service account credential API to do exactly what’s needed.
In preparation we need to
- Create or reuse a cloud project and assign it to your Apps Script project in place of the default one that Apps Script creates (You can’t change the settings on that Apps Script managed cloud project to do what we need)
- Give the service account an IAM role that authorizes it to do the work (in this case “Cloud Run Invoker”)
- Make the user account (the email address running the Apps Script) a principal for the service account
- Give the user account the IAM role (Service Account Token Creator) that authorizes it to generate tokens on behalf of someone else
- Enable the IAM API
- Give your Apps Script project “https://www.googleapis.com/auth/cloud-platform” and “https://www.googleapis.com/auth/script.external_request” scopes
Add the user as a principal
Now you should have this on the permissions screen for your cloud-run-invoker service account
SuperFetch and iam plugin
You’ll need the SuperFetch library – details at the end of the article.
The preparation was the hard part. Now we can use the SuperFetch iam plugin to get a drop in replacement for the regular tokenService.
Using the idToken service
Later on in this article, I’ll breifly introduce the gotenberg SuperFetch plugin, but for now you can just access your cloud run instance as normal like this.
Unit testing for Iam plugin
As usual I’m using Simple but powerful Apps Script Unit Test library for testing. Details at the end of the article. Here’s a complete set of tests for the Iam.tokens plugin trying out all the methods
SuperFetch idTokenService plugin
There’s a handy plugin in the SuperFetch library to simplify all that. Here’s how to use it. Just supply your serviceAccount and cloud run endpoint and you’ll get back a function that can generate an id token.
You can use this token to authenticate to any cloud run service that requires authentication. My service looks like this.
Gtb, Cnv and Drv SuperFetch plugins
I’ll cover these plugins in detail in separate articles, but SuperFetch also has plugins for the Drive REST Api, a conversion Api for PDF’s and the Gotenberg API running on cloud run. Here’s how to apply everything I’ve covered in this article to getting pretty much any kind of Office/image type file from drive, converting it to a PDF and writing the converted file back to Drive
Testing Cnv and Gtb plugins
And here’s the tests for the Cnv and gtb plugins