Feature: Avoid impersonation

[philomory]

Issue #, if available:

192

Description of changes: Replaces --google-admin (and associated environment variables, template options) with --customer-id, while incorporating @behobu's changes from #192. This allows the app to function without needing to impersonate an Google Workspace admin user.

I'm not as confident in the CF/SAM changes as I am in the code changes; if desired, I have an alternative branch I can recreate the PR using, which only changes the app code, and which would allow you to handle the templates as you see fit.

Also note that as-implemented, the code currently replaces the --google-admin option with the --customer-id option. For my own purposes, this was acceptable, even desirable, but if retaining the option to do user impersonation is desirable it probably wouldn't be too hard to adjust things so you can pass either option (though not both).

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[philomory]

I've just noticed that my editor seems to have made some unnecessary whitespace changes, I'll try to revert those.

[bburky]

Thanks, this feature looks nice. I was hoping to avoid domain-wide delegation, and impersonating a real Google account.

You could leave--google-admin as an optional argument (when omitted, use the service account).

Similarly --customer-id could be optional too, defaulting to my_customer. But it would be confusing to have these two options' defaults be opposites and incompatible. It's probably clearer to have it be a required option, and tell users to provide my_customer if they want to use domain-wide delegation to an impersonated super admin user and provide the user email as --google-admin.

(I'm not sure if there's any real advantage to an impersonated user, it seems worse to me. But supporting both may allow easier migration between them? Switching over entirely to non-impersonated seems better to me, but is a bigger breaking change.)

Because the Google docs aren't too clear on this, it's probably worth adding a note to the README to point specifically to the "Assign a role to a service account" docs section and explain how to set up the service account: https://developers.google.com/workspace/guides/create-credentials#assign_a_role_to_a_service_account

• I would suggest to create a custom admin role limited to only user API read and directory API read. Grant the admin role to the service account with "Assign a role to a service account". The service account's maximum permissions are those of the Admin role (the service account will not be restricted to specific OAuth roles like with domain-wide delegation).
• The "Optional: Set up domain-wide delegation for a service account" steps can be skipped entirely. This method does not use domain-wide delegation at all or impersonation.