Refactor GCP auth design with Service Accounts and ADC

What does this MR do?

MR refactors our GCP service account approach to follow best practices, as recommended by Google (#1, #2), as follows:

• Remove use of Default Service Account across stack
• Switch from a GCP Scopes authentication approach to Service Account IAM
• Create dedicated Service Accounts for VM groups with IAM access granted for components that require GCP service access (Object Storage) with the least privileges (minimum permissions and access only to created buckets)
• Removes requirement to upload a Service Account Key and uses Application Default Credentials instead granted to the VM's Service Account (except in one specific instance for GKE backups)
  • This MR does the same for GKE nodes but a future MR will move GKE clusters over to Workload Identity by default where accounts are attached to pods
  • Note that a Service Account key is still specifically required for Toolbox Backups Object Storage access while the rest work with ADC. As such Backups will be made optional until user passes in a specific Service Account key for this. Documentation will be added to guide users through.
• Enforce public access prevention on Buckets also.

Related issues

Closes #314 (closed) #325 (closed) #567 (closed)

Author's checklist

When ready for review, the Author applies the workflowready for review label and mention @gl-quality/get-maintainers:

• Merge request:
  • Corresponding Issue raised and reviewed by the GET maintainers team.
  • Merge Request Title and Description are up-to-date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline
  • MR has no new security alerts in the widget from the Secret Detection and IaC Scan (SAST) jobs.
• Code:
  • Check the area changed works as expected. Consider testing it in different environment sizes (1k,3k,10k,etc.).
  • Documentation created/updated in the same MR.
  • If this MR adds an optional configuration - check that all permutations continue to work.
  • For Terraform changes: set up a previous version environment, then run a terraform plan with your new changes and ensure nothing will be destroyed. If anything will be destroyed and this can't be avoided please add a comment to the current MR.
• Create any follow-up issue(s) to support the new feature across other supported cloud providers or advanced configurations. Create 1 issue for each provider/configuration. Contact the Quality Enablement team if unsure.