Audit logs showing cloud-support@google.com acting as principal for group membership update [352704075]

Assigned

Bug

Status Update

No update yet.

Description

wa...@google.com

created issue #1

Jul 12, 2024 11:24AM

This will create a public issue which anybody can view and comment on.

Please provide as much information as possible. At least, this should include a description of your issue and steps to reproduce the problem. If possible please provide a summary of what steps or workarounds you have already tried, and any docs or articles you found (un)helpful.

Problem you have encountered:
Cx is observing "cloud-support@google.com" acting as principal making changes to group membership.
These logs are appearing due to the creation of a new Workspace user that had existing memberships as a non-google Workspace user.

As documented [here](

https://support.google.com/a/answer/9484090?hl=en&ref_topic=1685690) "You can add members without Google Workspace email addresses to groups. If you later create Google Workspace user accounts for those email addresses, group memberships are automatically transferred to the new accounts." So the newly-created user had existing memberships previously as a non-google account, those memberships were being transferred to their new account.

There is a background process that is adding the newly created matching user to the group and removing the placeholder or unclaimed "other" user from the group. This behaviour is documented [here](

https://support.google.com/a/answer/7664944?hl=en&ref_topic=1685690&sjid=15120872984654266379-NC) .

When the background process is making the changes, the log entry to this change is reflected under principal cloud-support@google.com

This is causing confusion to Cx.

What you expected to happen:
If it is background process then there should not be any log entry which is not providing any meaningful information to cx

Otherwise, Cx is thinking that Google cloud support is making changes to their user membership

Steps to reproduce:

Other information (workarounds you have tried, documentation consulted, etc):

Comments

ka...@google.com <ka...@google.com> Jul 12, 2024 11:56AM

Reassigned to on...@google.com.

on...@google.com <on...@google.com> #2Jul 12, 2024 02:18PM

Reassigned to gc...@google.com.

I have forwarded this request to the engineering team. We will update this issue with any progress updates and a resolution.

Best Regards,
Josh Moyer
Google Cloud Platform Support

t....@metro.digital <t....@metro.digital> #3Jul 29, 2024 04:29PM

This is not only useful for IP addresses, but also for many other resources. I understand that names are currently used as identifiers, so this request is probably not trivial to implement. Maybe distinguishing between a (numeric, automatically generated) identifier and a (textual) label is the way to go?

ma...@google.com <ma...@google.com> #4Jul 31, 2024 11:25AM

Reassigned to ma...@google.com.

Is it any hope? We have migrated our IP address to the server with different role, and now the name of this IP address resource doesn't match its role at all. It seems to be trivial enough to momentary reserve static IP address of the old named resource, drop resource, and immediately recreate it with the new name and the old IP address.

ma...@google.com <ma...@google.com> Jul 31, 2024 01:30PM

Reassigned to gc...@google.com.

Issue 352704075