As Security Officer I do not want RAM to impersonate a SuperAdmin when analyzing GCI assets

[BrunoReboul]

Current State

RAM does not use superAdminEmail to analyze GCP assets.
This setting is required only to analyze GCI group settings and or GCI group membership.
To do so 4 microservices [listgroup, listgroupmembers and getgroupsettins for the batch mode and convertlog2feed for real time mode] are consuming the Workspace Admin SDK / Directory API

The authentication mechanism used to access this API is the function JWTConfigFromJSON which returns a jwtConfig
The field Subject of the jwtConfig must be set to the email address of a superAdmin to impersonate while consuming the API.
this action is performer is this RAM utility function getJWTConfigAndImpersonate in this line of code

This authentication mechanism is described in the directory API documentation section Delegate domain-wide authority to your service account
"To access user data on a Google Workspace domain, the service account that you created needs to be granted access by a super administrator for the domain"

The code sample how to do it is documented in Instantiate an Admin SDK Directory service object

Desired state

leverage: You can also assign an admin role to a service account, rather than a user. For example, you can use a service account admin to create and update groups and group memberships with applications outside of the Admin console using the Cloud Identity Groups API.

Do no use the suject filed to impersonate (code change, like if empty in solution.yaml, just to not set)
Update documentation with

• From Admin Console / Account / Admin roles
• Create new role, name Real-time_asset_monitor, desc Role used by RAM to analyze GCI assets
• Admin API Privileges
  • group / read
  • domain management
• Assign Service account to the 4 RAM service accouts [listgroup, listgroupmembers, getgroupsettins,convertlog2feed]
  Warning: It can take up to 24 hours for new roles to take effect