Update the Kubernetes Executor to use Secret instead of ConfigMap
What does this MR do?
This MR replaces the Kubernetes Executor's usage of a ConfigMap to hold the execution script with a Kubernetes Secret.
Why was this MR needed?
Copied from commit message:
The existing code generates the script to be run and places it in
a Kubernets ConfigMap, before attaching to the pod and executing
said script. The issue with this is that the script contains the
entire configuration environment, including user defined secrets
and GitLab defined secrets like CI_JOB_JWT. Kubernetes ConfigMaps
are not a suitable place to store values like these; generally
speaking the ability to read ConfigMap values in a cluster is not
restricted as much as the ability to read Secrets. The result is
that GitLab can leak secret values to users who should not have
permission to see them.
To solve this issue, either the attach method of running scripts
needs to be re-architected or a change like this commit needs to be
applied. This commit converts the ConfigMap usage to a Secret, which
better suites the contents.
What's the best way to test this MR?
I don't know how to test the gitlab-runner in general (the unit tests do not pass on the un-altered main branch on my system). Assuming this gets running in some environment though:
- Kick off a CI/CD Job, something like:
Test:
script:
- sleep 900- Verify that a Secret is created with the
-scriptssuffix - Verify that the Secret contains the expected script with a command like:
kubectl get secret -o json <secret name> | jq -r '.data."get_sources"' | base64 -d.