Rate limits on metadata server access token requests

[kevinAlbs]

Hello,

I want to get the access token for an attached service account without using a Google auth library.

Referring to AIP-4115, I am able to obtain an access token by making a request to the metadata server:

curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Output resembles the following:

{ "access_token": "...", "expires_in": 3599, "token_type": "Bearer" }

My question is: Is there a rate limit for these requests?

Other relevant background and research:

• This only needs to work on GCE Equivalent Runtimes
• GCE documentation says the metadata server caches tokens, so this may suggest there is no rate limit:

Access tokens expire after a short period of time. The metadata server caches access tokens until they have 5 minutes of remaining time before they expire. You can request new tokens as frequently as you like, but your applications must have a valid access token for their API calls to succeed.

• https://stackoverflow.com/questions/58495465/what-is-the-rate-limit-for-gce-instance-metadata-servic... asks a similar question but is unanswered.
• I attempted to make repeated requests in a loop to the metadata server, but did not receive any error.

Thank you.

[grobledo · Accepted solution]

There is no rate limits other than what the Metadata Server can handle. In a normal situation, you should not have any issues with that.

[Clouds]

 

Startup and shutdown scripts

The metadata server is particularly useful when used in combination with startup and shutdown scripts because you can use the metadata server to programmatically get unique information about a VM, without additional authorization.

For example, you can write a startup script that gets the metadata key value pair for a VM's external IP and use that IP in your script to set up a database. Because the default metadata keys are the same on every VM, you can reuse your script without having to update it for each VM. This helps you create less brittle code for your applications.