Skip to content

Rename wlif parameters to more accurate names

David Fernandez requested to merge 440252-rename-wlif-param into master

🐟 Context

We are currently building the support for Google Cloud services.

For the authentication part, we leveraged the workflow identity federation.

For that, we are managing several parameters that are required.

One of them has been named wlif since the beginning but as explained here, that name is misleading.

We actually have two different things:

  1. The audience field in the credentials structure.
  2. The aud (audience too 😼) that we need to set for the tokens that are presented to the workload identity federation.

We were confused because by default, both aspects are set to the exact same value. As such, we called it the wlif string.

To clear the confusion, we need to use more accurate names for each part:

  1. identity_provider_resource_name. (A workload identity pool has many identity providers and we need to tell the authentication which one we should use = we need the resource name). This string has a very strict format: //iam.googleapis.com/projects/<project-number>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>.
  2. target_audience. As discussed here.

🔬 What does this MR do and why?

  • Rename wlif to identity_provider_resource_name in the Google Cloud logic that builds the credentials structure.
  • Rename wlif to target_audience in the JWT that are sent to glgo.
  • Update the related specs.

While at it, I also:

  • Renamed a few variables from gcp_x to google_cloud_x as we shouldn't use gcp.
  • Simplified the client classes initialize function by sending the project integration objects.

These changes are a refactoring that has no impact in the existing behaviors. If there is an impact that should be considered as a bug.

Lastly, the entire Google Cloud support is behind (multiple) feature flag and a saas only flag.

⚙ MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

☎ Screenshots or screen recordings

No UI changes.

⚙ How to set up and validate locally

We can re-use the past MR set ups for local validation:

Related to #440252 (closed) and https://gitlab.com/gitlab-org/gitlab/-/issues/439731

Edited by Pedro Pombeiro

Merge request reports