Skip to content

Add identity_provider YAML config entry

Pedro Pombeiro requested to merge pedropombeiro/438420/add-yaml-element into master

What does this MR do and why?

This MR adds support for the identity_provider YAML config entry, behind the ci_yaml_support_for_identity_provider feature flag, and the google_artifact_registry SaaS feature (temporary solution, as a new feature is being developed in a separate MR). Adding such a entry will cause the build to expose the following 2 file variables, which will facilitate access to GCP without additional work from the developer:

  • CLOUDSDK_AUTH_CREDENTIAL_FILE_OVERRIDE (for gcloud CLI)
  • GOOGLE_APPLICATION_CREDENTIALS (for client libraries)

NOTE: This MR contains a commit from !142973 (merged), so that it can be ready to review in its final form. We need to merge that MR first.

TODO

  • Read wlif claim value from artifact registry project integration
  • Use GCP client being developed in #425147 (closed) to replace config.json generation code in Ci::Build
  • Add missing specs
  • Double-check JSON schemas
  • Clean up code

Closes #438420 (closed)

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

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

build.options: image

scenario screenshot
validation failed image
validation successful image
integration not configured image
integration configured, build showing contents of injected environment variable image

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

SaaS scenario

  1. Ensure you have an Ultimate license applied to your GDK.

  2. Simulate a SaaS instance:

    export GITLAB_SIMULATE_SAAS=1

  3. Run Feature.enable(:ci_yaml_support_for_identity_provider) to enable the functionality.

  4. It is only possible to test the validity of the JWT token on .com (or with membership to a demo GCP project and some magic steps), which would have the correct token required for the glgo token exchange service, but we can test the config.json generation locally with the following job:

    test_job:
  stage: build
  identity_provider: google_cloud
  script:
    - cat $CLOUDSDK_AUTH_CREDENTIAL_FILE_OVERRIDE | jq

Non SaaS scenario

  1. Simulate a FOSS instance
  2. Run the job. It should not be able to access GCP.

Helpful links

Edited by Pedro Pombeiro

Merge request reports