Offer OIDC as an alternative way for authentication to GCP APIs to eliminate/reduce the usage of static secrets

[donistz]

How to categorize this issue?

/area security
/kind enhancement
/priority 2
/platform gcp

What would you like to be added:
Gardener to start supporting OIDC authentication for GCP APIs as an alternative to service account keys
Why is this needed:
Offering an alternative method for Gardener service authentication to GCP APIs (by using OIDC) for managing consumer project resources will help many Gardener service users to stop operating GCP service account keys (static secrets) and comply easier with their corporate security regulations.

At the moment Gardener can use only service account keys for the authentication to the GCP APIs when managing consumer resources in the GCP projects. Service account keys are powerful credentials, and can represent a security risk if they are not managed correctly. Some corporate security requirements expect consumers to rotate often(automatically) GCP service account keys and this brings complications for Gardener service consumers.

Google experts, on their side, strongly recommend the usage of the new feature "Workload identity pools" where, trusted identity providers are configured and their tokens are used to obtain via the STS API short-lived access token for acessing Google Cloud resources. A Kubernetes cluster could be used, for example, as a workload identity provider inside a Google project which makes a perfect fit for the Gardener authentication scenario to GCP APIs.

Gardener has to be improved to start supporting such OIDC authentication for GCP APIs and the OIDC provider should be the Garden Virtual cluster because this is the central K8S cluster in the Gardener landscape that is also storing the resource data for every project and can be configured as trusted workload identity provider on all integrated via OIDC GCP projects no matter which one will be the Gardener Seed cluster that will manage the shoot clusters inside these GCP projects.

Gardener operator: The new feature should be optional (alternative to the standard solution for backward compatibility) and a configuration in the gardener-extension-provider-gcp will have to provide the info if the OIDC is supported or not for a Gardener landscape. Gardener operator will have to be able to configure (switch-on) the OIDC provider option.

Gardner project admin: When the new OIDC feature is enabled for the gardener-extension-provider-gcp, the Gardener project admin will have to be able to choose between two configuration options for the GCP secrets:
[1] configure a secret with providing only the GCP project ID - this way the user will declare the agreement Gardener to use OIDC authentication and will be responsible to configure Gardener as a workload identity provider on his/her GCP project
[2] configuring a GCP secret (like at the moment)

Details on this topic: GCP - Workload identity federation