Skip to content

Prevent execution of arbitrary commands when containers are used for job execution

Problem Statement

Organizations with highly privileged runners (those with AWS IAM roles, Terraform access, deployment permissions, etc.) need a way to prevent arbitrary command execution even if their GitLab instance is compromised. Currently, if GitLab is compromised, an attacker can define arbitrary job scripts in .gitlab-ci.yml that will execute on these privileged runners. This creates a single point of failure where GitLab compromise leads to infrastructure compromise.

Customer Use Case

A government organization runs CI/CD jobs that:

  • Have elevated AWS IAM permissions
  • Execute Terraform to manage infrastructure
  • Can restart services and modify production environments

They need runners that:

  • Only execute pre-approved container images (enforced via image signing + admission controllers)
  • Only run the container's built-in entrypoint (not arbitrary scripts from .gitlab-ci.yml)
  • Cannot be used to execute arbitrary commands even if GitLab is compromised

This security model is analogous to:

  • sudo with command whitelisting
  • SSH authorized_keys with command= restrictions

Current Workarounds and Limitations

Attempted Solution: FF_KUBERNETES_HONOR_ENTRYPOINT

The customer attempted to use FF_KUBERNETES_HONOR_ENTRYPOINT, but this feature:

  • Was designed for entrypoint initialization, not security isolation
  • Still executes job scripts via kubectl exec after entrypoint runs
  • Does NOT prevent arbitrary command execution
  • Does NOT achieve the security goal
  • Was also not correctly implemented and didn't even work as intended

Related Feature: disable_entrypoint_overwrite

There is a related feature disable_entrypoint_overwrite for the docker executor which prevents the entrypoint from being overwritten. However it doesn't prevent all scripts from GitLab from running, so it doesn't meet requirements.

Proposal

Implement a new feature called feature_name_goes_here which prevents any commands from GitLab Rails from running in job. This feature would supersede FF_KUBERNETES_HONOR_ENTRYPOINT and disable_entrypoint_override. The feature must follow the pattern recommended by the investigation spike which was to do initialization in a new init container, before running the build container. It is acceptable to copy step-runner into the build container and then exec the entrypoint exactly as it appears in the image which allows step runner to intercept and filter logs before they enter the Kubernetes log system.

Edited by Joe Burnett