Skip to content

adding flag to disable automounting the service account token

What does this MR do?

This merge request adds an optional registration option to the kubernetes executor that to make use of the AutomountServiceAccountToken feature of kubernetes pods:

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server

This can be used to disable mounting of service account tokens to the pods running scheduled jobs.

Why was this MR needed?

The use case where this makes the most sense is running the kubernetes executor in a multi-tenant cluster where security of the cluster is a concern. When the service account token is mounted into the pod, a scheduled job gains access to that token. While this can be limited with permissions of the service account being used, literally not mounting the service account token at all seems reasonably clean. This can be used to effectively remove all (non public) access to the cluster from pods being used for job execution. Extremely handy in a highly regulated environment.

Are there points in the code the reviewer needs to double check?

As first time contributor to this repository, I had to do some hacking around to build a container with the runner to test this out. I have tested this from a functional perspective with the following cases:

  • parameter not specified: service account token is mounted (this is unchanged from current behavior)
  • parameter is specified to true: service account token is mounted (this is unchanged from current behavior)
  • parameter is specified to false: the service account is not mounted

The actual code to accomplish this was basically trivial, but it also has (what I consider to be) a weird negative. The flag was set to "disable" for the registration to help make it easy to keep the current behavior if the flag isn't set. I'm certainly not a golang expert and would love to hear feedback related on alternative ways to keep the parameter clean without breaking existing behavior. For example: if I just made the flag identical to the kubernetes pod spec, AutomountServiceAccountToken then if the flag isn't set, it would interpret the flag as false and not mount the secret. This would be a breaking change because it would require people that rely on the service account token to make a code change.

I have intentionally not updated documentation while I look for feedback on the above. Happy to come in and add it if people think this approach is reasonable!

Feedback would be highly appreciated.

What are the relevant issue numbers?

https://gitlab.com/gitlab-com/account-management/US-Bank/issues/43

Edited by brianberzins

Merge request reports