iam.serviceAccounts.signBlob is missing despite service account having role SA Token Creator

[cpetrenciuc]

Project 1 is containing a service account and a Cloud Run service developed using Java which is setup to use the identity of this service account. This Cloud Run service creates buckets in a second Google Cloud project and generates a signed Url for each bucket it creates.

In the second project we have granted to the service account from Project 1 the following roles at project Level: 

• Service Account Token Creator
• Storage Admin

If we do not specify for our Cloud Run service the environment variable GOOGLE_APPLICATION_CREDENTIALS with the path to a JSON key for the service account from Project 1, the application is able to create buckets but it is not able to create signed Urls. The error message says that the permission iam.serviceAccounts.signBlob is missing.
If we define a Google Cloud Secret containing the JSON key for the service account and we mount this secret as a volume for our Cloud Run service, and we put in GOOGLE_APPLICATION_CREDENTIALS environment variable the path to this JSON key file from the mounted volume, then the application is able to generate signed Urls.

Why it is not enough to just specify this service account as Cloud Run service identity? Why do we have to do this hack with a secret containing the service account JSON key mounted as a volume and referenced through GOOGLE_APPLICATION_CREDENTIALS?

Thank you. 

[ronnelg]

Hi @cpetrenciuc,

Welcome to Google Cloud Community!

The error message that you encountered, permission iam.serviceAccounts.signBlob is missing typically means that the service account you're using doesn't have the necessary permissions to generate signed URLs.

But in your case, the Service Account Token Creator role is already granted to the service account, which is the "iam.serviceAccounts.signBlob" permission should be included.

There are several scenarios why you might still get the permission iam.serviceAccounts.signBlob is missing error even after adding the "Service Account Token Creator" role. Here's how we can try to troubleshoot the issue:

1. Propagation delay: Sometimes, it can take a few minutes for the role changes to propagate across GCP. Wait for a few minutes and then try again.
2. Incorrect service account: Double check that you're using the correct service account credential in your code or configuration. Ensure that it is the same service account where you granted the role.
3. Caching issue: Some client libraries might cache credentials or permissions. Try clearing the cache or restarting your application to ensure it is using the updated permissions.
4. IAM service account credential API: Check if the API is enabled in order to impersonate a service account and to generate short live credentials.

Regarding to your question as to why you need to do the hack with a Google Cloud Secret containing the service account JSON key mounted as a volume and referenced through GOOGLE_APPLICATION_CREDENTIALS, you may submit a ticket to Google Cloud Support for further investigation with your project.

I hope the above information is helpful.

[cpetrenciuc]

Hello @ronnelg,

Thank you for your reply but I do not think either of the 4 possible causes you've listed here apply.

It cannot be a propagation delay since the role Token Account Creator has been granted to this service account several days ago. 

It cannot be a spelling mistake of the service account email address since our two projects have only one service account named like that which, by the way, is created by Terraform and assigned as identity to our Cloud Run service also by Terraform. 

It can't be a caching problem, or if it is it's something that we can't control. In the span of 3 hours we deployed several versions of this Cloud Run service and none of them worked. I had to do the hack I mentioned with the environment variable to make the Cloud Run service work. It should have been enough just to set the Cloud Run identity. I never had this problem with Cloud Run services developed in Net.