feat: add SETUID and SETGID capabilities for gitlab runner container security context

[ericwyles]

Description

Add SETUID capability for gitlab runner container security context to allow running buildah inside a container from the runners.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[Racer159]

I think this change should be fine but can you add a docs note to configuration.md to mention needing this sysctl setting? https://github.com/defenseunicorns/uds-rke2-image-builder/pull/81/files#diff-8c6b38593d0267b1fcfe569ffd1ab064b64bdecc6293bc967cded5f4b9c8bc13R15
(ideally in an admonition to call attention to it)

[Racer159]

Small tweak since it is only applicable to buildah and tools like it

[bburky]

CAP_SETUID is basically equivalent to root in the container. I understand there's a need for this for container builds, but I don't love seeing this be the default config for GitLab.

Do we support multiple configurations of gitlab runner groups (so this could be an optional config)? Do we support/suggest using dedicated nodes for gitlab runners (so that compromising CI doesn't compromise the whole cluster)?

Have we made any progress on using ephemeral EC2/VM-based runners? Let people have root in their CI (and use real docker build), if you've isolated them with a VM or dedicated EC2 instance.

[bburky]

I guess DISABLE_RESTRICTCAPABILITIES_EXEMPTION is disabled by default. But it does end up enabled for all runners.

[Racer159]

CAP_SETUID is basically equivalent to root in the container. I understand there's a need for this for container builds, but I don't love seeing this be the default config for GitLab.

Do we support multiple configurations of gitlab runner groups (so this could be an optional config)? Do we support/suggest using dedicated nodes for gitlab runners (so that compromising CI doesn't compromise the whole cluster)?

Have we made any progress on using ephemeral EC2/VM-based runners? Let people have root in their CI (and use real docker build), if you've isolated them with a VM or dedicated EC2 instance.

We do support running gitlab runners on their own cluster (you can give it a different gitlab URL and registration token) and it is an optional config (though defaulted) as written - we can undefault it or remove that part of the PR to only partially support Buildah in the runner (buildah can run without this but flags warnings and I would expect some container build operations would fail though haven't dug that far yet).

Not yet on fleeting runners though it is something still on the docket to setup for envs that can use it (really just AWS rn)

[Racer159]

Opened a draft PR for the fleeting plugin: #117 - looks like it is out of beta now too cc @oates / @zachariahmiller

[zachariahmiller]

CAP_SETUID is basically equivalent to root in the container. I understand there's a need for this for container builds, but I don't love seeing this be the default config for GitLab.
Do we support multiple configurations of gitlab runner groups (so this could be an optional config)? Do we support/suggest using dedicated nodes for gitlab runners (so that compromising CI doesn't compromise the whole cluster)?
Have we made any progress on using ephemeral EC2/VM-based runners? Let people have root in their CI (and use real docker build), if you've isolated them with a VM or dedicated EC2 instance.

We do support running gitlab runners on their own cluster (you can give it a different gitlab URL and registration token) and it is an optional config (though defaulted) as written - we can undefault it or remove that part of the PR to only partially support Buildah in the runner (buildah can run without this but flags warnings and I would expect some container build operations would fail though haven't dug that far yet).

Not yet on fleeting runners though it is something still on the docket to setup for envs that can use it (really just AWS rn)

Unless something has drastically changed recently it fails without SETUID and honestly i thought SETGUID in rootless. IIRC its on the mount, buildah bud and buildah unshare

[Racer159]

lgtm assuming tests pass