Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Cloud Run job in an assured workload folder fails when using secrets

Hi all,

We have migrated our project to an assured workload folder and since then we have gotten permission exceptions when starting Cloud Run jobs due to missing access permissions to a secret. The exception basically states:

"The service account used must be granted the 'Secret Manager Secret Accessor' role (roles/secretmanager.secretAccessor) at the secret, project or higher level."

We already granted the service account the 'Secret Manager Secret Accessor' role at a secret level before we migrated to an assured workload folder. So the exception message seemed to be somewhat misleading. We then tried to give more permissions and granted the 'Secret Manager Secret Accessor' role at the project level. This worked, the Cloud Run jobs are running now without failures.

So I wanted to ask, if this is a known bug? Or if this is expected behavior when running in an assured workload folder?

Second question I wanted to ask in regard to Cloud Run jobs, assured workloads and secret manager is, if anybody knows when regional secrets are planned to be implemented in Cloud Run jobs?

Thanks!

Solved Solved
0 2 408
1 ACCEPTED SOLUTION

Hi @sfrutig,

Welcome to Google Cloud Community!

It definitely sounds like a frustrating experience when permissions that should work suddenly don't after a migration. So to answer your questions: 

Is this a bug or expected behavior in Assured Workloads? - That permission error after moving to Assured Workloads is likely expected, not a bug. Assured Workloads adds strict compliance checks. These checks might demand broader permissions (like project-level access you granted) to validate access across its compliance boundary, making the old secret-level permission insufficient. The error message is generic and doesn't explain this Assured Workloads context. 

When will regional secrets be supported in Cloud Run jobs?Secret Manager itself supports regionalization, allowing you to store secrets in specific regions. However, as for when Cloud Run jobs will support regional secrets specifically, there's no public timeline announced by Google Cloud yet. I'd suggest to keep an eye on the official Cloud Run release notes for updates. 

Was this helpful? If so, please accept this answer as “Solution”. If you need additional assistance, reply here within 2 business days and I’ll be happy to help.

View solution in original post

2 REPLIES 2

Hi @sfrutig,

Welcome to Google Cloud Community!

It definitely sounds like a frustrating experience when permissions that should work suddenly don't after a migration. So to answer your questions: 

Is this a bug or expected behavior in Assured Workloads? - That permission error after moving to Assured Workloads is likely expected, not a bug. Assured Workloads adds strict compliance checks. These checks might demand broader permissions (like project-level access you granted) to validate access across its compliance boundary, making the old secret-level permission insufficient. The error message is generic and doesn't explain this Assured Workloads context. 

When will regional secrets be supported in Cloud Run jobs?Secret Manager itself supports regionalization, allowing you to store secrets in specific regions. However, as for when Cloud Run jobs will support regional secrets specifically, there's no public timeline announced by Google Cloud yet. I'd suggest to keep an eye on the official Cloud Run release notes for updates. 

Was this helpful? If so, please accept this answer as “Solution”. If you need additional assistance, reply here within 2 business days and I’ll be happy to help.

Hi @sfrutig ,
This is expected behavior — in Assured Workloads, resource policies can be stricter, and secret access often needs to be set at the project level, not just on the secret.

About regional secrets for Cloud Run jobs: Google has not announced a timeline yet. Best to watch the Google Cloud release notes or submit feedback through your account rep or support.