Specify which "user" shall run the job (kubernetes-executor)
## Status update 2025-03-11 - We have added this feature to the 17.11 milestone with the intent of implementing an immediate solution to the problem. - The long term solution for this type of capability as it relates to the K8s executor, is the Pod Spec Overwrite feature. However, the next iteration of that cross group feature is not on the near-term roadmap in the Verify section. Therefore we have opted to go with the near term option. ## Problem to solve Users that use the K8s executor to run GitLab CI/CD jobs need the ability to easily specify that different jobs run with different users. - Customer verbatim: "For example, when running a job that uses `image: alpine`, we want to run as user `guest`. When running a job that uses `image: node`, we want to run as user `node`." To solve this problem, customers cannot use the [Set a security policy for the pod capability](https://docs.gitlab.com/runner/executors/kubernetes/#set-a-security-policy-for-the-pod) as the security policy for the pod would apply the same security policy, and therefore same user, for all jobs. # Description GitLab CI YAML's [`image:docker:user`](https://docs.gitlab.com/ee/ci/yaml/#imagedocker) specifies the username or UID to use when running the container. This option is implemented for the docker executor (see https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2750, relevant MRs is https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/4483). Surprisingly, it is not implemented for the kubernetes executor - when using the kubernetes executor, `image:docker:user` is completely ignored. ## Proposal Have the Kubernetes executor run jobs as the given user when `image:docker:user` is specified on the job. ## Technical implementation proposal - [ ] Placeholder - pending async discussion with the development team. ## Links to related issues and merge requests / references https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2750
issue
Advertisement
Advertisement