Build Runner WLIF integration
Description
Note: This is a duplicate of https://gitlab.com/gitlab-org/gitlab/-/issues/434223+.
Currently, in order to use Workload Identity Federation with GitLab Runner we would need a long and complex configuration (example below has been provided by Jason Collins (Google), reference) (click "Details"):
variables:
AUDIENCE: "//iam.google…/proj…/123456/loc…/global/workl…/gitlab-pr51573878/providers/gitlab"
OIDC_CONFIG: "/tmp/oidc-config-${CI_JOB_ID}.json"
OIDC_JWT: "/tmp/oidc-jwt-${CI_JOB_ID}.txt"
GOOGLE_APPLICATION_CREDENTIALS: "${OIDC_CONFIG}"
CLOUDSDK_AUTH_CREDENTIAL_FILE_OVERRIDE: "${OIDC_CONFIG}"
default:
id_tokens:
GITLAB_OIDC_TOKEN:
aud: $AUDIENCE
before_script:
- echo "${GITLAB_OIDC_TOKEN}" > ${OIDC_JWT}
- |
cat <<EOF >${OIDC_CONFIG}
{
"type": "external_account",
"audience": "$AUDIENCE",
"subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
"token_url": "https://sts.googleapis.com/v1/token",
"credential_source": { "file": "${OIDC_JWT}" }
}
EOF
after_script:
- rm ${OIDC_JWT}
- rm ${OIDC_CONFIG}
script: gcloud compute instances list
variables:
AUDIENCE: "//iam.google…/proj…/123456/loc…/global/workl…/gitlab-pr51573878/providers/gitlab"
OIDC_CONFIG: "/tmp/oidc-config-${CI_JOB_ID}.json"
OIDC_JWT: "/tmp/oidc-jwt-${CI_JOB_ID}.txt"
GOOGLE_APPLICATION_CREDENTIALS: "${OIDC_CONFIG}"
CLOUDSDK_AUTH_CREDENTIAL_FILE_OVERRIDE: "${OIDC_CONFIG}"
default:
id_tokens:
GITLAB_OIDC_TOKEN:
aud: $AUDIENCE
before_script:
- echo "${GITLAB_OIDC_TOKEN}" > ${OIDC_JWT}
- |
cat <<EOF >${OIDC_CONFIG}
{
"type": "external_account",
"audience": "$AUDIENCE",
"subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
"token_url": "https://sts.googleapis.com/v1/token",
"credential_source": { "file": "${OIDC_JWT}" }
}
EOF
after_script:
- rm ${OIDC_JWT}
- rm ${OIDC_CONFIG}
script: gcloud compute instances list
With glgo and the progress we've made on the integration so far, we can use:
mirror:
image: gcr.io/google.com/cloudsdktool/google-cloud-cli:alpine
services:
- name: registry.gitlab.com/gitlab-org/architecture/gitlab-gcp-integration/glgo-token-service:v0.2.0
alias: sts
variables:
GITLAB_WLIF_TOKEN_FILE: "${CI_PROJECT_DIR}.tmp/GITLAB_WLIF_TOKEN"
GITLAB_WLIF_ENDPOINT: "https://auth.gcp.gitlab.com"
DOCKER_HOST: "tcp://docker:2375"
id_tokens:
GITLAB_WLIF_TOKEN:
aud: //iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/gitlab-gcp-demo/providers/gitlab-prod-gitlab-org
script: gcloud compute instances list
mirror:
image: gcr.io/google.com/cloudsdktool/google-cloud-cli:alpine
services:
- name: registry.gitlab.com/gitlab-org/architecture/gitlab-gcp-integration/glgo-token-service:v0.2.0
alias: sts
variables:
GITLAB_WLIF_TOKEN_FILE: "${CI_PROJECT_DIR}.tmp/GITLAB_WLIF_TOKEN"
GITLAB_WLIF_ENDPOINT: "https://auth.gcp.gitlab.com"
DOCKER_HOST: "tcp://docker:2375"
id_tokens:
GITLAB_WLIF_TOKEN:
aud: //iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/gitlab-gcp-demo/providers/gitlab-prod-gitlab-org
script: gcloud compute instances list
But we can simplify this a lot. We could add support for something like:
my-job:
identity_provider:
gcp: my-wlif-alias-1
script: gcloud compute instance list
It would make it so much easier for our customers to use the integration from the CI.
Proposal
In order to implement this, we would need to add support for it into GitLab Runner:
- GitLab starts a job with Workload Identity Federation identifier.
- GitLab generates a JWT token for it, the
id_tokensway. - GitLab sets required environment variables.
Runner generatesconfig.jsonfor gcloud pointing it to glgo as acredential-source-url.- GitLab generates
config.jsonfor gcloud pointing it to glgo as acredential-source-url. The file is exposed as a file variable, so scripts executing in GitLab Runner can take advantage of it without changes to the Runner.- The WLIF schemeless-URI is read from project integration (initially from the GAR integration, until we create a separate WLIF integration, context).
- If WLIF alias is present in integration, gate the functionality on having a matching alias (TBC).
- It just works!
🎉
This is a very important part of the integration that has not been well described before. Arguably more important than anything else, because it allows users to do anything on GCP through GitLab CI, easily.