gMSA Support for a Shared Runner Fleet
Overview
Hi Darren, We have a shared customer who is evaluating supportability of the use of gMSA with shared runners. I was looking through the GitLab docs to better understand what was supported, and ran across #27895 (closed)
I see this as still open and it wasn't clear to me if this was a supported scenario based on the discussion (e.g. - where it ended up). Do you have an insight here as to whether this is currently do-able given the current integration support with GitLab?
Additional context
Honoring confidentiality, I’ll keep it generic here, but happy to loop you into a private thread, if necessary, with the customer to collaborate. This is a large manufacturing partner that is heavily invested in GitLab. The scenario is basically as follows:
As a company, this customer has adopted gMSA for all of the SQL infrastructure and trying to move away from traditional accounts and credentials for the management. Today, the SQL team deploys and manages all their SQL instances using a combination of gMSA/GitLab/and their own set of shared runners with dedicated VMs.
They want to transfer ownership of all this over to a centralized team who manages a Shared Runner fleet for the larger organization. That team has standard implementation using containers for these shared runners and historically handle all identity and auth through a key vault. The SQL team does not want to use a vault (nor manage accounts this way). They want to use gMSA. The DevOps team feels that if they use gMSA with their shared runners, anyone who lands on those runners would have the permissions to the configured databases and says that Gitlab doesn't provide a way to lock down which runners a pipeline can use.
From a Microsoft standpoint, we have general guidance on how to configure gMSA with Containers but a lot the fine details and security ramifications land back with how the runners are implemented within GitLab and the controls around them. This where I have limited insight into GitLab guidance, feature support, and best practices. The only thing I could find was the previous link I shared that touches on the implementation of gMSA with runners.
Ultimately, they are trying to understand if it’s possible for them to configure gMSA on this generic shared runner fleet without opening security holes in SQL with other teams who may be landing on those same shared runners.
Current status of gMSA support (revised 2023-04-20)
Docker executor
-
Users need to prepare the container host.
-
Provide
security-opt
which is agitlab-runner
configuration option. Microsoft - Run a container with a gMSA.
Kubernetes executor
-
For Kubernetes, based on this gMSA document it all comes down to roles and security context which we support just fine with the Runner k8s executor.
-
Today, while there is no support for a credential spec for an individual job - use of gMSA is achievable by setting user and security options. You just can’t control it from individual jobs yet.