[feat] Support workload identity in GCP

[mlutx]

Is your feature request related to a problem? Please describe.
Workload identity is supported by Apigee Hybrid, it is more secure and does not require key generation. (In some environments, service account key generation is not allowed by organization policy).

Describe the solution you'd like
when gcp.workloadIdentityEnable is set to true, no more check on serviceAccountRef during input check

Describe alternatives you've considered
No

Additional context
https://cloud.google.com/apigee/docs/hybrid/v1.10/install-configure-cluster.html#gke---workload-identity

[RiflerRick]

@anaik91
in terms of the requirement, I see that the overrides file of helm supports a workloadIdentity section: https://cloud.google.com/apigee/docs/hybrid/v1.11/config-prop-ref#gcp-workloadidentity-enabled

AFAIU, in the current configuration, we are using the create_service_account variable to create the service account and then generating the service account secret which is mounted as a volume in the corresponding deployments.

From the perspective of helm, it is simply a config that we have to enable. Currently the overrides.yaml.j2 file does not have the workloadIdentity.enable variable.

The vars file might look something like this:

create_service_account: true
gke:
  workloadIdentity:
    enabled: true
    gsa:
      connectAgent: <IAM SA for connectAgent>
      runtime: <IAM SA for runtime>
      synchronizer: <IAM SA for synchronizer>
      ...

Each of the GSA keys correspond to the google service accounts for the corresponding components.

• If workloadIdentity.enabled is false, the normal route is followed for creating kubernetes secrets and mounting them onto the deployments.
• if it's enabled and create_service_account is false, it is assumed that the service accounts for the components mentioned already exist and all we need to configure is the WI
• if create_service_account flag is true, the gsa component service accounts are ignored.

Let me know how you feel about this!

[anaik91]

@RiflerRick : Please do the following

• Since the WI enabled flag needs to go to overrides put in the gcp section of overrides , like the rest of the gcp variables
  overrides.gcp.workloadIdentity.enabled
  refer : https://github.com/apigee/ansible-apigee-hybrid-accelerator/blob/main/vars/test.yaml#L104

• Make the relevant changes to the jinja template after the following line .

• Keep the gsa params distributed across given that they are specific to overrides

  overrides.connectAgent.gsa
  overrides.envs.gsa.runtime
  overrides.envs.gsa.synchronizer
  overrides.envs.gsa.udca
  overrides.logger.gsa
  overrides.mart.gsa
  overrides.metrics.gsa
  overrides.udca.gsa
  overrides.watcher.gsa
  Set the defaults for each gsa in the role so that even if WI is enabled and user doesnt give gsa in overrides it ll pick defaults

[RiflerRick]

@RiflerRick : Please do the following

• Since the WI enabled flag needs to go to overrides put in the gcp section of overrides , like the rest of the gcp variables
  overrides.gcp.workloadIdentity.enabled
  refer : https://github.com/apigee/ansible-apigee-hybrid-accelerator/blob/main/vars/test.yaml#L104
• Make the relevant changes to the jinja template after the following line .
• Keep the gsa params distributed across given that they are specific to overrides
  overrides.connectAgent.gsa
  overrides.envs.gsa.runtime
  overrides.envs.gsa.synchronizer
  overrides.envs.gsa.udca
  overrides.logger.gsa
  overrides.mart.gsa
  overrides.metrics.gsa
  overrides.udca.gsa
  overrides.watcher.gsa
  Set the defaults for each gsa in the role so that even if WI is enabled and user doesnt give gsa in overrides it ll pick defaults

Thanks