Container crash "Unable to verify OIDC token oidc: expected audience..." about gce_metadata_server HOT 6 CLOSED

i'll look into this a bit tomorrow but why run the emulator within Cloud Run instance (its really only designed for local testing)? the reason i say this esp for cloud run, cloud functions, etc, is that they already have a metadata server therer already. ...or are you trying to use the metadata server somehow as a way to impersonate (in that case, you can just use the IAM api:
https://github.com/salrashid123/gcpsamples/tree/master/impersonated_credentials

plus for cloud run to cloud run auth, it'd be id_tokens, (not just access_tokens)
https://github.com/salrashid123/google_id_token

from gce_metadata_server.

why run the emulator within Cloud Run instance (its really only designed for local testing)

In this case it’s only ever being run locally (via docker-compose) as a sort of poly fill so that requests issued to metadata.google.internal will work locally just as they would in production without having to change code (in this case, an NGINX proxy_pass for example). The curl commands are issued from the command line on the same container that nginx is running (that’s the docker-compose exec proxy bash command above). Or, maybe I’m misunderstanding?

from gce_metadata_server.

Rereading your question above...

The secret referenced in --serviceAccountFile /conf/sa.json Is just a non-committed service account JSON key that I’m using for local development only and doesn’t end up in production in any way whatsoever.

I’m not super-familiar with how Google’s IAM works, but just to confirm: The result coming from http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=[Google Run URL] in production is an OIDC token, correct? This is a.k.a. id_token right? It’s not an access_token? What’s the difference?

Also, my use case (if it helps): I’ve simply implemented a proxy that lives in Cloud Run (an “unauthenticated” instance) that allows me to authenticate regular end users in an arbitrary/proprietary way. Then once authenticated with the proxy using my own technique (and setting a cookie so I can remember them), that proxy uses this method (request to the Google metadata server with the appropriate audience) to get the id_token [?] that it then injects into the Authorization: Bearer ... header right before it proxies the request to the authenticated Cloud Run instance.

I only happened to notice this problem because I was going to add a second upstream authenticated Cloud Run instance to my proxy and wanted to get Google’s id_token for that other instance. Presumably this won’t be an issue in production, but was just testing locally in development.

Hope this helps clarify!

from gce_metadata_server.

i think part of the issue was a lazy hack i had put into a dependency oauth library referenced by the metadata server (the metadata server uses https://github.com/salrashid123/oauth2 for id_token stuff)

that code was updated back in Feb to remove a silly mandatory verification step but i never updated the actual dockerhub image since last Sept.

I just uploaded a :dev image just now for the metadata server. Could you try running that one instead (or build your own image if you'd like based in the HEAD of gce_metadata_server.

from gce_metadata_server.

couple more notes and response:
yeshttp://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity? gives an id_token (you use that to access things like other cloud run instances, cloud functions, endpoints, etc). An access_token on the otherhand is an oauth2 token that you would use to perform crud operations against GCP resources themselves (eg, create a cloud function, create a vm, etc). The id_token can be thought of as a token to invoke your service (on cloud run). an access token is used to invoke a GCP resource itself (eg, compute engine api)

just fyi, if you want to manage a custom auth scheme, you may want to look at identity platform: this allows you to define multipl authentication systems and manage your users
https://cloud.google.com/iap/docs/enable-external-identities
https://cloud.google.com/iap/docs/cloud-run-sign-in

from gce_metadata_server.

tagged dev->latest which includes the idtoken/verify update
https://hub.docker.com/layers/salrashid123/gcemetadataserver/latest/images/sha256-a616518cd5ebd3e333a90731c6c580b7e4fcce47084880fc1bf42edc8a9bf6cf?context=explore

from gce_metadata_server.