We need to evaluate the customer needs behind the request for honoring the K8 entrypoint in order to propose the proper solution. This issue is to track that investigation.
We need to have certain runners with a lot of power (IAM roles, etc), so that they can do terraform and restart things and whatever other tasks they need to do to deploy code and update infrastructure. This power is dangerous, and we want to limit how it can be used.
Thus, we need the ability to create runners that cannot just run arbitrary commands specified by the gitlab server, but instead will only run the entrypoint for the specifically blessed images we allow to run on those runners. We need to not trust the gitlab server for these runners. This feature is already active for docker runners, enabled by --docker-disable-entrypoint-overwrite.
This is a common security practice for allowing users to execute narrowly defined privileged commands, like sudo, where you can specify commands that can be run by users as root, or the ssh command= option in authorized_keys.
The reason why is because we do not want gitlab to become a security single point of failure. If we cannot create these high-security runners that only will run containers without supplying commands, then anybody who manages to compromise gitlab will be able to compromise all of our environments by supplying commands to these runners who are empowered to do almost anything to the environments they manage. Thus, we want to make it so that certain runners can only run certain images (which we can do with an admission controller and signing images), and the runners will only be able to execute the entrypoint of the image without supplying commands specified by the gitlab server.
We currently have this functionality with the docker runners. We now need this for the k8s runners.