Correct permission required to run `gcloud identity groups` as a Service account [270173267]

Assigned

Feature Request

Status Update

No update yet.

Description

rm...@google.com

created issue #1

Feb 21, 2023 07:15PM

Problem you have encountered:

The current doc[1] doesn't have any guideline on what are the Roles required to run the gcloud identity groups describe (and other subcommands[0]) as a Service Account and always produces an error[2] regardless of the IAM roles applied to it.

What you expected to happen:

Should be able to run gcloud identity groups .. as a Service Account.

Steps to reproduce:

Create an SA, and grant it a Viewer Role
Impersonate the SA using either [3] or [4]
Describe an existing group by running gcloud identity groups describe <groupemail>

Workaround:

Assign the Workspace/Cloudidentity role Group Administrator to the Service account by following this instructions[5], the Service account doesn't need any other IAM role.

===


[0] 
gcloud identity groups create
gcloud identity groups delete
gcloud identity groups describe

[1] https://cloud.google.com/sdk/gcloud/reference/identity/groups/memberships/list

[2]  ERROR: (gcloud.alpha.identity.groups.describe) Invalid value for [--email]: There is no such a group associated with the specified argument: group-xxx@domain.com

[3] https://cloud.google.com/sdk/gcloud/reference/auth/activate-service-account
[4] https://cloud.google.com/iam/docs/impersonating-service-accounts

[5] https://cloud.google.com/identity/docs/how-to/setup#auth-no-dwd

Comments

sa...@google.com <sa...@google.com> Feb 22, 2023 04:30AM

Assigned to sa...@google.com.

sa...@google.com <sa...@google.com> #2Feb 22, 2023 01:43PM

Reassigned to gc...@google.com.

Hello,

Thanks for reaching out to us!

The Product Engineering Team has been made aware of your feature request, and will address it in due course. Though we can't provide an ETA on feature requests nor guarantee their implementation, rest assured that your feedback is always taken very seriously, as it allows us to improve our products. Thank you for your trust and continued support to improve Google Cloud Platform products.

In case you want to report a new issue, please do not hesitate to create a new [Issue Tracker] 1 thread describing your issue. Once again, thank you for the suggestions.

Thanks and Regards,
Onkar Mhetre
Google Cloud Support

be...@google.com <be...@google.com> #3Dec 19, 2023 09:34PM

Specifically, this happened to us. We have a GKE cluster with two similarly-sized node pools. One has E2 nodes and the other has C2D nodes. We wanted to temporarily double the size of our E2 nodepool and checked the quotas page first. The only quota in the entire GCP project that was above 20% was "CPUs" at 55%. We reasoned that since only half of our machines were in the nodepool we wanted to double, this would only raise us to around 80-85% of quota, which seemed safe for a temporary change. We were surprised to see our scale-up fail due to quota. (And then we clumsily tried to quickly scale down to get below quota using direct GCE ASG scaling rather than GKE autoscaler, which ended up deleting a bunch of our more active machines instead of the empty ones — perhaps user error, but a bigger impact than we had expected for what we thought was going to be a simple "scale up fast, let it scale down slowly once our temporary need was over".)

Had the human-readable label in the UI said "E2 and N1 CPUs" instead of "CPUs" we would not have made that mistake: we would have tried for a smaller scale-up or requested more quota first.

I assume that the "internal"/computer-readable name `CPUS` is unlikely to change for compatibility reasons, but hopefully the UI display name is less hardcoded?

MicrosoftTeams-image.png

53 KB

View

Download