Can't disable inherited IAM organization policy Service account key creation blocked at project lev

Google Cloud Database
1

Hi, I’m currently managing a GCP project and trying to enable service account key creation for a specific project. However, the inherited organization policy iam.disableServiceAccountKeyCreation (legacy) is enforced, and prevents all key creation—even though I am the Super Administrator for the Google Workspace domain and have full permissions (including org admin roles in Google Cloud).

What I’ve tried:

  • Created and assigned the Organization Policy Administrator role

  • Attempted to override the policy at the project level (no effect due to enforcement at org level)

  • Attempted to migrate to the managed constraint (iam.managed.disableServiceAccountKeyCreation) and set it to “Not enforced” (no effect)

  • Verified through UI and gcloud that the project is not allowed to override the parent policy

Despite these attempts, service account key creation is still completely blocked on the project. I am unable to proceed with automation requiring this feature.

Request:
Is there any way to:

  • Fully override or disable this inherited policy at the project level?

  • Identify who at the org level (if any) has the rights to modify the enforced org policy?

  • Get Google support to help unlock the constraint, or validate if the enforcement is locked due to an upper-level constraint I cannot see?

Thanks in advance for any suggestions.

1 Like
2

Hello @Theartofsult , Welcome on Googl****e Cloud Community.

Sad to hear that you have issues with Google Cloud. I’ve created [1].post about similar cases and I have hope that it will helps you fix your problem. Let’s try with this, and if such approach won’t work for you, we will try to handle this somehow :slightly_smiling_face:

[1.] https://medium.com/google-cloud/troubleshooting-101-solving-the-service-account-key-creation-is-disabled-error-9dd88c45cee4

If this helped, mark it as a “Accepted Solution”! :blush:

–
cheers,
Damian Sztankowski | GDE Googl****e Cloud
LinkedIn | medium.com | Sessionize | Youtube | Developers Profile

1 Like
3

Subject: Access Limitation Regarding Service Account Key Creation Policy

Dear [Name],

Thank you for the detailed documentation regarding the service account key creation policy.

I would like to inform you that I am the registered owner of the domain and also serve as the primary administrator for the Google Cloud project in question. However, the procedure outlined for re-enabling key creation (via Organization Policy Admin or TAG-based exception) appears to require a higher level of administrative access at the organization level – access which we currently do not possess.

We therefore opted to work around the restriction by using a new Gmail account, which is not governed by any existing organization policies.

Should there be any alternative path or assistance available for enabling key creation without full organization-level access, I would be grateful for your advice.

Best regards, Sult

1 Like
4

Hello @Theartofsult , Welcome on Googl****e Cloud Community.

No. You have to have account with Org Policy Admin role to be able to either turn off restriction or make an exception. There is no other way. However, instead of using keys, you should use Workload Identity Federation which is more secured approach than keys.

–
cheers,
Damian Sztankowski | GDE Googl****e Cloud
LinkedIn | medium.com | Sessionize | Youtube | Developers Profile

5

The iam.disableServiceAccountKeyCreation (legacy) constraint, when enforced at the org level, blocks all service account key creation globally—including in all projects and folders. Even if you’re a Super Admin in Google Workspace, and even with Org Policy Admin or Org Admin IAM roles in GCP, you can only change org policies if you’re assigned IAM permissions on the organization node where the policy is set.

1 Like
6

Hi Damian

Thank you for the clarification and helpful explanation.

I’m currently working on a small-scale RFID-based tracking system for local animal training purposes. The setup involves a physical RFID reader connected to a local Python application, which records chip data and sends it to a Google Sheet in real time using the Google Sheets API. This process requires server-to-server authentication, and until now, using a service account with a key file has been the most straightforward method.

Since this is a local setup (not running in Cloud Run or GitHub Actions), switching to Workload Identity Federation would require significant infrastructure changes that may not be feasible for this use case. The hardware is deployed in offline or semi-connected environments, and the scripts run directly on a local machine or edge device.

Unfortunately, the project is restricted by organization-level policies under a Workspace domain I control, but which still blocks service account key creation. As a workaround, I’ve considered switching the project to a standard Gmail account that allows service account keys, but that feels like a workaround rather than a scalable solution.

Would you say that for local, standalone devices pushing to Google Sheets, there’s still no supported alternative to key-based service accounts?

I appreciate any further thoughts or advice you may have.

Best regards, Sult

7

I understand, thx for answer. :slightly_smiling_face:

1 Like
8

Hi @Theartofsult ,
With addition what @bhaweshkumar wrote. You can either follow your approach ( but this is far from ideal state imho) or you can make an exception for your project ( exact way how to configure exceptions, have been described under the link from my first reply). And no, if you have Org Policy Admin permissions, YOU ARE ABLE to turn off fully organization policies. The challenge here is, when you are the Workspace SuperUser and do not explicitly grant Org Policy Admin role to your user, you are not able to manage Google Clouds. This is called separation of duties. So, decide what will be faster to you:

  1. following your workaround approach
  2. Making exception based on my instructions.

PS: If you need help, we can make a video meet and I’ll try to guide you what should be done :slightly_smiling_face:

–
cheers,
Damian Sztankowski | GDE Googl****e Cloud
LinkedIn | medium.com | Sessionize | Youtube | Developers Profile

9

Hi @Damian Sztankowski and all,

First of all – thank you so much for the helpful replies and the kind offer to assist further :folded_hands: I really appreciate the tone and support here.

After giving it some thought, I’ve decided to drop the “Keys and Org Policy” topic altogether for now – it’s a bit over my head and too complicated for my personal use case.

Let me briefly explain my current situation:

I’m working on a personal project for my pigeon loft (yes, real pigeons :dove: ). I’m building a custom registration system that records the return time of pigeons during training sessions using RFID tags. The system is currently running through Google Sheets and AppSheet, and I’ve been using a PC setup with Python and Excel to capture data from a 125 kHz RFID reader.

Now I’m exploring whether I can move this over to a mobile phone setup, using a 125 kHz USB RFID reader connected via USB-C directly to an Android phone. My hope is that the phone can capture tag data and log it (ideally automatically) to Google Sheets or through a lightweight app interface – with no PC involved.

I came across the open-source IDRW Android project on GitHub, which seems promising for reading RFID tags via USB-HID on Android. I haven’t tested it yet, but I plan to.

So now I’m wondering:
Has anyone here successfully used a mobile phone to collect RFID data via USB and send it directly to Google Sheets or a similar cloud backend?
Do you know of any other Android apps or approaches that could help with this kind of “phone-to-cloud via RFID” pipeline?

I know this is a niche case, and I’m only building this system for myself and my own pigeons – but I’d love to hear your suggestions or thoughts if you’ve dealt with something similar. If there’s a better approach than what I’ve described, I’m absolutely open to new ideas.

Thanks again for your time and support!

Best regards, Sult (by the way, “Sult” is a book written by Knut Hamsun, Fantastic)