Limit Kubernetes Privileged Flag to Specific Containers in Job Pod [Kubernetes executor]

Release notes

Privileged Flag is no longer added to the entire pod by Kubernetes Executor. Only required containers have Privileged set.

Problem to solve

We require Privileged to allow us to run docker:dind in our shared runners and support container build and test workflows. Unfortunately, the privileged configuration flag on the Kubernetes executor applies that level of access to the entire job pod, rather than only to the service container running docker:dind. Allowing the build script, all downloaded code in dependencies, the GitLab helper, and all other services to run with effective root access to our Kubernetes workers is over-broad, unnecessary, and dangerous. We would like to only apply the privileged flag on a single container and filter that to an approved image.

Intended users

User experience goal

Devon, Allison, and Pryanka should be able to define and execute build jobs that need access to a Docker daemon while Alex feels confident that least privilege principles and compliance requirements are being met.

Proposal

There are several mechanisms that would meet this requirement, including allowing user-specified templates for the pod launched by the Kubernetes executor, or supplying a rules construct in the privileged parameter to the executor.

Runner administrator should be able to conditionally add the privileged flag to the container securityContext. Conditional rules should be have access to container image name and whether it is the script container or a service.

Further details

It would be additionally useful to prevent user override of container entrypoint or command when privileged is set. Reducing the ability of user provided scripts from running with elevated permissions reduced the attack surface.

Permissions and Security

These features should only be accessible to the runner administrator, and GitLab server permissions are not directly applicable.

Documentation

This feature should be documented under the Kubernetes executor

Availability & Testing

Available Tier

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by Darren Eastman